Why Your Project Plan Will Fail

You’ve written a project plan. Your team is ready to start. Here’s the bad news – you’re going to fail. But why? How can you avoid failure?

The Undergrad Mistakes

Failing to plan is planning to fail. We’ve all heard this one before. Its become a cliche. Steve McConnell opens his article, The Nine Deadly Sins of Project Planning with this old saw. Well, we certainly can’t argue with that. And Steve offers some other suggestions that also fall into the project management 101 class – don’t use the same plan for every project, plan for risks, don’t plan in too much detail too soon, to name a few. Let’s assume we know that stuff already.

Christopher Hawkins provides us with project management 211 topics in his article, Why Your Schedule is No Good – And How to Fix It. He goes into detail on six more common mistakes:

1. People take vacation – is that in the plan?
2. People get sick – is that in the plan?
3. Don’t forget holidays. And for global teams, don’t forget holidays in other countries.
4. What about personal days?
5. Have you planned for disaster? Christopher adds 5 days of contingency to a 3 month project.
6. No-one is productive for 8 hours per day – is that in the plan? We plan on 5 or 6 hours of “on task” time per day.

His article is a really good one. These are the things you know to do if you’ve managed projects before. You didn’t do them because someone told you to do them – you planned for these because they happened (and they always happen), and you got burned. So you remembered.

The Graduate Mistake: Everything Is Late

Doug DeCarlo has an article at Gantthead, Why Traditional Project Planning Often Fails. He applies some interesting insights, that help put things in perspective.

First, he cites a variation on Parkinson’s Law, that the tasks will grow to fill the allotted time. They may not all be late, but many will – and few will be early. In addition to “feeling right” intuitively, this has some mathematical impacts on the schedule that I don’t believe any estimation software accounts for.

When you run two tasks in parallel, and one or both are late, you’re done when the last of the two finishes. By running tasks in parallel, you can infer that they are independent. Unfortunately, this isn’t universally true when planning. When tasks are run in series and the first task is late, the second one starts late.

A Quick Refresher on PERT
When we look at traditional PERT analysis, we have a mathematical way of dealing with this. Imaging two tasks estimated to take 4/6/8 hours (best case / likely case / worst case) each. With PERT estimates, you are saying that 90% of the time, the task will take between 4 and 8 hours. Each task has a 5% chance of taking more than 8 hours, and a 50% chance of taking more than 6 hours.

When you run those two tasks in parallel, that means you only have a 25% chance that your project will finish in 6 hours – the odds are that at least one of the tasks will run long. And you have an almost 10% chance that your project will take more than 8 hours. If you’re running 5 tasks at once, you have a 23% chance that the project will take more than 8 hours.

Many people will think that if they have 5 tasks, running at the same time, each with a 95% chance of being done in under 8 hours, that they have a 95% chance of being done in 8 hours. They don’t. The problem is that you aren’t done until all the tasks are done. And you only have a 77% chance that they will all be done in under 8 hours.

Where PERT gets interesting is when the tasks run in series. The two 4/6/8 tasks will complete in 9/12/15 with the same expectations – 95% of the time, the two tasks will have finished in under 15 hours. The odds get better because sometimes, when one task runs long, the other one runs short. This is the interpretation of combining PERT estimates.

Back to DeCarlo

The problem, according to DeCarlo, is that the tasks will never come up short. Does this mean that PERT estimates are junk? No – it just means that our estimates might be. Imagine the task were ten times as large, with a PERT estimate of 40/60/80. Suspend for a moment your urge to reject an estimate that large. 40/60/80 is symmetrical. That means you believe 40 to be just as likely as 80. If DeCarlo is right, then 55/60/80 would be much more believable. This would represent that the task often runs long, and almost never runs short.

Thankfully, we can still combine PERT estimates in this way. If our two tasks were in series, and were estimated as 5.5/6/8, the final project estimate would be 10/12/14. The final distribution has tightened up, as we would expect – because the original estimates are tighter.

We think DeCarlo is at least on to something. When reviewing project post-mortems, we do find that under-estimated tasks exceed over-estimated tasks, by about 2 to 1, at least for tasks in the 2 to 8 hour size range.

Make sure and review the estimates – and pay particularly close attention to the “low side” of the estimate – is it really believable?

The Post-Hole-Digger Mistake

That’s how my grandfather described people with doctorate degrees. He felt that practical knowledge was worth more than theory. This works well for the last mistake, because for some people, this one is well, duh – practical, and for others it is enlightened study – aha! smart.

Your project is a moving target. Your project plan is a static document. Instead of proving it to you, I’ll quote Bill Miller from his blog, You Want it When?,

A project with no requirements changes is either mismanaged or a dead project walking. If the project you are delivering is something that has a future and the project stakeholders are excited and interested about, requirements change is an inevitable consequence.

Bill Miller, Embrace Change

Read the rest of Bill’s article – it’s really good. He and I have been discussing the warts and merits of agile project management, and reminiscing about the good old days of waterfall development and rotary phones for a while. Seriously good insights and healthy skepticism of the hype you see everywhere (even here, sometimes).

• When requirements change, deliverables change.
• When deliverables change, the work tasks and estimates change.
• When tasks and estimates change, the project changes – and so should the plan.

You don’t have to tell anyone if this was obvious to you, or if it seems enlightened – don’t ask, don’t tell. And if you haven’t been on a project where the project manager refused or at least resisted changes to the plan, you haven’t been on very many projects.

Conclusion

There are many things that can go wrong with project planning, ranging from the obvious to the insightful. From the high level (plan for change) to the low (be wary of symmetrical PERT estimates). The more of these things you plan for (pun intended), the better your plan will be. Most importantly, realize that your project is a moving target, so your plan better move with it.