Focus and Leverage Part 346

This is the fourth and final posting in this series on what I intended to write about when I first started this blog in late 2010.  In my last posting, I told you that on this posting I would discuss TOC’s version of a project management method that delivers projects on-time (or earlier), on-scope, and on-budget.  For those of you who work in an organization that delivers projects for their source of income, such as the construction industry, this post should be of interest to you.

In most project environments, resources are clearly working as hard as they can, but unfortunately many times the projects they are working still end up being late, over-budget and the deliverables or scope are often compromised because of these extended lead times and budget over-runs.  Many companies, who rely on project completions as their source of income, are using a method referred to as the Critical Path Method (CPM). Constraints Management uses a drastically different method referred to as Critical Chain Project Management (CCPM) which when implemented typically results in project durations often being 30-50% shorter than CPM's, with on-time completion rates reaching 95% or even greater.  Typically, with CCPM, projects not only finish on-time, but also finish on-scope and on or under budget.  So what’s the difference between these two methods and why does CCPM deliver such superior results?

I think the best way to describe the difference between these two methods is by discussing the two completely different approaches.  One significant difference is that CCPM takes into account both task and resource dependencies.  CPM, on the other hand, does recognize task dependencies, but does not consider resource dependencies and this is a very significant difference.  As a result, CPM's Critical Path looks much different than CCPM's Critical Chain.  Although this may seem like a small difference, in reality it is a major difference.

Another of the major differences is in the planning and structure of CCPM versus CPM.  Both CPM and CCPM begin their plans by listing each task with a beginning and ending date for each (i.e. task durations).  Typically, when resources are asked how long each task will take to complete, the resource automatically adds in a safety margin of time to protect the task due date (and their own personal credibility).  Often times this “safety” is double the amount time that is actually required to complete the task.  CPM relies on starting and completing these tasks per the planned schedule as a means of attempting to assure that projects will be completed on time.  As you will see, this is a very significant difference between CCPM and CPM.

Unlike CPM, CCPM, does not utilize start and stop dates in its plan.  Instead, CCPM sums the individual tasks times (which are inflated just like CPM’s) and then removes half of the sum of the task times  and places the removed time into a project buffer at the end of the schedule.  The project buffer acts just like a bank account with deposits and withdrawals.  When a task is finished ahead of schedule, time is added into the buffer and when a task completion is later than expected, time is removed (borrowed) from the project buffer.

CPM relies on the stated task start and completions dates to monitor progress.  But even if a task is completed early, the early completion is never passed on.  Rather, the task is held until the scheduled due date and then passed on so to protect the credibility of the resource who estimated it.  The result of holding the completed task is that early finishes are not passed on, but task delays are.  CCPM counters this by using the relay runner ethic, in that as soon as a project task is completed, it is passed on to the next resource to begin their work.  This difference in method positively impacts the speed of completion of CCPM projects.

There are also three behavioral problems that are associated with CPM that simply don’t come into play in a CCPM project environment.  The first behavior problem is Parkinson’s Law, which states that work expands to fill the available time.  If a task is scheduled to take one week, the resource will definitely use the full week.  The reason being that if, in the future a project has a similar task, in the resource's mind, they will be expected to complete it in the same amount of time.   The second behavioral problem is referred to as the Student Syndrome.  Because this extra safety is built into each CPM task, the task start is many times delayed because the estimating resource knows the safety is available.  And when Murphy strikes, delays will definitely occur because the safety has been wasted. The third problem is “bad” multitasking.  This problem occurs when the same resource is assigned to work on multiple projects at the same time.  If this is the case, the resource will split their time between projects by working on one project, then stops to work on another one and then returns to the first one.  Remember, CPM does not consider resource contentions.

CCPM overcomes these three behavioral problems by eliminating excess safety times and adding it to the aforementioned project buffer and removing individual task durations and applying the relay runner work ethic.  That is, the resource notifies the next resource of the estimated completion time of the task and passes it on immediately to the next resource.  The result of this action is that, unlike CPM, early finishes are passed on.  This action eliminates Parkinson's Law and the Student Syndrome.


CCPM eliminates bad multitasking by scheduling resources based upon project requirements.  That is, CCPM will actually delay the start of a new project to accommodate conflicting resource requirements.  To this point, CPM users believe that to complete projects sooner, they must be started sooner, but this is not a valid assumption.  CCPM users believe that in order to complete projects sooner, they must be synchronized which means that sometimes project starts are delayed.

Because of these differences in methods, CCPM has a much superior on time completion rate, often greater than 95%.  In addition, CCPM’s projects are nearly always completed on-budget with the original project scope completed.  In my experiences using CCPM, I have actually observed up to a 70% reduction in the time required to complete projects when compared to CPM.

Before I close, I want to summarize what we’ve said in this series of postings.  Constraint Management operates at many levels when compared to other management methodologies.  It is a tool for global systems optimization rather than local optimization.  Constraints Management (CM) includes a simple 5-step process of on-going improvement and a set of six Thinking Process tools that can be used at the system or process level to identify the true core problem(s) within an organization and then demonstrates how to develop and implement effective solutions.  Constraints Management also offers a simple and easy to use, real time financial accounting system (i.e. Throughput Accounting) that improves managers decision ability.

Substantial benefits of Constraints Management are typically realized much faster and are sustainable, especially when the goal of the organization is to make more money now and in the future.  Improvements in manufacturing lead time are often realized in the 60-70% range with inventory reductions in the neighborhood of 50%.  In project management environments, project completion times often shrink by as much as 40-50% with on-time completion rates of 95% not being uncommon.  In addition, most projects finish on-scope and on or under budget.  Constraints Management also offers a solution for parts replenishment as well, which typically results in a 40-50% reduction in inventory while at the same time virtually avoiding stock-outs.

Finally, when Lean and Six Sigma are combined with Constraints Management, enhanced process optimization is the end result.  My own experience as well as independent studies have demonstrated the superiority of this integrated approach to continuous improvement.

Bob Sproull