Focus and Leverage Part 328

Continuing on with our Case Study on Critical Chain Project Management we will delve into some of the behaviors that must be overcome in project environments as well as the basics of project management as it relates to CPM and CCPM.

As I alluded to in my last posting, Critical Path uses a fudge factor to protect pro­jects from inevitable uncertainty. When project plans are developed, durations for each individual task are estimated by the resources that are responsible for executing them.  And as I said earlier, a safety factor is added to each task by the person responsible for completing it. For example, suppose a realistic estimate of time for an individual task is one week.  Is one week the amount of time the resource actually tells the project manager? No, typically, the resource will add in his own personal safety factor to guard against “things” that might happen that would delay comple­tion of the task.  So it’s not unusual for 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!  And because the project manager wants to protect his/her reputation, the project manager adds his or her own fudge fac­tor.  The project manager adds up all of the in­dividual, inflated time estimates, and then adds his or her own safety factor.  So if this is what happens, then why with all of this extra safety imbedded are the projects still coming in late?

As I’ve reported on numerous occasions on my blog, the way people are measured predictably determines their behavior and project management is no different.  In traditional project management projects, progress is tracked by calculating the percent­age of individual tasks completed and then comparing the 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, so that com­paring a task that has an estimated duration of one day to a task that should take one week is an invalid comparison. Com­pounding 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 in­dividual task finish on time.  This probably sounds like a reasonable approach, but as you’ll see later on, it just isn’t so.

So with all of this imbedded safety, why are projects late such a high percentage of time?  As the contractor found out, this phenomenon is explained to a large degree by two common human behaviors. Think back to your old high school days. When you were given a homework assignment on Monday to write a paper by Thursday, when did you start working on it?  Wednesday night?  Dr. Eli Goldratt coined the expression, the Student Syndrome, to ex­plain why much of the imbedded safety gets wasted.  Because the person responsible for completing the tasks knows the safety is there, he or she procrastinates on starting the task. And then when Murphy strikes, the task becomes late.

 

The other 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 the estimate they gave, then the next time they have the same or similar task to complete, they will be expected to finish it early again.  So instead of notifying the project manager when they do finish a task early, they wait until the due date to do so. Parkinson’s Law states that work expands to fill the available time.  We’re talking about the personal credibility of the resources that provided the task-time estimate here, so to protect it, early finishes are not reported.  So the impact of these two behaviors on project completions is that delays are passed on, but early finishes are not. So is it any wonder that this contractor’s projects were coming in late?

These two behaviors aren’t the only reasons why projects are typically late in organizations using CPM.  Many organizations like this contractor have multiple projects, and there is competi­tion for shared resources.  In fact, it was not uncommon for this contractor’s project managers to ‘fight’ over these shared resourc­es because leadership held them accountable for completion accord­ing to schedule.  Leadership in these environments initiates projects without con­sidering the capacity of the organization to complete the work.  They also mistakenly assume that the sooner a project is initiated, the sooner it will be completed, so they push more projects into the mix.  After all, everyone knows that the sooner you start a project, the sooner it will be completed . . . right?  As a result of these actions by the contractor’s leadership, the most devastating problem of all associ­ated with project completions occurred—multi-tasking!”  I know, I know you’ve always been taught that being able to multitask was a good thing.  Let’s look at multitasking in a little more depth.

Multitasking happens when resources are forced to work on multiple project activities at the same time. So let’s look at an example of the impact of multitasking that this contractor was experiencing.  Suppose, for example, you have three projects that are assigned to move through your system, and each project has a time estimate of nine days.  Each project manager has developed his or her own schedule in isolation of the other two, and each project has the same, or a similar, start date, so each project manager will assume their project only takes nine days to complete.  But what happens if  each of these projects must use the same shared resources to reach completion?  All three can’t begin on the same day because there just isn’t enough capacity.  If there is pressure from all three project managers to show some progress on their project, what do the shared resources have to do?  Since the shared resource wants to satisfy all three project managers, he or she probably ends up splitting their time between the three projects.  Graphically this looks like the figure below.

Since you want to satisfy all three project man­agers, you probably end up splitting your time between the three pro­jects which would look like the following figure.

The shared resource splits time between the three projects, first working on Project 1 for three days, then Project 2 for three days, and finally Project 3 for three days,  Then  it’s back to Project 1 for three days and so on.  Assuming all of these projects were scheduled to begin on or near the same start date, with the multitasking rule now being enforced, Project 1 now takes twenty-one days to complete instead of nine days.. Project 1 started on time, but eventually finishes twelve days late because of the perceived need to also work on the other two projects. Project 2 now takes twenty-four days to complete instead of the planned nine days, and Project 3 takes twenty-seven days to complete.. One other thing that we didn’t take into account was the time lost having to reacquaint yourself with each project. By that I mean, the shared resource has to review where they left off before they can start working on a project again. And based on my experience, this adds a significant amount of time to each project.

 

So let’s summarize what the contractor learned so far before we move on.  The contractor learned that time estimates for tasks are arti­ficially lengthened as a protective measure against Murphy and all of the negative baggage he brings to the party. They also learned that even though there is a huge amount of safety built in, most of it is wasted because of the Student Syndrome and Parkin­son’s Law. With the Student Syndrome we put off work until the last minute while with Parkinson’s Law, if we’re given ten days to complete a project, that’s the best case scenario on how long it will take, even if it is completed earlier.  And finally, the contractor learned how devastating multitasking can be to the completion dates of projects, and how if they could eliminate it, then their on-time completion rates would improve dramatically.  And although all of this is true, there are still other things that the contractor could do to sig­nificantly reduce the time they take to complete projects.  This includes using Lean to reduce the amount of waste that exists within the project tasks or Six Sigma to make their project more repeatable.  So what actually happened to this contractor’s project completion rate?

 

In my next posting, we’ll get into what actually took place to significantly reduce the project times which translated into significantly better on-time completions.  We’ll also look at what happened to the financial picture of this contractor.

 

Bob Sproull