Manufacturing Breakthrough Blog

The Fudge Factor in Today's Most Common Project Management Method

Friday December 18, 2015


In my last post I presented you with some pretty horrifying project management statistics developed by the Standish Group [1], [2].  They explained the results of a  study of nearly 10,000 IT projects across America and found 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.  Another study was reported from 2006 and although the statistics had improved, the results were still not acceptable.  In today’s post, we’ll dig deeper into the most common project management method in use today, the Critical Path Method (CPM).


The Critical Path Method (CPM)

In order for any project to be successful, there must be a way to protect it from inevitable uncertainty.   The Critical Path Method (CPM) does so by using a “fudge factor.”  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 task by the resource responsible for completing it.

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 that would delay 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.  Project Managers know that at some point in the project Murphy will strike and some of the tasks will be delayed.  So the Project Manager adds his own 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 fifty percent 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.  The reason will be explained shortly.  In traditional project management tracking, the progress of the project is typically done so by calculating the percentage of individual tasks completed compared 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 equal duration estimates.  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 shortly I’ll show you why this isn’t so.

So the question remains…..if individual project tasks have so much extra time embedded in them, then why are so many projects coming in late? My belief is that this is partially explained by two very 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 Thursday, when did you start working on it?  How about Wednesday night?  Dr. Eli Goldratt [3] coined the term, 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 because the built in safety was wasted through procrastination.

The other human behavior that lengthens projects is referred to as Parkinson’s Law or “work expands to fill the available time.”  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.  So to protect against this, when a task is finished early, the resource waits and then notifies the Project Manager that it is finished on the task’s original due date.  After all, we’re talking about credibility here, so to protect it, early finishes aren’t reported.

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.


Next Time

In my next post we’ll continue our discussion on the problems related to the CPM method that are causing such horrific statistics.  As always, if you have any questions or comments about any of my posts, leave me a message and I will respond. 

Until next time.

Bob Sproull


  1. THE STANDISH GROUP REPORT © The Standish Group 1995. Reprinted here for sole academic purposes with written permission from The Standish Group. CHAOS.
  2. The Standish Group Report © The Standish Group 2007
  3. Goldratt, Eliyahu M. Critical Chain (North River Press, MA, 2002)

Categories :

Leave a Comment (Please Log In First)