We talked about the following issues (On estimating project tasks) that prevent projects from completing on time:

1. Milestone Management: Working to meet task deadlines or milestones
   • Parkinson’s Law: Work expands to fill (and even exceed) the allocated time
   • Student Syndrome: Negotiate safety into tasks (by extending the deadline) and use the safety upfront. Scramble towards the end to get the task completed
   • Measurement systems with lagging indicators: Earned value, CPI and SPI are lagging indicators due to task estimation issues
2. Multi-tasking: Working on more than one task at any point in time

We also talked about how safety (buffer) is added to every task. This is a form of local optimization and we know that local optimals do not necessarily lead to global optimals. We need to only protect the total project duration; i.e. add safety to the project and not to each task. Let’s turn our attention on how to fix these issues. 

Creating the Critical Chain

Critical Chain is an application of Theory of Constraints (ToC) first proposed by Eli Goldratt. The premise of ToC is that just as a strength of a chain is determined by its weakest link, the throughput of any system is determined by its constraint or the bottleneck. In any system, there will be just one or two constraint/s that determines throughput.

If we consider a project as a set of dependent events; a.k.a. a chain, then the critical path is the project constraint. The length of the critical path dictates when the project can be completed. Any task that is late on a critical path makes the project late. However, the critical path assumes resources are available 100% of the time. This is an incorrect assumption especially if you are working in a matrix organizational structure. The resource you need might only be available 50% of the time. Your project schedule should reflect this.

Here are the steps needed to convert your critical path project into critical chain.

Allocating resources to the project

Removing safety from each task

If this is the first time you are implementing critical chain project management, I would recommend you to have a heart-to-heart chat with your team. The most important process  in increasing throughput is to create a culture of trust amongst your team members. I tell my team that the task estimates will only be used to come up with two end dates: an aggressive end date and what I call the CPM (critical path method) end date. I do not care when each task is finished as long as I can see ownership and conscious effort in completing tasks as soon as possible. In order to do that together we will:

1. Estimate tasks at a 90% confidence level
2. Split the estimate into 50% and 40%. Move the 40% estimate to a bucket called “project buffer”. This bucket will be placed between the aggressive end date and the CPM  end date. This buffer will protect the project end date from slippage.
3. By working with estimates at 50% confidence level, the project can now benefit from early finishes.

If explained properly, the response usually is, “If I were working on a project at home, I will be working like this. I am going to try to complete tasks as soon as possible. I will also not wait for the “scheduled” start date on the successor tasks.” Such responses are music to the ears. This shows that the team has bought into the critical chain concept.

Your transition to critical chain project management will suffer a setback if you do not establish the trust necessary to work with estimates at 50% confidence level. Everyone likes to think they are true to their word. If you start challenging estimates in the middle of the project and revert to milestone management, you will lose the trust and will not likely get reasonable estimates. So take the time to do this right.

Project buffers and feeding buffers

As shown in the adjacent image, the area above the shaded region shows a very simple project critical path. The shaded region shows the same critical path but with buffers highlighted for each task. The third image under the shaded region shows the critical chain with project and feeding buffers. All we have done is to take the buffers on the critical path and segment it together under the bucket “Project Buffer”.

We need ensure that each path that feeds into the main path is completed on time. This is necessary to ensure that the tasks critical to the project completion is not delayed on account of delays in the non-critical paths. Hence, each feeding path is protected by feeding buffers. The principle is the same. Take the buffers out of each task on the feeding path and segment it together under a bucket called “Feeding Buffer”.

As you can see in the figure, the aggressive project completion (in the third schedule below the shaded area) is half that of the original schedule. So even if some of the tasks complete late, the project end date is protected. By not having milestones along the way, the project team just completes tasks one after the other as soon as possible. This will ensure that the project is completed somewhere between:

1. the aggressive date (best case scenario)
2. the original critical path date (worst case scenario)

Multitasking

Multitasking is a throughput killer. The very act of starting and stopping tasks adds waste to the development effort (increase in ETC). It also adds duration to the project. To give you an example of how much waste is involved in starting and stopping, we are now completing more work with the same number of people than we did before we implemented the Kanban.

All we did was to ask people to ensure they completed a task if they picked it up. If they felt that they could not complete a task, then we asked them not to start it. By condoning multitasking, the management is sending a message that they do not care about throughput. I am not about to regurgitate what I think about multitasking here.

Measuring progress on the critical chain

The goal of any measurement system is to ensure that you are on the right track. Trends in deviation from plan should be apparent before the deviation actually happens. The Earned Value method typically looks at what should have been done (or what was planned) and compares it to what was accomplished and provides a ratio. The major drawback of this method is that it does not look into the future to determine the risk if a project will be off rails. Early on in my career, a colleague told me, “I do not care where I have been. But I do care where I am going.” The same holds true for project management too.  

Buffer management is an ideal method to determine if a project is going to be off rails in the future. You can only manage buffers if you plan projects “the critical chain way”. In theory, if the rate of consumption of buffers is higher than the rate of project completion, the probability of the project going off the rails has increased significantly. This is the principle behind tracking project status using fever charts. Think about it for a minute.

When you estimate projects at a 50% confidence level, you are in effect estimating at the median completion time. (The median is a statistic and is the center point of a sample. Here is why we estimate with a 50% confidence level.) If actual task completion time is greater than the median time, your project buffer will decrease. If the actual task completion time is less than the median time, then the project buffer will increase. The former will take the actual project closure date to the critical path closure date while the latter will take the actual project closure date to the aggressive date we talked about above.

Let’s look at what the fever chart tells us about the project progress. The black line graph shows the percentage of buffer consumed. The graph is created with the X-axis being % of the project duration completed and the Y-axis as the percentage of buffer consumed. If the rate of buffer consumed is higher than the rate of project completion, you will have the slope of the line greater than 45 degrees and if the rate of buffer consumption is lower than the rate of the project completion you will have the slope of the line less than 45 degrees.

The green, yellow and red zones tell us when to take action. As long as the buffer consumption line graph remains in the green zone, I do not have any reason to worry about missing my project end date. Moreover, if the project completes and the buffer consumption line is still in the green zone, I have just completed the project 67% faster than I would have, if I had used the critical path method.

The buffer consumption line penetration into the Yellow zone signals caution. This tells me that the rate of buffer consumption just got steeper and we may need to review our scope and estimates on future tasks. There is still no need to take action, but let’s be prepared just in case. If your project completes and the buffer penetration line is in the Yellow zone, you have still completed the project 30% faster than the critical path method.

The buffer consumption line penetration in the Red zone means the project is definitely off the rails and corrective action needs to be taken immediately. This may mean that some of the  project tasks were not estimated accurately to begin with. Penetration into the Red zone also could mean scope creep or gold plating. So the causes of the penetration needs to be investigated. There is no sense in engaging in the blame game. Document the lessons learnt fix the estimates and the project (and feeding) buffers if necessary and continue with the project.  Completing the project when the buffer penetration line is in the Red zone means you have completed the project as per the critical path schedule.

This measurement system enabled by critical chain is one of the most important benefits of adopting it. Critical chain planning can also extend beyond one project. The principles here are scalable to Program and Portfolio Management too. Fever charts can be used to track entire program or portfolio. Projects heading towards trouble can be identified and corrective actions taken proactively.

Plan projects using Critical Chain and execute them using Kanban. The question is, “Are you willing to take the necessary steps and change to achieve breakthrough improvements in your project performance?”

Motion photo credit