Saturday, March 29, 2014

Focus and Leverage Part 329

In this posting, I’m going to discuss how we explained a new form of Project Management known as Critical Chain Project Management (CCPM) and how we were able to differentiate it from the Critical Path Method (CPM).  We’ll also discuss how the results of this new method significantly impacted the completion rates of projects and delve into the financial impact of this implementation.

As a refresher, we said that CPM task durations are inflated to protect against Murphy, but what if there was a way to signifi­cantly reduce these imbedded safety buffers and still be able to pro­vide the protection from Murphy that we need?  Using my example from Part 328, suppose we were able to reduce the estimated duration by as much as 50 fifty percent and still protect against Murphy. Does that sound like a significant reduction?  You may be thinking that, if this contractor was already late on projects with all of this built-in safety, how in the world would reducing these durations result in better pro­ject on-time completion rates?  What I’m proposing is that on my example from Part 328, we said that we had three projects each with an estimated duration of nine days. Referring to the drawing below, using CCPM, I’m suggesting that each project will now take only four and a half days and the total time to complete all three projects would theoretically be thirteen and a half days.


It was a daunting task to convince this contractor’s leadership that we could reduce their imbedded safety by a factor of 50 percent and still safely guard against the uncertainty introduced by Murphy.  In order to convince the contractor that this was indeed possible, I found it necessary to refresh their minds a bit on the Theory of Constraints.  Specifically, I presented the piping diagram and the simple four-step process that I presented to them during their initial training on TOC.  For you first timers to my blog, the figures below are what I am referring to here.

Our CI Team asked the leadership team to tell us what was the key to improving throughput in both of those drawings and they correctly stated that they would have to identify the constraint and then exploit it.  We also asked them to tell us how they would prevent a WIP explosion in the process, and they correctly told us that it would be necessary to subordinate everything else to the constraint.  We then asked them whether or not reducing cy­cle times at non-constraints was a fruitless exercise to which they told us that they should only focus on the system constraint and that it should never be idle. This was very important for them to understand because of how CCPM works.  In other words, we wanted the existence of a constraint to be foremost in their minds as we moved on.



Next, we asked leadership to tell us what the constraint was in their maintenance projects.  After careful deliberation, only one person raised their hand and explained that in a project, it’s not the longest task necessarily that is the constraint, but it’s probably the longest set of sequential tasks, where one task is de­pendent upon another and that this series of interconnect­ed tasks is probably the constraint.  This was a correct answer, so we explained that this series of dependent tasks is actually referred to as the critical path which in CPM is, in fact, the constraint.  We needed them to understand this concept so that when we presented the concept of CCPM, they would see that it too is the constraint, but that it’s very different than CPM’s Critical Path.

In Focus and Leverage Part 328, I presented two behaviors known as the Student Syndrome and Parkinson’s Law and how both of these behaviors work to extend the time required to complete a project.  I explained that with CPM, plan­ning resources estimate individual task times and then add in their own protection against disruptions caused primarily by Murphy. And then the effects of Parkinson’s and the Student Syndrome waste most of the safety that has been added.  So the question our implementation team had to explain was, how does CCPM deal with these behaviors?

We explained that while CPM relies on individual task durations as well as sched­uled start and finish dates, CCPM does not.  The project focus is no longer on finishing individual tasks on time, but rather completing tasks as soon as possible.  Like CPM, CCPM still gath­ers estimates on individual tasks and identifies its own version of the critical path that is referred to as the Critical Chain. However, unlike CPM, CCPM also considers the com­peting resources and includes them as part of the critical chain. We then presented an example of this new way of looking at projects as depicted in the following figure.

As I explained earlier, CPM defines the critical path as the longest path of dependent tasks within a project. That is, tasks are dependent when the completion of one task isn’t possible until the completion of a preceding task.  Any delay on the critical path will delay the project correspondingly.  In this figure, the critical path is highlighted according to the CPM method.  It’s important to remember that CPM determines the critical path by looking at the task dependencies within the project.  So using CPM, the critical path would be C1-C2-D1, and the project completion estimate would be the sum of those days, or twenty-nine days.  We wanted to draw a distinction between CPM and CCPM, so it was important for the contractor’s leadership to understand their existing methodology.

One of the shortcomings of CPM is the failure to consider or recognize the existence of resource dependencies, so what if, in our example in the above figure, tasks A2 and B3 are performed by the same resource?   Would the critical path be different?  Since A2 and B3 are done by the same resource, they can’t both be done at the same time. Because of this dependency, we have to move B3 to begin after the same resource completed A2.  So the new critical path would be A1-A2-B3-D1 and the new project estimate increases from the original twenty-nine days to thirty-four days as seen in the figure below.


So the question now becomes, what does the recognition of resource dependencies do to the on-time completion of this project?  It means that without considering resource de­pendencies, using CPM, the project is guaranteed to be late!  This simple consequence of incorrectly iden­tifying the critical path—which we now refer to as the critical chain—is that the project team will never be able to complete their project on time without heroic efforts, adding additional resources, overtime or a combination of all three. In presenting these project drawings, it was now evident to the contractors leadership that the practical implication of incorrectly identifying the real critical chain is that the focus will be on the wrong tasks which is really no different than focusing on non-­constraints in a production process, right?  This explanation made it easy to see why the contractor’s projects are late so often.

One of the leaders then said that "There seems to be a problem that when we add resource dependencies to the project, it will actually lengthen the project completion time, and that’s not what we want…..we want to shorten them."  We then asked leadership what they thought we had to do to shorten the project time?  None of them had an answer.  Remember earlier how we said that excessive safety is imbedded within each task as a way to guard against the uncertainties of Murphy?  CCPM takes a completely different approach by assuming that Murphy’s uncertainty will happen in every project and unlike CPM, CCPM actually removes these safeties within each task and pools them at the end of the project to protect the only date that really matters, the project completion date.  In other words, instead of protecting the task due dates, we shift our thinking to protecting the project due date and there is a significant difference.
In my next posting we'll dive deep into Critical Chain Project Management (CCPM) and discuss why it is so superior to the Critical Path Method (CPM).
Bob Sproull

No comments: