Monday, October 14, 2013

Focus and Leverage Part 259

In this posting we will continue to dissect the most common methodology to execute projects, the Critical Path Method.  Again, I want to thank Bruce Nelson and my son John for writing much of what is to be posted in the next 4 or 5 postings.

CPM attempts to guard against uncertainty by using a sort of “fudge factor.”  In the early stages of project planning, durations for each of the individual tasks are estimated by those resources that are responsible for executing them.  These same resources then add a safety factor to each task duration, in order to protect the task from the inevitable and unknown sources of uncertainty.  For example, suppose the realistic estimate of time for an individual task is one week.  Typically the resource will add his or her own safety factor of their own to guard against “things” that might happen that would delay completion of the task.  So, for example, 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 that they must meet!

A typical project manager then adds up all of the individual, inflated time estimates and add his or her own safety factor.  Why is this done?  Project Managers know from experience that at some point in the project Murphy will strike and some of the tasks will be delayed, so to counter this, they 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 in the neighborhood of 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.

In traditional project management tracking (CPM), the progress of the project is typically done so by calculating a percentage of individual tasks that have been completed and then comparing that percentage against the due date.  For example, if there are 200 individual tasks assigned to a project and 180 of them have been completed, then the project is 90% complete.  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.  By that I mean, comparing a task that has an estimate of one day to a task that should take one week to complete is an invalid 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 you will see why this isn’t so.

So if individual project tasks have all of this extra time imbedded in them, then why are the projects coming in late?  This is partially explained by two, very common human behaviors.  The project resources know that they have built in this “safety” into their tasks, so knowing this, work on their tasks can be delayed and they’ll still have time to complete their tasks on time.  Remember 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?  Wednesday?  Or you knew you had a test scheduled for Friday, when did you actually start studying for it? Thursday?  Dr. Goldratt coined the term, Student Syndrome, to help explain these behaviors as to why the apparent built-in safety gets wasted.  It’s called procrastination.  When the task start is delayed and Murphy strikes, the task will be late because the built in safety was wasted through this procrastination..

The other human behavior that lengthens projects is referred to as Parkinson’s Law.  Parkinson’s Law is defined as work expands to fill the available time.  Resources instinctively know that if they finish a task ahead of its scheduled due date, then 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 doesn’t notify the project manager until the original due date.  The resources’ credibility is on the line here, so to protect it, early finishes are never reported.  The key effect on projects of this behavior is that delays are passed on, but early finishes aren’t.

While these two behaviors clearly negatively impact project schedules, there are other explanations as to why projects seem to always come in late.  If you’re like many organizations today, you 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” these shared resources because they believe that their project is the one that is most important.  At the same time, there is a belief that the sooner a project is started, the sooner it will be completed.  The result of this thinking is that projects are “pushed” into the fray without considering the capacity of the organization to complete the work.  As a result of these two actions, conceivably the most devastating problem of all associated with project completion occurs……bad multitasking!  But wait a minute….I thought we’d all been taught for years that multitasking is a good thing?  Good multitasking is good, but bad multitasking is not.

In my next posting we’ll talk more about bad multitasking and continue our comparison of CPM and CCPM.
Bob Sproull

No comments: