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.

TOC Stories: Accelerating Projects

The remarkable success of Goldratt's business novel The Goal demonstrated the power of using a story to communicate business concepts. While this concept is not new, it had not been widely applied to business principles before Goldratt did it in 1984. More than 20 years later the book is still selling annually quantities most business authors would be happy to see in a lifetime of book sales.

Following this model I have created a number of stories based on real experiences we have had with organizations applying TOC. The following story is true and the results are real, though I have fictionalized the company name and blurred some details so as not to expose any proprietary information. I hope that you will find this format an interesting vehicle for learning more about TOC and the potential to be gained from its application.

The Story
“Big Pharma” develops, produces, and sells pharmaceuticals. They had a big fish on the line, a blockbuster drug with sales expected to be in the billions per year. And they were in a race. A competitor was working on a very similar product and the first company to get their product to market would secure the large pent up demand for the new drug. Arriving second would mean having to displace the other company’s product, a much slower, more expensive proposition. Being first to the market was easily worth billions in the first year alone.

One can imagine that with so much at stake, money was flowing freely in both companies. But outsourcing and adding staff didn’t always accelerate the process. As one executive said, “I know we need more people but I don’t know where and how many. Every time I have done that in the past all it did was increase my costs.”

The first need the company had was to understand exactly where the constraint was in their development cycle. As the drug was late in the development process, where most of the investment and effort is in the clinical trials to test the effectiveness of the drug, this was the area of most concern. When they used TOC to analyze their flow and understand where the bottlenecks were it became apparent that the real constraint was in an unlikely place, the clinical pharmacy. The clinical pharmacy supplies the drugs, and the placebos, that are used in the clinical trials conducted by doctors in their hospitals around the world. Doctors enroll patients and then need precisely prepared supplies of the drug and placebos (to insure the scientific validity of the trials) according to a pre-planned timeline. Missing the timeline would mean the loss of the test patients delaying the completion of the needed scientific data to get the drug approved.

The Obstacles
At this point in the drug approval process there are large volumes of clinical trials that need to be done and the weight of the workload had brought the clinical pharmacy to its knees. The planned preparation time for delivering the samples had been 8 weeks, but they were already extended out to 10 weeks, and were frequently missing even those delivery dates. On the horizon was an even bigger volume of work to meet the demands of the last trials before the submission of the new drug. The company had explored outsourcing the process to a contractor, but it was going to take months to validate them as a supplier and moving the process out of the company would also extend the lead times due to the approvals that were needed on each batch of products. Adding people to their existing operation would also take time, especially for some of the more unique jobs where things were breaking down already.

The climate in the clinical pharmacy made it not exactly opened to improvement. The group had recently been moved off the main campus of the company to make room for the growing staff there, resulting in a negative impact on the workers quality of life, and a loss of social connections to their colleagues in other departments. Moving to a remote physical location was also slowing down certain approvals and sign-offs from managers who remained on the main site. Things that had been handled in five minutes by walking over to a person’s desk, now turned into unanswered voice and e-mails, adding to the delays. In addition, once the analysis showed where the real constraint was, and with the mounting pressure of the growing workload, the people naturally became increasingly defensive, and protective of their turf. “Helping” people under these circumstances to improve their process was not exactly the ideal situation.

The Opportunity
The opportunity that existed for the clinical pharmacy was to understand much better how work flowed, or in their case piled up and trickled, through their system. The conventional methods of project management had long been established in the company with all of the usual effects apparent:

Projects were consistently behind schedule or late
Resources were not available when needed, even if promised
There was constant firefighting, with priorities shifting continually
There were too many changes and too much re-work
Necessary things (specifications, approvals, documentation) were not available when needed

They needed to understand how their mode of operating caused these effects, and to see how the Critical Chain approach would enable them to address the underlying causes of these symptoms. One of the most important of these causes was bad-multitasking, in other words stopping work on a task before it is completed to work on another more urgent one. It was widely believed that the “earlier you start a project, the early it will finish.” This had resulted in the large piles of work evident at each step of the process. ­With the increasing pressure brought on by the growing demand of trials and their missing delivery dates, bad-multitasking was the daily reality.

The other major contributor to the situation was the common management practice of focusing on the on-time completion of each tasks, in the mistaken belief that this would result in projects finishing on-time. Instead, as it does in most environments, it had resulted in people inflating their task estimates to protect themselves. With the growing work loads and the large piles of tasks at each step of the process (there were no fewer than 5 tasks on each person’s desk at any given time), this meant that most of the time it took to complete a task was waiting in the queue to get started. All the data they had showed that the time to complete a given task was getting longer, and that people’s estimates were in line with these times. What they didn’t understand was that there was a different way to manage the projects that would enable them to reduce both the individual tasks times and the overall project durations.

The solution to both of the core problems already existed in the critical chain process. First it was essential to reduce the work-in-process in the system, to shrink the queues at each step so the work would flow faster, and to eliminate the pressure to multi-task that was coming from having so many active projects that were not progressing. Through self-discovery workshops using interactive games and exercises, the clinical pharmacy’s managers realized for themselves how their conventional management methods were creating the problems they faced. They saw also how these practices could be modified to create very different results. While the changes were significant, the tools and processes enabled them not only to accept them but to take a strong measure of ownership in them.

Applying the methodology with the support of Concerto® software, the clinical pharmacy made the three fundamental changes for Critical Chain:

· They loaded projects into their pipeline only to the level that their most heavily loaded resource (their constraint or bottleneck) could handle them. This meant staggering the projects, starting many of them later than they had previously planned.
· They cut the times of each task by 50%, aggregated this time into a project buffer placed at the end of the project plan to protect them against the uncertainties and variability inherent in their projects. Then they cut this buffer in half, reducing the overall project duration to about seven weeks, from a little more than the previous ten weeks.
· They began to drive priorities only according to the rate at which these buffers were being consumed. In other words, tasks were worked based on which project had the least amount of buffer left relative to the amount of work remaining on the project.

By loading the projects based on their real capacity, the team insured that there would not be increasing backlogs of work in the system, thus the work would flow much faster without having to wait. With fewer open tasks the opportunities to multitask were greatly reduced, and work spent much less time waiting in queues to be worked. Stripping out much of the safety time from the tasks, then did not create any problems as most of this time had been needed for the queues. By placing it in the buffer at the end meant that it was visible to all, so they had a clear barometer for seeing if a project was tracking on time. It also made the safety time available for anyone whose work might take longer than expected due to unforeseen issues. But with work flowing more rapidly than before much less total safety time would be needed, so the overall project times went down. Shifting the behavior to focus on the most at-risk tasks insured that these projects got first attention. Projects with more safety, could wait without jeopardizing their delivery date. The team adjusted their measurements and indicators to match the new model.

The Results
Right from the beginning things improved. Within one month on-time delivery went from almost zero, to 50%. The lead time to deliver was reduced to seven weeks from ten, and within three months on-time delivery was at 100%, with projects completed up 40% After the first wave of improvements and stabilizing on-time deliveries at 98+%, the team realized there was the opportunity to further reduce the project lead times. Lead times were cut first to six weeks and then to three, just four months after launch. After six months the number of projects completed had doubled from the original rate, while on-time performance held steady at the new level.

The impact on the drug launch was remarkable. By addressing the constraint of the larger system the entire time-to-market of the drug was reduced. The rate of the clinical trials was accelerated and what had been an estimated advantage of “a couple of weeks” over the competition resulted in Big Pharma launching their drug four months ahead of the competition. During it’s the first year on the market their product outsold the competitors by more than $1 billion dollars, but it had cost less than $200,000 for the full implementation.

Since then Big Pharma expanded the use of Critical Chain to all of its global clinical pharmacies, to other critical product development processes, to facility construction and upgrade, and manufacturing process validation, with similar results. But these are subject for other stories.

Of course not every company has the leverage of a multi-billion dollar drug, but cutting project durations by half, while increasing output substantially, and moving to nearly 100% on time, can still has substantial benefits for almost every company. We hope you have enjoyed this installment in our series.

To comment on this story or to inquire about other stories you'd like to see, e-mail me at kfox@tocc.com