Maximizing Profitability Part 30

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 several years ago. 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.