Focus and Leverage Part 37

Earlier, we explained that in traditional project management we track the progress of the project by calculating the percentage of individual tasks completed and then comparing that percentage against the due date. The problem with this method is that it is nearly impossible to know exactly how much time is remaining to complete the project. Using this method to track progress, many times you’ll see 90 % of a project completed only to see the remaining 10 % take just as long. In fact, looking at the number or percentage of tasks completed instead of how much of the critical path has been completed only serves to give a false sense of conformance to the schedule.

Critical Chain Project Management (CCPM) measures the progress of a project much differently and in so doing allows the project to make valuable use of early finishes. Critical chain uses something called a Fever Chart which is simply a run chart of % of Critical Chain Complete versus % of Project Buffer consumed. Figure 1 is an example of such a chart. In this chart we see that 20 % of the critical chain has been completed while only 8 % of the project buffer has been consumed, thus indicating that this project is actually ahead of schedule. Contrast this with Figure 2 which has completed 26 % of the critical chain, but has consumed 28 % of the project buffer, making it a bit behind schedule.

Figure 1

Figure 2

The green, yellow and red areas of the fever chart are visual indicators of how the project is progressing. If the data point falls within the green area of the chart, the project is progressing well and may even finish early. If the data point falls into the yellow zone, there is cause for concern and a plan on how to move the project forward should be developed, but is not to be implemented just yet. Contrast this with the vertical rise demonstrated in Figure 2 which indicates that buffer is being consumed at too fast a rate relative to how the project is progressing. If a data point falls into the red zone, as demonstrated in Figure 3, then the plan we developed should now be executed. In Figure 3 we see that only 35 % of the critical chain has been completed while almost half (49%) of the buffer has been used.  But even if the entire amount of project buffer is consumed at the completion of the project, the project is still on time and not late. That is, if 100 % of the project buffer is consumed, as long as 100 % of the critical chain has been completed, the project is exactly on time.

Figure 3

In addition to using the fever chart, we also recommend calculating a project index by dividing the % of critical chain completed into the % of the project buffer consumed. As long as this ratio is 1.0 or less, then the project will come in on-time or early. This means that the rate the buffer is being consumed is in step with the progress on the critical chain.  However, if the project index goes beyond 1.0, the project completion date could be in jeopardy.  Figure 3's project index is 1.4 indicating that significant action must be taken on the critical chain to assure an on time completion.

In my next posting I will define how Goldratt’s 5 focusing steps apply to project management and then summarize the key points made in this series of blogs on Critical Chain Project Management.

Bob Sproull

Focus and Leverage Part 36

Earlier we demonstrated how by simply eliminating multi-tasking, significant gains can be made in project completion rates, but we still have to address the impact of the Student Syndrome and Parkinson’s Law. We know that both of these behaviors work to lengthen the time required to complete projects. Remember how excess safety is imbedded into traditional project management plans? Resources estimate task times and add in their own protection against disruptions caused primarily by Murphy. Knowing that this safety exists, resources then delay starting work on their tasks until the due date is close. Even if the resources don’t delay the task starts and finish early, these early finishes are not reported and passed on. So how does CCPM deal with these two behaviors?

While CPM relies on individual task durations as well as scheduled start and completion dates, CCPM does not. The focus is no longer on finishing individual tasks on time, but rather starting and completing these tasks as soon as possible. So how does this work? Like CPM, CCPM still gathers estimates on individual tasks and identifies its own version of the Critical Path. Unlike CPM, CCPM considers competing resources (i.e. the same resource has to work on different tasks) and makes them a part of the critical path. Let’s look at an example of how CPM and CCPM identifies the critical path.

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 tasks isn’t possible until completion of a preceding task. The critical path is important because any delay on the critical path will delay the project correspondingly. Figure 1 is an example of a series of tasks which must be completed in a project with the critical path highlighted in grey. Traditional project management determines the critical path by looking at the task dependencies within the project. Task A2 can only be initiated after A1 is completed. Task B3 can only be performed after completion of B2 and C2 only after C1. Task D1 can only be performed after completion of A2, B3 and C2. Using CPM the critical path would have been identified as C1-C2-D1 and the project completion estimate would have been 29 days (i.e. 8d+12d+9d).

Figure 1

In addition to task dependencies there are also resource dependencies that CPM fails to recognize. What if, in our example, tasks A2 and B3 are performed by the same resource? Is the critical path different? In Figure 2 we see the new critical path that includes a provision for resource dependencies and as you can see the new critical path is 5d+10d+10d+9d or 34 days. So the minimum time to complete this project is now 34 days. In our opinion, the failure to consider resource dependencies is one of the key reasons why project completion rates are so terrible. The simple implication of incorrectly identifying the critical path, which we will now refer to as critical chain, is 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. The practical implication of incorrectly identifying the real critical chain is that the focus will be on the wrong tasks. Is this any different than focusing on non-constraints in our earlier discussion on TOC?

Figure 2

We said earlier that safety is imbedded within each task as a way to guard against the uncertainties of Murphy. Critical Chain takes a completely different approach by assuming that Murphy’s uncertainty will happen in every project. Unlike CPM, CCPM removes these safety buffers within each task and pools them at the end of the project plan to protect the only date that really matters, the project completion date. There are many references that explain the details of how CCPM does this, but here’s a simple example to explain it. Basically we have removed all of the protection from individual task estimates which we estimate to be 50 % of the original estimate. Figure 3 demonstrates the removal of this safety. So now, the length of the critical chain is no longer 34 days, but rather 17 days. But instead of just eliminating the safety buffer, we want to place it where it will do the most good…..at the end of the project to protect the due date. This isn’t exactly how this works, but for presentation purposes to demonstrate the theory behind CCPM it will suffice.





Figure 3

Figure 4 is this same process, but this time the safeties that we removed are added to the end of the project to act as a cushion to Murphy’s inevitable attach. So the question now becomes, how do we utilize this buffer and how does it improve the on-time completion of the project?

Figure 4

Suppose task A2 takes 7 days instead of the 5 days that are in the plan? In a traditional project management environment, this would be cause for panic. In a CCPM environment we simply consume two days from the project buffer and we’re still on schedule. Suppose now, for task B3, we only take 3 days instead of the planned 5 days. We simply add the gain of 2 days back into the project buffer. In traditional CPM, delays accumulate while any gains are lost. This is a significant difference! The project buffer protects us from delays. For non-critical chain tasks, or subordinate chains such as C1-C2 from our example, we also can add feeding buffers to assure that they are completed prior to negatively impacting/delaying the critical chain.

One of the key differences between CPM and CCPM is what happens at the task level. In traditional project management each task has a scheduled start and completion date. CCPM eliminates the times and dates from the schedule and instead focuses on passing on tasks as soon as they are completed, much like a runner in a relay race passing the baton. This function serves to eliminate the negative effects of both the Student Syndrome and Parkinson’s Law from the equation and permits on-time and early finishes for projects. In order for this to work effectively, there must be a way to alert the next resource to get ready in time.

In my next blog posting, we’ll discuss how Goldratt’s 5 Focusing Steps apply to project management and how we track progress on both CPM and CCPM to demonstrate why CCPM offers a much more reasonable way to do so.

Bob Sproull

Focus and Leverage Part 35

In my last blog posting we talked about Parkinson’s Law (i.e. Work expands to fill the available time), the Student Syndrome (i.e. procrastination or delaying work on a task because we know there’s safety time imbedded in our estimate) and multi-tasking (i.e. jumping from one project to the other) and how each one extends the time required to complete projects. Although eliminating multi-tasking improves our on-time completion rate, there are other things that can be done to improve these rates even more? Let’s take a look.

As we’ve seen, in CPM task durations are inflated to protect against Murphy’s untimely attacks. What if we could significantly reduce these imbedded safety buffers and still provide the protection that we need? In our example from Figure 1, suppose we were able to reduce the estimated duration by 50 % and still protect against Murphy. In other words, if we could complete the tasks in 5 days instead of 10 days, wouldn’t this be a quantum leap in project completion time reduction?

Figure 1

Figure 1 is a depiction of the reduction in durations of each project. We have just reduced the time to complete these three projects from 30 days to 15 days, but can we do this and safely guard against the uncertainty introduced by Murphy? The answer is, yes we can! But before we explain how to do this, we want to introduce (or re-introduce to some of you) something called the Theory of Constraints (TOC).

TOC came on the scene in the mid-1980’s through its developer, Eli Goldratt. Goldratt taught the world that every organization has at least one (and usually only one) constraint that prevents an organization from coming closer to its goal. And for most companies, the goal is to make money now and in the future. In fact, Goldratt analogized this concept to the strength of a chain being dictated by its weakest link.

In a manufacturing environment, TOC presumes that only one work station, the one with the least capacity, dictates the throughput of the process and to operate all stations at maximum capacity will only serve to create excess inventory in the process. This excess inventory increases the lead time and wastes resources. The best way to understand TOC is to envision a simple, repeatable process as in Figure 2.

Figure 2

In our example, Step 3 at 7 days is the slowest resource since it requires 7 days to complete it, whereas all of the others require much less than 7 days. Therefore the maximum throughput of the process in Figure 2 is 1 unit of product (or service) every 7 days. TOC identifies Step 3 as the constraint and tells us that if we want to improve throughput, then we must focus our improvement efforts on this step.

The question you might have in your mind right now, is why bring up the Theory of Constraints (TOC) when we’re talking about Project Management. The answer is quite simple. TOC recognizes the existence of a constraint and this recognition in a project management environment is absolutely critical to shortening the time required to complete projects.

TOC teaches us that the first order of business is to define your Goal. In a single project, the goal is identified as making the promised project due date while in a multiple project environment, the goal is to maximize the throughput of projects. So how do Goldratt’s 5 focusing steps apply to project management?

Goldratt’s 5 Focusing Steps:

1. Identify the system constraint.

2. Decide how to exploit the constraint.

3. Subordinate everything else to the constraint.

4. If necessary, elevate the constraint.

5. Return to step 1, but don’t let inertia create a new constraint.

Good question and in my next few postings, I will demonstrate how each of the 5 steps apply to a project management environment as well as introducing TOC’s version of project management, Critical Chain Project Management (CCPM).

Bob Sproull

Focus and Leverage Part 34

So the question I left you with in my last posting remains…..if individual project tasks have so much extra time imbedded in them, then why are so many projects coming in late? We think that this is partially explained by two common human behaviors. Resources know that they have built “safety” into their tasks, so they often delay work on the task until much later than they had originally planned. Think back to your high school days. When you were given a due date for a paper for say, next Thursday, when did you actually start working on it? Wednesday? Eli Goldratt coined the term, the Student Syndrome, to explain one of the reasons why the apparent built-in safety gets wasted. When the task start is delayed and Murphy strikes, the task will be late.

Another human behavior that lengthens projects is referred to as Parkinson’s Law. Resources intuitively know that if they finish a task in less time than they estimated, the next time they have the same or a similar task to complete, they will be expected to finish it early also. So, to protect against this, even thought the task is finished early, the resource doesn’t notify the project manager that it is finished until the original due date. After all, we’re talking about credibility here, so to protect their credibility, early finishes aren’t reported. Parkinson’s Law states that work expands to fill the available time, so resources use all of the available time. The key effect on projects, of these two behaviors, is that delays are passed on, but early finishes aren’t. So is it any wonder that projects are late?

While these two behaviors negatively impact project schedules, there are other reasons why projects are late. Many organizations today have multiple projects going on at the same time and it’s not unusual for projects to share resources. In fact, many project managers tend to “fight over” shared resources because they believe their project is the one that has the highest priority. Another significant problem is that in many project based companies, leadership initiates projects without considering the capacity of the organization to complete the work. Leadership also mistakenly assumes that the sooner a project is initiated, the sooner it will be completed. As a result, perhaps the most devastating problem of all associated with project completion occurs……multitasking! But wait a minute….I thought we’d all been taught for years that multitasking is a good thing?

Multitasking happens when resources are forced to work on multiple project activities at the same time. Like we’ve always said, humans aren’t very good at rubbing their tummy and patting their heads at the same time. Many people believe (especially in leadership positions) that multitasking is a good thing because it increases efficiency since everyone is “busy” all of the time. If you’ve ever to read The Goal by Eli Goldratt (if you haven’t, you should), you might remember how focusing on local activities actually damaged the overall system performance. You may also recall how Goldratt used his robot example whereby running the robots continuously, efficiency did improve, but at the expense of creating lots of excess inventory.

Figure 1



The negative impact of multitasking in a project management environment is much, much worse. Let’s look at an example. Suppose you have three projects (Figure 1) that you are assigned to and in each project you have estimated that you have 2 weeks (10 days) of work on each project for the tasks assigned to you. Assuming Murphy didn’t strike, if you started and finished Project 1 without stopping or working on any other project, it would be done in 10 days. Ten days because that’s what you told everyone it would take (Parkinson’s Law). Likewise for Projects 2 and 3, assuming no other interruptions, each would take 10 days to complete for a total time to complete the three projects of 30 days. But having laid it out like this, if all three projects were scheduled to start on the same day, then Project 1 would be on time at 10 days, Project 2 would be done in 20 days (i.e. 10 days late) and Project 3 would be done in 30 days (i.e. 20 days late).

But can you reasonably expect to work on only one project at a time? Because there are probably three different project managers (i.e. one for each individual project), each one is most likely telling you (or maybe even screaming at you) that they need you to show progress on their project (as you will see later on, CPM reports project progress typically by measuring % of tasks complete). And because you want to satisfy all three managers, you decide to split your time between the three projects (i.e. you multi-task). So as is demonstrated in Figure 2, you start with Project 1 and work on it for 3 days. On the fourth working day, you stop working on Project 1 and begin Project 2 and work on only it for 3 days. On the seventh working day, you stop working on Project 2 and begin working on Project 3. On the tenth day, you stop working on Project 3 and begin working on Project 1 again. You repeat this sequence until all three projects are completed as in Figure 2.

Figure 2

By multitasking, look what’s happened to the time to complete each individual project. Without multi-tasking each individual project took only 10 days to complete and 30 days to complete all three. Without multi-tasking Project 1 was completely in 10 days, Project 2 in 20 days and Project 3 in 30 days. With multi-tasking Project 1 took 28 days, Project 2 took 29 days and Project 3 took 30 days. Both methods completed all three projects in 30 days, but which set of results do you think your leadership would prefer? Also, keep in mind that when you multi-task, there is also time required to get re-acquainted with each project so the multi-tasking times will actually be considerably longer. In fact, some studies have shown that tasks often take 2-3 times their estimated duration when multi-tasking occurs.

So let’s summarize what we’ve learned before we move on. We’ve learned that task time estimates for tasks are artificially lengthened as a protective measure against Murphy and all of the negative baggage he brings to the party. We’ve learned that even though this safety is built in, it is wasted because of the Student Syndrome and Parkinson’s Law. With the Student Syndrome we put off work (i.e. procrastinate) until the last minute, while Parkinson’s Law says that if we’re given ten days to complete a task, that’s how long it will take, even if it is completed earlier. And finally we’ve learned how devastating multi-tasking can be to the completion rate of projects. So what can we do about these three behavioral problems? What if we could significantly reduce these imbedded safety buffers and still provide the protection that we need? In my next blog, we’ll take a look at just that.

Bob Sproull

Focus and Leverage Part 33

In the next several blog postings, I am going to write about Project Management.  Specifically, I'm going to compare the primary method being used today called Critical Path Method to a Theory of Constraints based method known as Critical Chain Project Management.  Most of what you will read here is from a white paper my son John Sproull and I wrote last year. Before I make this comparison though, I want to write briefly about the state of project management in the world today.

In a fairly recent survey (The Chaos Report) by the Standish Group, studying nearly 10,000 IT projects across America, it was reported that 52 % of projects ended up costing greater than 189 % of the original budget, 31 % were cancelled and only 16 % of the projects were completed on time and on budget.

In 2007, a new Chaos Report, revealed that only 35 percent of software projects started in 2006 can be categorized as successful, meaning that they were completed on time, on budget and met the user requirements. Although this was a marked improvement from their first groundbreaking report, it’s safe to say that these statistics still aren’t acceptable or at least where they need to be!

In yet another study done in Australia, construction projects completed only one eighth of building contracts within the scheduled completion date, and that the average overrun exceeded 40%. The fact is, there are many other reports from numerous industry types, from all over the world, that all conclude the same thing, project completion rates are abysmal!

So the question I pose to you is this. What if I could demonstrate a different method that would push your project successful completion rate from where your rate is now to over 90 %? Would you be interested in hearing about it?  I'm assuming many of you would be, so the focus of the next several blog postings is going to be on project management.

Ninety percent of the Project Managers around the world are using a project management method called Critical Path Method (CPM) and have been doing so for many years. If you ask a typical project manager about what factors delayed a completed project, most will tell you that something they didn’t expect or even had no control over cropped up in some of the tasks and delayed them. In other words uncertainty or the Murphy bug bit them! Every project from virtually every environment has uncertainty associated with it and how this uncertainty is dealt with determines the ultimate success or failure of the project. So in order for a project to be successful, doesn't it make sense that there must be a way to protect it from uncertainty. Let’s take a look at how traditional project management (CPM) protects a project from uncertainty.

CPM uses a “fudge factor” to protect projects from inevitable uncertainty. That is,when developing the project plan, durations for each individual task are estimated by the resources responsible for executing them and then a safety factor is added to each of the tasks by the resource responsible for completing them. For example, suppose the realistic estimate of time for an individual task is one week. Is one week what the resource actually tells his or her project manager? Typically the resource will add a safety factor of their own to guard against “things” that might happen to cause a delay in the completion of the task. So it’s not unusual for the original one week to be quoted as two weeks. Resources react this way because they know from experience, that as soon as they give the project manager an estimate, it automatically becomes a commitment!

A typical project manager will then add up all of the individual, inflated time estimates and then add his or her own safety factor. Why is this done? Project Managers know that at some point in the project Murphy will strike and some of the tasks will be delayed, so they too add a safety factor to protect the project from being late. Keep in mind that every resource inflates every task, so it’s not uncommon for the estimated duration to be greater than 50 % greater than it takes to actually complete the task. So with all of this built-in safety, the project should be completed on time….right? So it seems, but the statistics on project completions don’t bear this out. We’ll explain why later.

In traditional project management PM) how do you track progress against the completion date? The typical method involves calculating the percentage of individual tasks completed and then comparing that percentage against the due date. Sounds reasonable, but is this the right way to track progress? The problem with using percentage of tasks completed is that not all tasks have the same duration. That is, comparing a task that has an estimate of one day to a task that should take one week is not a valid comparison. Compounding this problem is the mistaken belief that the best way to ensure that a project will finish on time, is to try to make every individual task finish on time. This too sounds reasonable, but later on we’ll show you why this isn’t so.

Why are so many projects being finished late?  In my next blog posting I'll discuss the human behaviorial reasons why this phenomena (i.e. late projects) might be happening.

Bob Sproull