« Three Expectations of Servant Leadership
The Clash of the Priorities »

Three Common Project Schedule Killers

July 18, 2012 | Author: PM Hut | Filed under: Scheduling

Three Common Project Schedule Killers
By Preben Ormen

Project planning and scheduling is a tricky thing at the best of times and even experienced project managers can run into problems here. The difference is that they just don’t end up in the mierda quite as often as others because they know about the three most common schedule killers and how to deal with them. While this does not guarantee a risk free schedule, it does take the edge off in a major way.

The three most common schedule killers we all run into in our projects are as follows:

  1. Student Syndrome
  2. Parkinson’s Law
  3. Multitasking

Before we jump into the details, let me first lay out the context for the analysis and the examples.

Let us assume we have a simple project with 10 sequential tasks, each of the same expected duration. Assume further that:

  • We know the distribution of expected outcomes for each task.
  • The task duration distributions are independent and identical.
  • These distributions can be modeled with the triangular distribution.
  • The most optimistic (shortest) task duration is 10 days.
  • The most likely task duration is 15 days.
  • The most pessimistic (longest) task duration is 25 days.

A Monte Carlo simulation of this, our base case, shows that we can have 100% confidence that this simple project can be completed in the range of 129 to 211 days. (What surprises many when they see this kind of simulation is that we only have 15% confidence that we can complete this project in 150 days, the sum of the most likely estimate (15 days) for the 10 tasks.)

The reason we end up with a range of 129 to 211 days is the effect of risk pooling (what insurance companies do). That said, the result is based on some key assumptions, namely that each task starts as soon as the previous one is completed and that the assigned resources (i.e., people) only charge time for time time worked (i.e., if allotted time is 25 days and time worked is 15, then the charge will be only 15 days).

As we shall see, these are not at all robust assumptions. So, let’s get to it.

Student Syndrome

The Student Syndrome refers to a familiar behaviour pattern where students (and in real life many others, including project team members) wait till the last minute to start an assigned task. Another name for Student Syndrome is procrastination.

This means that:

  • Even if additional time is requested and granted, the start is always as late as possible.
  • Since most of us sample from the “most likely” range of the distribution, this means that:
    • Almost all of the safety is wasted.
    • Tasks have low probability of early finishes.
    • Tasks have significant probabilities of late finishes.
    • Assigning more time does not reduce risk of late finishes, we just push the schedule.

Student Syndrome Example

Let’s use our base case step durations and allot 25 days. I.e., we expect a risk free project with no delays and a total duration not to exceed 250 days. As explained above, with pooling, the base case has a project duration range of 129-211 days.

Let’s assume the tasks starts based on the the most likely point estimates by our resources and that these estimates land us in the range 15 to 20 days. Now let’s bracket this into two scenarios:

Scenario 1 – Liberal:

  • The resources expect they can do a step in 20 days.
  • Implied slack or safety is 5 days.
  • Start date will be day 6.

Scenario 2 – Radical:

  • The resources expect they can do a step in 15 days.
  • Implied slack or safety is 10 days.
  • Start date will be day 11.

We can now run two Monte Carlo simulations and compare to the base case outcome.

Student Syndrome Simulation Results

Base case (pooling):

  • Project duration range is 129-211 days (100% confidence).

Scenario 1 – Liberal:

  • Project duration range is 181-256 days.
  • 21.3% longer than the base case.

Scenario 2 – Radical:

  • Project duration range is 233-304 days.
  • 44% longer than the base case.

The simulation results simply take into account a very common and predictable human behaviour pattern. And this blows the schedule to bits:

  • The Student Syndrome wastes any and all slack there is.
  • Giving more time to a task beyond the max duration will not reduce risk.
  • If start times are driven by the ‘most likely’ estimates and not ‘max duration’, finish times will always be late, no matter what is allocated.
  • The later we start, the greater the expected overruns.
  • Pooling may take the edge off, but your pool will still be late.

Implications

The implication for the wise project manager is that:

The only way to mitigate the student syndrome is to manage the start times: always start as soon as possible based on the maximum estimated duration for a task to protect the finish date from overruns.

Parkinson’s Law

Cyril Northcote Parkinson first articulated his law in the book: “Parkinson’s Law: The Pursuit of Progress”, London, John Murray, 1958.

The scientific observations which contributed to the law’s development included noting that:

  • As Britain’s overseas empire declined in importance …
  • The number of employees at the Colonial Office increased.

The original Parkinson’s law states that:

  • Work expands so as to fill the time available for its completion.

Parkinson’s Law is often generalized further to state that:

  • The demand upon a resource always expands to match the supply of the resource.

This means that:

  • Assigned time will likely be used in full.
  • We have a low probability of (reported) early finishes.
  • Available resources will be assigned work up to full capacity.
  • We have increased risk of resource contention.

Parkinson’s Law Example

Let’s assume we allot 25 days per step as per our base case task duration estimates.

Let’s further assume that all steps start as soon as possible, which, when applying the implied “Parkinson’s Law decision rule”, means that:

  • Regardless of point estimates, each task will always consume 100% of the allotted time, i.e., 25 days.
  • In effect, this is like a uniform distribution centered on 25 days.

Parkinson’s Law Simulation Results

We actually do not really need to run a Monte Carlo simulation for this because the outcome is deterministic – what you allocate is what you get.

  • If you allocate the max duration for each step, and start as soon as possible, you will have a risk free project.
  • If you allocate less than max duration, you will always get the allotted time plus any overrun when they occur.
  • Since all steps take 25 days, project duration will always be at least 250 days.
  • You loose all early finishes and suffer all late finishes.
  • The more time you allot, the later you’ll be.

The effect of Parkinson’s Law is similar to the Student Syndrome, but with an added, nasty little twist:

  • The more time you allot, the higher your costs will be because people are working and therefore, presumably, billing. E.g., allot 30 days for a 25 day task – you get (and pay for) 30 days of work.
  • Under the Student Syndrome, you just get the time delays. E.g., allot 30 days for a 25 day task – you get (and pay for) 25 days of work.

Implications

The implications for the wise project manager are that there are two ways to mitigate Parkinson’s Law:

  • As an extension of how to manage the Student Syndrome, i.e., to manage the start times: always start as soon as possible based on the maximum estimated duration for a task to protect the finish date from overruns.
  • Protect the work load by specifying very clearly what it means to be done (i.e., the work to be completed), monitoring progress and reassigning a resource if necessary when his or her current task is complete.

Multitasking

Multitasking refers to a familiar behaviour pattern where resources are working on more than one assigned thing at the same time.

This typically occurs when someone:

  • Is assigned to more than one project, or
  • Have several activities going on in parallel within one project.

Multitasking Example

Consider a case with three tasks A, B and C with a common milestone date M.

Let’s assume that:

  • We can’t assign three resources and complete the three activities in parallel, but
  • We can assign one resource and complete each task sequentially (single tasking), or
  • We can assign one resource and work on each task in parallel (multitasking).
  • Let’s also assume that the tasks can actually be divided into sub-tasks.
  • A, B and C have an overall max duration of 25 days each.

Multitasking Simulation Results

We don’t need a simulation to tell us how this works: Multitasking causes unavoidable delays compared to single tasking.

This is because multitasking quite often is a result of assigning tasks across projects or across parallel streams (or stages or whatever) within a project.

Consider the following:

  • Completing A, B and C sequentially means we get A completed after 25 days, B after 50 and C after 75. Consequently, whatever tasks follows after A, B and C respectively can start on day 21, 51 and 71, respectively.
  • Completing A, B and C in parallel, i.e., multitasking, means we get A completed after 58 days ( technically 50 + 1/3×25), B after 66 days (technically 50 + 2/3×25) and C after 75 days.
  • Comparing the two outcomes, it is clear that whatever A and B are linked to will be delayed compared to single tasking. This means that the organization potentially forgoes 56-25 or 31 days of benefits for A and 66-50 or 6 days of benefits for B. C, being last in line in both cases, is theoretically unaffected (except for the high likelihood of schedule delay from the effects of Student Syndrome and Parkinson’s Law).

Learning Points

  • Multitasking delays completions of all but one task compared to sequential completion.
  • Delayed completions may imply delayed benefits.
  • Multitasking gives a false sense of progress because it looks like lots of things are happening.
  • Multitasking creates stress because resources must deal with project issues from all the activities mixed together.
  • Multitasking increases the communication overhead because resources must stay in touch with more owners and stakeholders for multiple tasks.
  • Multitasking breaks “flow” (i.e., concentration) which reduces efficiency and may contribute to tasks taking longer.
  • The “event horizon” is longer when multitasking which increases the period of exposure to undesirable events (i.e., risk and uncertainty).

Implications

The imlicaitons for the wise project manager are that:

The negative effects of multitasking are most properly addressed by scheduling and prioritizing consciously among projects and tasks.

Multitasking is a classical manufacturing problem that was solved definitively by going to one-piece flow; i.e., a sequential mode or single tasking.

Closing Thoughts

We all know life is seldom as straight forward as we can make it look in examples used to illustrate a point of view, idea or theory. That said, the underlying dynamics of the Student Syndrome, Parkinson’s Law and Multitasking are very real.

Perhaps we cannot entirely eliminate their effects, and Multitasking is especially difficult to deal with in a practical way unless all other project teams drawing on the same resource pool also try to do more single tasking. We need a policy decision in the respective organizations to ultimately come to grips with this.

On a more positive note, as project managers we have much more control over the influence of the Student Syndrome and Parkinson’s Law because a project manager can and must manage and monitor work assignments and start times. Being that much more aware of what to look out for and, more to the point, avoid, is a good part of the battle. Hopefully, this has been of some help to that end.

Preben Ormen has over 35 years experience with a wide range of businesses, teams and cultures from around the world. He has experience in SAP, IT Governance, procurement, system selection and integration, and performance and process improvements. You can read more from Preben on his blog, you can follow him on Twitter, and you can contact him via LinkedIn.

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

This entry was posted on Wednesday, July 18th, 2012 and is filed under Scheduling. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

No comments yet.

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

The Stevens Enterprise Project Management Master's Program

Project Management Categories