For all of our newsletter readers, I’d like to announce a big change with Craig Lamb & Singletary, Inc., and this newsletter. As of December 1, our company is joining forces with ComFrame, a Birmingham-based high-end services provider very complimentary to CLS.  How will the newsletter change? Only the logo for now, starting next issue. Longer term, you can expect even more valuable content, with perspectives on CPM and BPM that only the experience of a firm like ComFrame can provide. Closing on 1000 subscribers, the newsletter has been a key part of our message and I promise that the content will only increase, with more first class contributors on the way. As always, we are interested in any feedback you might have, and please enjoy this issue!

 — Duncan Lamb, President, Craig Lamb & Singletary, Inc.

Jackson, MS, Tuesday, January 30, 2006.  CLS will be hosting an EPM "Lunch and Learn" seminar from 11:00-1:00, CST.  If you will be in Jackson, MS, you won't want to miss it!

If you know someone who might be interested in receiving this newsletter, please email the Subject Line "Subscribe" to newsletter@clsassociates.com with the e-mail address in the message body.

By: Alex S. Brown, PMP

Microsoft Project is a widely-used scheduling tool. Its quirks and complications are a huge drain of time on the Project Management community. This series will go beyond tips and tricks to discuss solutions to real-life problems, to achieve real time-savings for its many users.  MS Project default settings can work against the experienced project manager. A common complaint about the tool is, “I hate to touch anything once I have my schedule right. If I change anything the whole schedule seems to fall apart.” With four simple steps, any project manager can take back control. The Project Manager needs to run the schedule, but all too often MS Project can try to take control. Take back control by understanding the tool better.

#1 Automatic Predecessors and Successors
Some MS Project default settings only make sense if you want to demonstrate the tool. If you want to quickly generate a phony schedule with the minimum of keystrokes, it makes sense for each task to be the predecessor of the one before it. Task #1 depends upon task #2, depends upon #3, and so on. By default, MS
Project will create these dependencies for you. Unless you always work on single-person projects, and you always execute your entire task list from top to bottom, you should consider turning off this “feature”.  Whenever I get a new computer, I always launch Project and change this setting. When I create my task list
or WBS, I want to focus on breaking down the work, not on dependencies. When adding dependencies, I want to decide what they are and create them myself.

To change this setting, go under the Tools menu, to the Options menu item. Go to the Schedule tab, and clear the “autolink inserted or moved tasks” checkbox. You may turn this feature on temporarily, to enter a string of dependent tasks, but most project managers should keep this checkbox cleared most of the time.

#2 "Fixing" Your Tasks
Every MS Project user I know has told me the same story: it is an hour before the project status meeting. The schedule has changed in some dimension: estimated work-hours for a task, duration of a sign-off, or another task-level date. This change will ripple through the schedule because of the dependencies. For some reason, though, MS Project will not change the date to what it must be. The change is obvious and simple, but every time you enter the new date, the program either replaces it with the old value or adjusts something that should not change.

Ninety percent of the time, the problem lies with the task type: fixed work, fixed duration, or fixed units.  The difference between these three will explain why many values jump when you make just one adjustment.

MS Project has a basic calculation for all tasks: duration times units equals work. In plain English, a task that will take eight hours to complete (duration), has a full time resource assigned (100% units) requires eight work-hours to complete (work). A task that will take 40 hours in duration, that takes only 10% of a person’s time, only requires 4 work hours.

This basic equation is clear, but once you start making changes, it takes on a life of its own. If you chang the work-hour estimate for the 8-hour duration task to 16 hours from four hours, what should happen? Does that task now take 16 hours duration, or two people (200% units)? MS Project decides what do to after checking which value is "fixed" for the task.

If the task is fixed duration, then any change to either work-hours or units will affect the other, without changing duration. For the 40-hour duration task, increasing the work estimate to 8 hours will increase the units to 20%. MS Project assigns the task to spend more time per day, to get the job done in the same duration.

If the task is fixed units, any change to duration or work-hours will affect the other. For the 40-hour task, increasing the work to eight-hours will increase the duration to 80-hours, while keeping units at 10%. MS Project assigns more time to the task, keeping the units fixed.

If you change the fixed value, MS Project behaves as follows:

• Change the duration of a fixed-duration task, and the work changes (units stay the same)
• Change the units of a fixed-unit task, and the duration changes (work stays the same)
• Change the work of a fixed-work task, and the duration changes (units stay the same)

The first rule of working with units, duration, and work is: figure out your goal BEFORE changing values.

Just because MS Project might keep the duration constant when the work doubles or it may double the duration; as the project manager you need to know what should happen. MS Project can print reports for you and track the effect of your dependencies, but it will never predict your project work for you. Choosing the right setting for each task will make the process easier for you.

Fixed units are great for tasks that always consume the same amount of work-time every week, no matter what. Earned value books call these tasks "level of effort" and they include supervision, management, and status reporting tasks. The more time they are performed, the more work-hours they consume.

Fixed duration is my favorite task for IT projects. If you use the saying, "it does not matter how many women are pregnant, it still takes nine months to make a baby," then enter "fixed duration" into MS Project.  No matter how many resources or work hours are assigned, the task will always take the same duration of time. Fixed duration is also great when you want CONTROL over the duration of your tasks. I often find, for instance, that adding people to a task may reduce its duration, but not quickly and not easily. I use fixed duration tasks so that I can increase the resources on a task and then manually change the duration. I want to make a decision before changing a duration, and MS Project lets me do so if I choose "fixed duration".  Fix the duration and enter the work effort, and MS Project will figure out the units. Perform resource leveling and MS Project is solidly under control.

Fixed work is useful for tasks that scale up or down perfectly along with the resources assigned. Production tasks sometimes work this way, if you have an efficient production process. So long as you have enough machinery, for example, adding more machine operators will increase manufacturing production nearly linearly. Double the resources, and you halve the time needed to produce a given amount. When using this method, be careful. It will never factor in learning effects, communication overhead of a large group, the cost of splitting a task, nor the cost of dragging out a task over time. You need to remember that MS Project will adjust your schedule automatically, and remember to add tasks or work-hours to cover these effects. At a certain number of resources, for instance, you may want to add a fixed-units "management" task, covering the same days as the fixed-work production task. The manager will oversee production and help with communication. Alternatively, just adjust each person’s work estimate when changing assignments, taking into account the added overhead of large-group efforts.

#3 Control Your Resources’ “Efforts”
The next complaint of new MS Project users is random changes when adding or removing resources from a task. “Effort driven” tasks can make your work and units change on a task every time you add a new resource or take one away...

The preceding article was an excerpt of a full article written by Alex S. Brown for his website, www.alexsbrown.com.  To view this article in its entirety and in its original format, please follow this link:

Real Life MS Project: Take Back Control, Alex S. Brown, PMP. 

By: Derry Simmel

Maybe you have experienced this phenomenon. You are at a company and they have a PM methodology, they are using the forms, there may even be people with Project Manager titles, but the benefits and results that come from project management are not there. I suggest that organizations like this are suffering from "Cargo Cult Project Management." I doubt I can trademark that, so feel free to use it as your own. Let me indulge in a little history for those who may not be familiar with the term.

During World War II the Allied forces occupied many of the Pacific islands. Up until that point, many of the inhabitants of these islands had never seen manufactured goods. With the military occupation, things like clothing, food, weapons and other manufactured goods were delivered in plentiful quantities. These supplies arrived in airplanes. To the islanders who were unfamiliar with manufacturing or powered flight, the arrival of the good from airplanes seemed to be a direct delivery from the gods. After the war, the airplanes and their cargo, no longer came. In an attempt to get the planes to return islanders made airplanes out of wood, radio sets out of bamboo, and even painted military symbols on their bodies. They talked on the radios, waved flags, and lit up the runways at night, all to no avail.

This is not unlike what happens at some companies today. We use project charters, create Project Manager job titles, and produce a methodology but nothing really happens. We don't get all those great project management benefits. Some PMO Directors have told me that they are not allowed to call their organization "the PMO." This is invariably due to an unsuccessful attempt at a PMO which left everyone bitter and disillusioned. I can certainly sympathize with those feelings. Imagine how the natives that spent all day waving palm leaf flags felt when they finally realized that no cargo was coming. Just like these natives, executives and management have been asked to do a lot of work for little or no result.

How did this happen? More importantly, what can be done? In my opinion, this happens for two primary reasons. First, too much emphasis is placed on the trappings and appearance of project management. Secondly, someone tried to implement project management in the wrong order. Let's look at the second reason first.

You can read earlier articles where I talked about the need to build your PMO through People, Processes, and Tool and in that order. In the case of a cargo cult PMO, someone has started with the tools. Not necessarily a purchased software product, although that is common, but the forms, the meetings, the language and other end products of Project Management. Just like the natives, we started with all the right tools, and got no result. The reason the natives did not get cargo is because there was no infrastructure, no industry, trade or machinery to create the cargo. Similarly, a PM tool without the underlying support of the right people and the right processes will fail.

Next there is this (IMHO) unhealthy focus on the physical aspects of project management, the forms, tools, reports. These are not project management. If you're reading this, you probably already know that, but some PMOs have gotten a bad name because they tried to start there. This is a huge temptation and absolutely understandable. Your management is demanding that you show results so by creating a methodology or by implementing a tool you can show that something has actually happened. Something did happen and it may look like project management, it may even feel like project management, but it's no more project management than a coconut headset is a radio.

Now, I am not saying that you can't succeed if you start off with tools and methodologies. Some companies (the very rare ones) may already have a fertile environment for this. I'll bet that if you looked carefully at these companies you would find that they already had the right people and processes in place; they just probably were not calling it Project Management. Unfortunately, most places are not like that. So what do you do if you are stuck in this kind of situation?

I think the first step is to assess what is going on. Resist the impulse to act, you probably represent the last chance project management will have at your company for the foreseeable future. If you fail, then you and project management are out the door. After you have an understanding of what is going on, cut, cut and cut some more. Get rid of every one of the forms or tools or processes that is not creating significant and measurable value. You can figure out what these are by observation. If everyone enters 8 hours for a project every day, then your time system is not being used correctly ? can it. At this point you are not trying to fix anything - that will come later. Just clean house.

What you will be left with are the people, processes and tools that are producing and valuable. Start here by enhancing and consolidating. Improve what is working. Bring everything into a consistent whole. Call this your methodology if you want, but please do not confine project management to a series of steps to be taken. If you confine PM then so will everyone else. Things get more complicated from here and I've already written on several of these topics, so I'll stop here. The idea is to stop doing the things that do not work and start doing the things that will.

To view this article in its original format, please follow this link:

Cargo Cult Project Management, Derry Simmen.

The company is thriving, with a culture that lets left-brain and right-brain types coexist

It may surprise those who have come to know Motorola (MOT) for its cool cell phones, but the company's more lasting contribution to the world is something decidedly more wonkish: the quality-improvement process called Six Sigma. In 1986 an engineer named Bill Smith, who has since died, sold then-Chief Executive Robert Galvin on a plan to strive for error-free products 99.9997% of the time. By Six Sigma's 20th anniversary, the exacting, metrics-driven process has become corporate gospel, infiltrating functions from human resources to marketing, and industries from manufacturing to financial services.

It's still paying off for Motorola Inc., too. Consider the hot-selling, super-slim Razr phone. A creative, innovative design, sure. Yet "Six Sigma's stamp is all over the Razr," says Michael S. Potosky, Motorola's corporate director of Six Sigma. Engineers, for instance, applied the process to the phone's antenna, helping keep it hidden while maintaining call clarity. With hits like the Razr, the Schaumburg (Ill.) company has climbed from a 15.4% market share in mobile phones to 22.4% over the past two years. Motorola netted $4.6 billion on $36.8 billion in revenues last year, helping it earn the No. 13 spot on the BusinessWeek 50 list of top corporate performers.

COMEBACK It wasn't always thus. In fact, Motorola stumbled in the late '90s, ceding its lead in mobile phones to Nokia (NOK ). But one of the company's biggest feat in rebounding has been to allow the left-brain, analytical discipline of Six Sigma to coexist alongside the right-brain creative process without disrupting it. Six Sigma, broadly speaking, expresses a way of thinking about business problems that encourages precision and predictability. The mantra of Six Sigma "black belts" is DMAIC, for "define, measure, analyze, improve, control." The "sigma" refers to the Greek letter, which in statistics is used to measure how far something deviates from perfection. The "six" comes from the goal to be no more than six standard deviations away from that perfect measure.

Innovation, by contrast, can be messy. It is hard to sum up in a simple statistic and requires a healthy tolerance of failure. "Innovation is, by its very definition, based on the idea that the value resides in the introduction of something unexpected," says Dev Patnaik, a principal at Jump Associates, a design strategy firm in San Mateo, Calif. When it comes to the breakthrough product, or the game-changing strategic shift, Six Sigma fans can "have all the wrong reflexes," says Rita Gunther McGrath, a Columbia Business School management professor.

At Motorola, designers are left to do their thing, but the process wonks will be close at hand, to make sure a cool project meets a measurable customer demand and gets built to quality standards. Unlike some companies newer to Six Sigma's esoteric methodology, Motorola has people who accept it as part of the culture. Veterans are used to so-called project hoppers offering input at various stages in product development.

Others agree that Six Sigma and innovation don't have to be a cultural mismatch. At Nortel Networks (NT), CEO Mike S. Zafirovski, a veteran of both Motorola and Six Sigma stalwart General Electric (GE) Co., has installed his own version of the program, one that marries concepts from Toyota Motor(TM)'s lean production system. The point, says Joel Hackney, Nortel's Six Sigma guru, is to use Six Sigma thinking to take superfluous steps out of operations. Running a more efficient shop, he argues, will free up workers to innovate.

That's clearly a seductive line of thinking: About 35% of U.S. companies have a Six Sigma program in place, according to a January, 2006, Bain & Co. study. "The past 20 years are evidence of how many companies have picked up that [it] works," says Potosky. But even a disciple like him stresses that in this era of the Big Idea, Six Sigma's success will only come in a culture that not only welcomes creative types and the metrics-obsessed, but one that makes them both better.

To view this article in its original format, follow this link: 

Six Sigma still pays off at Motorola, Business Week.