So the question I left you with in my last posting remains…..if individual project tasks have so much extra time imbedded in them, then why are so many projects coming in late? We think that this is partially explained by two 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 say, next Thursday, when did you actually start working on it? Wednesday? Eli Goldratt coined the term, the 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.
Another 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 they estimated, the next time they have the same or a similar task to complete, they will be expected to finish it early also. So, to protect against this, even thought the task is finished early, the resource doesn’t notify the project manager that it is finished until the original due date. After all, we’re talking about credibility here, so to protect their credibility, early finishes aren’t reported. Parkinson’s Law states that work expands to fill the available time, so resources use all of the available time. 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. Another significant problem is that in many project based companies, leadership initiates projects 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……multitasking! But wait a minute….I thought we’d all been taught for years that multitasking is a good thing?
Multitasking happens when resources are forced to work on multiple project activities at the same time. Like we’ve always said, humans aren’t very good at rubbing their tummy and patting their heads at the same time. Many people believe (especially in leadership positions) that multitasking is a good thing because it increases efficiency since everyone is “busy” all of the time. If you’ve ever to read The Goal by Eli Goldratt (if you haven’t, you should), you might remember how focusing on local activities actually damaged the overall system performance. You may also recall how Goldratt used his robot example whereby running the robots continuously, efficiency did improve, but at the expense of creating lots of excess inventory.
But can you reasonably expect to work on only one project at a time? Because there are probably three different project managers (i.e. one for each individual project), each one is most likely telling you (or maybe even screaming at you) that they need you to show progress on their project (as you will see later on, CPM reports project progress typically by measuring % of tasks complete). And because you want to satisfy all three managers, you decide to split your time between the three projects (i.e. you multi-task). 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 stop working on Project 1 and begin Project 2 and work on only it for 3 days. On the seventh working day, you stop working on Project 2 and begin working on Project 3. On the tenth day, you stop working on Project 3 and begin working on Project 1 again. You repeat this sequence until all three projects are completed as in Figure 2.
By multitasking, look what’s happened to the time to complete each individual project. Without multi-tasking each individual project took only 10 days to complete and 30 days to complete all three. Without multi-tasking Project 1 was completely in 10 days, Project 2 in 20 days and Project 3 in 30 days. With multi-tasking Project 1 took 28 days, Project 2 took 29 days and Project 3 took 30 days. Both methods completed all three projects in 30 days, but which set of results do you think your leadership would prefer? Also, keep in mind that when you multi-task, there is also time required to get re-acquainted with each project so the multi-tasking times will actually be considerably longer. In fact, some studies have shown that tasks often take 2-3 times their estimated duration when multi-tasking occurs.
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 put off work (i.e. procrastinate) until the last minute, while Parkinson’s Law says that if we’re given ten days to complete a task, that’s how long it will take, even if it is completed earlier. And finally we’ve learned how devastating multi-tasking can be to the completion rate of projects. So what can we do about these three behavioral problems? What if we could significantly reduce these imbedded safety buffers and still provide the protection that we need? In my next blog, we’ll take a look at just that.