Why projects are always late

What is the best way to set a project timescale?

It's notoriously difficult to bring a tech project in ON TIME and ON BUDGET. A 2004 study by PwC 2004 found that only 2.5% were on time/budget, and more than 50% failed completely. And we all know that if it's a government IT project, then the chance of success is approximately 0%, right?

The 'iron triangle' of project management describes how quality is constrained by scope, time and cost, and changing any one of these constraints affects the others. Or, as commonly attributed to John Ruskin, "Good, fast, cheap. Choose two." In most projects quality isn't negotiable, cost and scope aren't negotiable, so our only choice is how much time should be allowed. 

There are four ways you can set a project timescale:

1. Set an aggressive target without reference to any work estimation, expecting that the delivery team will 'step up', show initiative, and work overtime.

RESULT: burnout, lying, resignations, box-ticking.

2. Try to estimate accurately, based on previous projects and the expert opinion of the delivery team.

RESULT: Dammit! We got it wrong AGAIN. Once the team got into the work they hit unexpected delays in areas that they had assumed would be straightforward. As usual.

3. Add a contingency to the estimate, based on its risk, or "Just how unknown are these unknowns?"

RESULT: Dammit! Parkinson's Law in action: work expands so as to fill the time available for its completion." There was scope creep and 'polishing', and once again we overran.

4. Accept that it will take 'as long as it takes'.

RESULT: 3 years in and no end in sight. Nobody can remember the project's original purpose. It's evolved into major re-engineering, and we've changed the tech platform twice.

So must we accept that it's impossible to meet project deadlines without wasting time and resources? Well, yes. The problem with deadlines is that they're predicated on two false assumptions:

• You can predict with any accuracy how long it takes to create new technology solutions.
• The delivery timescale has a real business impact (This one isn't always false, but it usually is).

The solution, whether you want to use the "Agile" word, is to give up on your delusion that you understand your business needs in sufficient detail, or that they will remain stable for long enough, for you to be able to plan the optimal sequence of actions for an extended period. Instead, break down your business goals into MUCH smaller pieces, articulate them as measurable/testable outcomes with acceptance criteria (instead of specifications of solutions) and continually reassess their prioritization.

In other words, stop trying to boil the ocean, because it might turn out after heating one cupful that actually now you need a teabag. This is a fundamental principle of the 'product approach', and probably the hardest to achieve. More about this in the next post!