Project Success?
Do most projects deliver just what the client needs, when promised, and at or under the ORIGINAL cost estimate? World-wide experience says otherwise. Projects usually have great excuses for not meeting one or more of the necessary conditions for success of a project. Usually it can be blamed on someone or something, "Out of our hands." You no doubt have heard about some of the big ones: the Chunnel, the Denver Airport, the Super Conducting Super Collider, several defense projects. Some do get done...eventually. Later than promised, at higher cost, and usually missing scope at 'completion.' The Chunnel finally opened, it just couldn't transport passengers. So did the Denver airport, but it still ate passengers baggage.
Since projects show the same symptoms across many types and sizes of projects, over a long period of time, and even across many countries and cultures, isn't it likely that there is a fundamental flaw in the way we manage projects? The major innovations made in project management about forty years ago; computerized critical path scheduling and Earned Value, or Cost Schedule Control Systems (CSCSs), do not seem to remove the symptoms. Many of the grandest project failures have had great CSCSs. Doing Critical Path or CSCSs can't be the real Root Cause of the symptoms. Some people define insanity as, "Doing more of the same thing and expecting a different result." Dr. Stephen Covey uses the analogy of trying to find a street address in Chicago, while using a map of Detroit. No matter how much harder you work at it, you aren't going to get there.
Dr. Goldratt initially applied the Theory of Constraints (TOC) to identify the Root Cause of many production problems: the way companies manage statistical fluctuations and dependent events. A project is like a production line, from a different (moving) frame of reference. In a production facility, work moves through the work stations. In a project, work moves through the activity network. In a production facility, one of the mistaken policies was to use inventory in front of each work station to attempt to account for output fluctuations and dependencies. In projects, people add safety margins (time) into each activity. They assume if each activity has a high probability of getting done, the project has a high probability of getting done. This ides is similar to the thought that if each machine in a factory can keep up its efficiency, the factory is efficient. The TOC based Drum-buffer-rope solution demonstrated that the factory assumption was wrong. Can you see some reasons that the activity safety assumption might be wrong for projects?
Consider a project scheduled and managed to the critical path paradigm (many are, or think they are.) The method suggests that if you focus on the critical path, you can control the project. Unfortunately, there are often many other paths that are not much shorter than the critical path. They can become the critical path due to normal statistical fluctuations. In addition, when they merge into the critical path (and all of them must by the end of the project), then they can delay the project. When network paths merge, only delays are passed on. The project loses all positive variations. So what happens to the probability of completing the project on time if any of the many paths can cause delay?
Some propose that 'float' or 'slack' in the project network helps protect the project form this reality. Unfortunately, not only does project network float NOT depend on uncertainty of the activities in the network path, it is usually inversely proportional to the protection you need. That is, the longest non-critical project paths, which usually need the most uncertainty protection, have the least float.
Cost Schedule Control Systems (CSCSs) were developed so the government could have a firm basis for making progress payments on projects. They are based on single, simple, idea: we can measure progress by the activities completed. We can define the 'Earned Value for an activity by the Budgeted Cost of the Work Performed (BCWP) for each activity. By using the budgeted cost, rather than the actual cost, we could tell whether actual cost differences were due to time phasing of the work or the cost of doing the work. This solves the problem of focusing only on the critical path, because we see any activities that are behind. Unfortunately, it means we have nowhere to focus. All tasks seem equally important; or at best are weighted by the relative cost of the activity. In addition, if a schedule is resource leveled, we lose track of the actual chains of work through the activity and resource dependencies. The critical path is no longer the critical path.
The Theory of Constraints (TOC) asserts that every system has a constraint. TOC demonstrates that constraint time is much more important than non-constraint time. In Goldratt's first book, The Goal, Jonah clarifies for Alex Rogo (through Socratic questions, of course) that the value of time at the bottleneck is worth the total Throughput of the plant for the time lost. What is the value of time lost at the constraint of the project? Could you have many non-constraint activities done ahead of schedule, and the critical activity very late on a project? Does the use of Early Start scheduling make this even more likely? If so, your Earned Value may look good early in the project. What shape is the project really in? What is going to happen when, somewhere near the end of the project, the paths merge? Then, reality will tell you where the constraint was.
Current methods of managing uncertainty in a project fail to protect you. Worse, they lead to putting in excessive safety, and then wasting it. How confident are people in the activity duration estimates they give you? Not in terms of defining uncertainty limits, but in terms of how likely do they believe, when they give you the duration, that they will make it? The best way to answer this is to look at how your organization treats late and early completion. If everyone gets about the same true feedback whether they are late or early on an activity, people might give you times that have a 50/50 chance of being met. I haven't found that organization yet. In most organizations, you don't get beat up if you are on time or early (which few are), and it goes down hill from there. So in most organizations estimators are somewhat in excess of 90/10 chance of meeting or beating the duration they give you. At least, people believe they are when they give them to you.
The statistical distributions that cover events like task completion tell us that the 50/50 times to do a task are usually less than one half the 90/10 times. So, at least half of your schedule is 'safety' time to start with. Stashed away in each task. You know that if the individual activities are independent, putting the times in each task is the worst way to do it. There is a tendency to "use it or lose it." Your plan also fails to take advantage of the aggregation effect. This effect says that since some tasks will under-run and some tasks will over-run, the time to protect completion of a chain of tasks should (in general) be much less than the time needed to protect each task to a given level. For long chains of relatively uniform activity duration, it can be a lot less.
Paradox?
How can you have this safety time in the original schedule, and then have projects most often over-run lead times? People methodically waste the safety time. In addition to the merging effect, people rarely allow the project to take advantage of positive activity variations, and people rarely have them anyhow because of the 'hockey stick' (Goldratt's 'Student Syndrome') and multi-tasking. The hockey stick is the shape of the curve of effort vs. time over the duration of an activity. It is nearly horizontal for most of the planned activity duration time, and then shoots nearly straight up as the milestone approaches. Anyone who went to school and did reports or studied for exams understands this effect well.
In summary, current project management fails to effectively plan and manage uncertainty. It does not allocate safety correctly to start with (aggregation), puts in too much (over 100%), and then wastes it (merging, multi-tasking, hockey stick, failure to pass on positive variations.) It also diverts focus from the most important activities, leaving a project manager over-worked and uncertain as to what to do.
Critical Chain Project Management corrects these defects. It reduces the planned activity times to closer to 50/50 times, and puts a smaller but conservative safety time into properly located and sized buffers. It clearly identifies the critical chain of activities, and subordinates all other chains to it. It protects the critical chain from delays in the feeding chains with properly sized buffers. It ensures the availability of resources on the critical chain. It includes methods to incentivize resources to work 100 percent on activities, and pass the work on as soon it is done. It eliminate waste of activity time. It applies an improved measurement system (buffer management) with clear focus and decision information. It gets projects done on time, all the time, with less lead time (at least 25%) than other project management methods.
Project planning and management with Critical Chain also favorably impacts project scope and cost. There is less time to make changes, the distribution of activities reduces the impact of changes, and it reduces potential cost increases from scope changes and schedule over-runs.
Proof? The Director of the Wide Body Aircraft Division of Israel Aircraft Industries said, "...we succeeded to drop our average Turn Around Time per Aircraft Visit from three months to two weeks, and to increase our backlog from two months to one year."
More proof: Harris built a new eight-inch semi-conductor water plant in record time...one third the industry average time for a plant like this. (13 months instead of 46...with a Throughput of $2 m/day.)
More recently, a pharmaceutical company we have worked with improved the Throughput of its drug Discovery process by nearly a factor of three. The U.S. Navy improved ship overhaul processes at Pearl Harbor Naval Shipyard to achieve over 95% schedule success, and increased productivity by nearly 100%. They have used CCPM on large projects at other shipyards to save the government millions of dollars, and achieve unprecedented schedule success. With our help, the U.S. Coast Guard is achieving record schedule performance on its overhaul of coast guard cutters. It companies are cutting project durations in half, and achieving schedule success of near 100%, unheard of in that industry.
Let us help you achieve that same level of success. Please Email us now, before our schedule for 2005 is fully booked!
PS: You don't have to be the CEO of a company to achieve success with CCPM. We work with managers of single projects, heads of project organizations and PMOs, and senior managers responsible for thousands of resources. We tailor our solution to your need.