Focus and Leverage Part 107

In the past several weeks I’ve been getting lots of emails about Project Management (PM) and specifically how the Theory of Constraints handles this subject.  And although I’ve had a similar posting in the past, because of all the inquiries on this subject I’ve decided to create a new entry.  So let’s first look at some published statistics on the state of projects around the US and world and then take a look at the most common project management technique used in the world today.

If yours is an organization that relies on project completions as their primary source of revenue and you’re like many other project based organization, then the results of multiple surveys by an organization called the Standish Group¹ might be of real concern to you.  Back in 1994 the Standish Group conducted a landmark study (entitled the Chaos Report) 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.  The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are probably immeasurable, but could easily be in the trillions of dollars.  Pretty scary figures if project execution is your business model aren't they?

Now let’s fast forward thirteen years to 2007 to the “new” Chaos Report⁵ which revealed that only 19 % of projects begun were considered outright failures and were cancelled, compared to the 31% reported in 1994. In addition, 35 % of software projects started in 2006 can be categorized as successful, meaning they were completed on time, on budget and met user requirements.  Although this is a marked improvement from their initial groundbreaking report, it’s safe to say that these statistics still aren’t acceptable or at least where they need to be!  The point is, project failure rates appear to be a universal problem spanning virtually all industry types and although the success rates are improving, they still don’t rise up to an acceptable level.

As I write this posting, about 90% of the Project Managers around the world are using a project management methodology known as the 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, there must be a way to protect it from uncertainty.  So let’s take a look at how traditional project management (CPM) attempts to protect a project from inevitable uncertainty.

CPM uses a sort of “fudge factor” in an attempt the completion date of projects.  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?  The answer is no!  Most of the time the resource will add his or her own safety factor 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.  They do this because they know from past experience that as soon as they give the project manager an estimate, it automatically becomes a commitment!  So with all of this built-in safety, you would think that the project should always be completed on time….right?  So it would seem, but the statistics on project completions that we just saw paint a much different picture.

Ok, so if individual project tasks have so much extra time imbedded in them, then why do you suppose that so many projects coming in late?  It’s my opinion, and that of many others, that these completion failures are at least partially explained by two very common human behaviors.  Since the resources who gave the padded estimates know that they have built “safety” into their tasks, they often delay or procrastinate work on the task until much later than they had originally planned simply because they know they can.  It’s a common behavior and if you 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?  The late Dr. Eli Goldratt 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 typically be late because the built in safety was wasted through procrastination.  Ok, so what else negatively impacts project completions?

Another common human behavior that extends projects and causes them to be late is something called 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 again.  So to protect against this, even when a task is finished early, the resource doesn’t notify the project manager that it is finished until the original due date is reached.  We’re talking about personal credibility here, so to protect it, early finishes aren’t reported.  Parkinson’s Law states that work expands to fill the available time so if the resource has one week to finish a task, the entire week is taken to finish it.  The key effect on projects of these two behaviors is that delays are passed on, but early finishes are not.  So with just these two behaviors in play, is it any wonder that projects are late?

While these two behaviors do negatively impact project schedules, they aren’t the only reasons why projects are late.  Most organizations today have multiple projects going on at the same time and it’s not unusual for all of the projects to share common resources.  In fact, many project managers tend to “fight over” these shared resources because they believe that their project is the most important one or the one that has the highest priority.  Another problem is that in many project based companies, leadership continually pushes new projects into the system 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……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 really bad!  So is there a difference between good and bad multitasking?  In my opinion, I simply don’t like multitasking of any kind because it extends the time required to complete all tasks.  I believe it’s more effective to start a task and complete it or take it to a logical stopping point before you start another one.

Quite simply, bad multitasking happens when resources are forced to split their time between multiple projects.  Many leaders mistakenly believe that multitasking is a good thing because it increases efficiency.  In their minds, since everyone is “busy” all of the time the organization is more efficient.  Those of you that follow my blog on a regular basis know how I feel about this performance metric!  The bottom line is that using efficiency to measure performance quite simply encourages exactly the wrong behaviors no matter what industry!  It only encourages people to look busy, so the negative impact of bad multitasking in a project management environment becomes much, much worse.  So to demonstrate this, let’s look at an example.

Suppose you have three projects (see Figure 1) that you’re working on simultaneously.

Figure 1

On each project you estimated that it would take you 2 weeks (10 days) to complete 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 should be done in 10 days.  Ten days because that’s how long you told everyone it would take (Parkinson’s Law).  But having laid it out like this, if all three projects were scheduled to start on the same day, then Project 1 would be completed on time at 10 days. But because you only worked on Project 1 for the past 10 days, Project 2 would now be done in 20 days, making it 10 days late. Similarly, Project 3 would be done in 30 days and would be 20 days late.  Unfortunately CPM doesn’t usually work like this in a multi-project environment, something else takes place…..bad multitasking!   Let’s see what this looks like.

Because there are probably three different project managers involved here, each one is most likely telling you (or maybe even screaming at you) that they need you to show some progress on his or her project because in CPM, projects are typically measured by % of tasks completed versus some due date.  Because you want to satisfy all three managers, you decide to split your time between the three projects (i.e. you’re guilty of bad multitasking).  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 begin Project 2 and work on only it for 3 days.  You repeat this sequence until all projects are completed.  Let’s see what that looks like graphically in Figure 2.

Figure 2

By using bad multitasking look what’s happened to the time to complete each individual project.  Without bad multitasking, Project 1 was completed after 10 days, but with bad multitasking Project 1 has now taken 28 days, a full 18 days later than without multitasking!!  Project 2, which was originally completed in 20 days, is not completed until day 29, 9 days later than with multitasking!  Project 3 which originally took 30 days to complete, again is finished at the same 30 day mark.  Both methods completed all three projects in 30 days, but which set of results do you think your leadership would prefer?  Having two projects done in 20 days and the third one at the 30 day mark or the results of bad multitasking?  Also keep in mind that when you are guilty of bad multitasking, there is also time required to get re-acquainted with each project so the multitasking times will actually be considerably longer.  In fact, some studies have shown that this getting re-acquainted time on projects often pushes out their duration by 2-3 times their estimated duration in the presence of multi-tasking.

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 procrastinate by putting off work until the last minute, while Parkinson’s Law says that if we’re given ten days to complete a task, that’s the shortest period of time it will take to complete, even if it is completed earlier.  We’ve learned that delays are passed on, but early completions are not.  And finally we’ve learned how devastating bad multitasking can be to the completion rate of projects and if we could eliminate it, we know our on-time completion rate will improve.

In my next blog posting, we’ll complete our discussion on CPM and then I’ll show you a different way to run projects that typically raises the on-time completion rates in excess of 90%.

Bob Sproull

References:

 

1.  THE STANDISH GROUP REPORT © The Standish Group 1995. Chaos Report.

2.  The Standish Group Report © The Standish Group 2007.