More Projects Faster: Critical Chain Project Management

Thanks for all the great responses to past. Given the apparent interest in Project management issues from my last article on the subject, and the numerous requests for the follow on article, I have decided to post it here. It's a bit long for a blog, so if you want a pdf to print out, ask for it.(For those of you who have requested the article directly through info@tocc.com, it has been sent in pdf to you already.) I hope we keep the exchange going.

Kevin

More Projects, Faster, with Fewer Resources: Critical Chain Project Management

“It’s not important to complete tasks on-time, it is essential to complete projects on-time.”

No matter where you look in today’s competitive world, the pressure to complete more projects, faster at lower cost is pervasive. Speeding construction projects brings new plants and stores, with their substantial revenue streams, on-line earlier, improving investment returns. Accelerating new product development and launch expands market share, increases sales and for many companies can be the difference between being the market leader and being an also-ran. In information technology, bringing new systems on-line faster means enhanced capabilities for customer service, inventory management, and a host of other mission-critical management activities. For most companies involved in strategic projects, delivering more projects faster is not just important, it is imperative.

While there is a wide range of different project types companies undertake, there is a surprisingly consistent set of issues, or complaints across this spectrum. In most project environments, the list typically includes all or most of the following concerns:

· The original dues dates are not usually met
· There are too many changes
· Too often resources are not available where and when needed (even if promised)
· Necessary things are not available on-time (information, specifications, materials, designs, approvals)
· There are fights over priorities
· There are budget overruns
· There is too much re-work

The simple fact that this list is so common and pervasive, strongly suggests that the common problem is much more related to how companies manage projects than to any technical or specific factor. The existence of a common core problem also provides companies with an exciting opportunity to make significant strides in delivering more projects faster with fewer resources.

Critical Chain highlights that there are three main factors in how companies manage projects which lead almost inevitably to the concerns listed above. These core drivers are:

1. Bad Multi tasking
2. Student syndrome
3. Parkinson’s Law

Bad multi-tasking is the process of stopping a task before it is finished in order to do something else that is either immediately urgent, or otherwise important. Each time a task is stopped there is an immediate efficiency loss due to the time needed to “get back into” the task when it is resumed. In knowledge work especially, it is not insignificant to have to re-orient oneself to the work each time it is re-started. Worse still are the delays these stops and starts cause to downstream tasks. Each time other work is inserted into a task, its elapsed duration grows. Because there are dependencies between tasks in projects these delays immediately start to delay the downstream tasks, and quickly impact the overall project timeline.

Given that most companies readily admit that this multi-tasking occurs frequently, and that people generally have many open tasks on their desks at any given time, it is not hard to see how the prevalence of this practice quickly results in the “Cascade Effect.” In other words delays move like dominoes through the project, extending overall durations and delaying project completions. (For a more complete explanation of this effect request TOCC’s “Bad Multi-tasking” article from info@tocc.com)

The second and third factors above are directly linked to how companies manage safety time in projects. Uncertainty is the reality of projects. While some actions may be taken to reduce some of the uncertainty, eliminating uncertainty and variability is simply not possible. Projects are like driving in a large metropolitan area, no matter what you do there is always the chance of encountering delays (rush-hour traffic, an accident, construction). No one can say for sure how long it will take to go from one place to another. One can only adjust the safety time allowed to insure arriving on time.

In projects companies often behave as if they can eliminate the inherent variability of the work involved. They do this by trying to improve the quality of their estimated task durations. The aim is to arrive at task estimates that can be met, while at the same time not being too long to meet the required timelines, and then holding people accountable to hitting those estimates. The logical reaction of people, in the effort to provide what is required, is to give estimates that they are confident can be met. This means that people must estimate task durations with enough safety to account for the significant number of things “that could go wrong” along the way.

While this makes perfect sense and is done with the best intentions at heart, the impact on projects is devastating. As soon as safety is built directly into task estimates, the student syndrome is triggered. In school students will argue for additional time before a test or an assignment is due. And then, when it appears they have plenty of time, there will be no urgency to start, often beginning work very close to the deadline. The same is true in projects. When people are busy, and their estimates provide the belief that there is ample time to complete the task, there will not be any real urgency to start when the task becomes available. As a result a good measure of the safety time built into the tasks is wasted at the front end of each task. The student syndrome accounts for a significant measure of the delays and long durations of projects. It is safety time that is really not used to complete the work, in spite of people’s best intentions. And all too often while this safety time was lost at the front end, it turns out to be needed at the back to overcome some unforeseen obstacles, resulting in tasks finishing late in spite of the safety.

At the back of each task is another mechanism, Parkinson’s Law, which helps to insure that even though safety time has been added to the estimates, that tasks will not finish (much) ahead of the planned time, even if no obstacles are met. The reality here is two-fold. First, if people do find they have extra time to finish a task they often use that time to “perfect” or “polish” their work, wanting to do the best job possible. So the work expands to fill the time available. The second issue is that there is a dis-incentive for people to finish early. Finishing much ahead of the planned completion date for a task sends the signal to management that the estimate was “fat” and that in reality it can be done much faster. The next time these estimates will be cut further in an effort to reduce overall project durations. Knowing that in the future this safety time may well be needed to account for unforeseen problems, people will not be quick to report early finishes of their tasks.

The result of these factors is that most companies will observe that their tasks generally come in very close to the estimated times, with a number of tasks completing later than planned. It can be easy to conclude that the company does an excellent job of estimating its task durations, and that there is thus not much opportunity to improve through better synchronization, but this is far from the reality. The simple nature of projects and project tasks is that there is variability. Doing a similar task may take 10 days one time, and due to certain obstacles or challenges, take 15 days the next time. This is the reality of trying to predict durations, just like predicting how long it takes to drive into a busy city on any given day. It will take different times each time it is done.

This means that if the company’s task estimates appear to be very reliable (i.e. they are met most of the time) that in fact there must be considerable safety that is being lost in the process. And as a result there is considerable opportunity to reduce durations, and increase project output, without adding resources.

Critical Chain addresses the core drivers of projects through three mechanisms. In order to curtail the bad multi-tasking effect there is the need to reduce the amount of available work in the pipeline. The mere presence of many jobs on each desk creates sufficient opportunity for resources to multi-task and misprioritize work, that it simply cannot be managed. Project managers, motivated to complete their projects on-time will persuade and cajole resources to shift priorities, customers and executives will exert their own pressures to re-focus resources, and the simple desire of people to choose between various tasks will insure that the bad multi-tasking will take place.

Initially Critical Chain drives the reduction in active work-in-process by freezing a significant percentage of the projects in the pipeline. By reducing the opportunities to multi-task, people can stay focused on and complete tasks much faster, enabling them to move more quickly from step to step, encountering much smaller queues of work. Freezing at least 25% of the projects typically is sufficient to accelerate the flow of work and thus the completion of projects. As projects finish the frozen projects can be released and also move much more quickly through to completion. This mechanism alone typically results in improving on-time project completion considerably, without making any projects (even the frozen ones) later than they would have been otherwise.

After the initial freezing process, to get to a steady-state of operation, it is essential to insure that work is released in a metered fashion so that WIP stays relatively low and bad multi-tasking is reduced. Theory of Constraints points out that any system, or project pipeline, can only do as many projects as it can get through the weakest link (the constraint) in its chain. Releasing more work than the constraint can complete in any period will only result in work piling up in front of the constraint, not in completing more projects. Critical Chain thus highlights that work should be released according to the capacity of the weakest link (most heavily loaded resource) in the system. Projects can then be pipelined and due dates committed to according to when there is an available slot on the constraint.

The second essential element of Critical Chain deals with how to plan for safety time in projects, so that the added time will not be wasted, and so that project plans will be as short as possible while still sufficient to give reliable delivery dates. This is accomplished by first identifying the longest chain of dependent tasks and resources for the project. This is very similar to what is widely known as the “critical path” but also allowing for any resource contentions (points where the same resource is required on two parallel tasks) that exist along the way. The resulting “resource-leveled critical path” or critical chain is what will determine the overall duration of the project.

For all the tasks on the critical chain the task estimates are cut, typically to 50% of their current duration, and the cut time is placed at the end of the project as a buffer. By removing a significant measure of the time from the estimates and placing it at the end, this safety time is now both much more visible for management purposes, and is available to every task on the critical chain who might encounter a real delay. However once this time is extracted and aggregated at the end it is possible to reduce it considerably, and with it the overall project duration. When the safety time is available to all, and tasks times are much shorter (therefore less likely to induce the student syndrome), and there are far fewer delays stemming from multi-tasking, the total safety time needed is by far less. The chance of encountering a delay on any given task is very high, but the chance of encountering a delay on ALL the tasks is very, very low. Critical Chain advocates cutting the safety time in the buffer in half, and experience has proven that in nearly every organization, there is still ample safety time remaining to complete the projects on time.

The last core step of Critical Chain is execution management using the buffers to guide decision making. If delays are encountered on the critical chain, some of the buffer time at the end of the project will be consumed. By observing the ratio between the percent of work completed on the critical chain and the percent of the safety consumed managers can see for any project the risk profile. When a project’s buffer is being consumed at a faster rate than the work on the critical chain, the buffer is red, or at risk. When both the buffer and the critical chain are moving at the same rate, it is yellow or “okay.” When the work is being done at a rate faster than the buffer is being consumed then the project is ahead, or “green.” At a glance executives can see which of its projects are at risk and which are on track and decide where and when to intervene.

For project managers, whose responsibility is to deliver the projects on-time, it is essential that they know immediately what task is responsible for a buffer being consumed faster than the work is being completed. They need to be able to see which task is holding the work in these cases so that they can undertake the proper actions to bring projects back to the green zone. By monitoring the buffer trends over time (getting more green, or getting more red) they can readily see and manage the corrective actions they are taking to insure their effectiveness.

For functional managers responsible for deploying people and other resources on project tasks, the central issue is setting priorities and matching people and equipment properly to tasks. Given that each task feeds into the project buffer, it is possible to tell if the task is feeding a buffer that is okay, or green, or in trouble, red. Project tasks that are red are given higher priority than those that are green, which can wait because there is still safety time available. Functional managers can thus deploy their resources according to the status of all the projects, and eliminate the fights over priorities that are a constant occurrence today in most organizations. By looking ahead to see the upcoming tasks for their department, and the status of each, managers can properly plan and assign resources to tasks based on the work involved and the relative urgency of that work.

Finally, Critical Chain provides the execution model for the task resources themselves, the people who do the work on the projects. The visibility of the buffer status for each task enables people to see clearly which of their tasks are the most urgent and make the right decisions about priorities without needing management instruction. They also can tell whether it is important to seek help when there is a delay. Red tasks clearly mandate getting help when there is an obstacle, whereas green tasks can suffer a delay without jeopardizing the project.

Of course it is essential to report certain data on projects to insure that the needed information is up to date and accurate. In many approaches progress is measured either as a percentage of the work complete, or the amount of time put in (often referred to as Earned Value). Unfortunately these reports of the amount of effort put in, do not indicate very clearly how much more time is required until the task is complete, which is ultimately what is needed. Many managers have experienced this in reality when it seems to take as long to complete the last 10% of a task as it did to do the first 90%. To counteract this, Critical Chain has Task Managers report the time remaining to complete a task. In most cases this is a far easier figure to give than the percent complete or the hours put in. And by reporting the time remaining it is easy to add up the remaining time on the critical chain and compare it to the amount of buffer consumed. (There are several software packages available in the market which automatically provide the information and reports described above, greatly facilitating the application of Critical Chain in organizations. More information is available by request at info@tocc.com)

The result of the application of these three central steps (project staggering according to the pipeline’s constraints, critical chain project planning with buffers, and buffer driven execution management) is a significant acceleration in project flow. Companies who have applied these steps have routinely seen on-time completions move to above 95%, while project durations have been cut 25-50% of there previous lengths. They have achieved these results through synchronizing the flow of work across their resources, and without adding more people or cost to their systems. The reduction in project durations translates directly into completing more projects in the same period of time, greatly improving the return on investment in projects and accelerating revenues.

While the changes suggested by Critical Chain are not difficult to understand in concept, putting them into practice in an organization carries with it some notable challenges. The greatest of these is the courage required to change the long-standing practices, procedures, and measures used to manage projects at all levels. Moving from the mode of pushing projects into the pipeline as early as possible to releasing them according to the constraints means changing the widely held belief that the earlier you start a project, the earlier it will finish. Without the cooperation of sales and upper management in the metering of projects, the pressure to launch more and more projects will overwhelm the pipeline and insure the return of bad multi-tasking.

Putting visible buffers into projects requires executive support based on an understanding of the fundamental principles, or it will result in these buffers being eliminated and unrealistic plans being launched. Managing projects and priorities according to buffers means that managers and task resources must surrender their reliance on managing individual task times as their main means of control. The magnitude of these changes is not insignificant as each requires overcoming the inertia of long-time practices and beliefs, any one of which can quickly undermine the process.

There are proven processes and techniques for navigating each of these fundamental shifts, but that is the subject for a future article on implementing Critical Chain in organizations. If you are interested in receiving this article, please send a request for “Critical Chain Implementation” to info@tocc.com, for examples of results visit www.tocc.com/TOC%20results.htm.