General discussion


What's wrong with the Plan?

By Marc Thibault ·
The plan said six months but the project took ten months. Why didn't the plan say ten months? That seems a reasonable question to ask of whoever crafted the plan.

Every week, somebody publishes a list of the things that make projects late and over budget. All of these lists agree on the significant issues.

These are not unknowns. They can be listed, their impacts quantified, probabilities attached, and baked into the plan.

I've never seen a plan that included a factor for scope creep, or the sum of the many hazards that could bring down the development server, or flu season, etc. Why not?

At the very least: "Even though our bottom-up CPM analysis says six months, all the similar projects we could find took between ten and twelve months, so we're estimating eleven months."

How can we make sure we give projects the time and resources they need to succeed if we propose hopelessly optimistic plans that ignore significant risk factors?

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

Now you are wilfully ignoring the purpose of the plan

by Tony Hopkinson In reply to What's wrong with the Pla ...

First it's not about how long it will take, it's about when it's required.
Second it's not about how much effort it will take, but how much effort you dare say it will up front.
Third, where did you get this naive idea that the plan was meant to be realisable.

All I can say is you must be new.

Collapse -

Good one

by Marc Thibault In reply to Now you are wilfully igno ...


But on the mark. That's the challenge. It's especially a challenge in government where failure has no consequences, and TLA contracts, where billable hours are the goal.

The people who pay are taxpayers and the developers who have no control over the insane targets that are set for them.

Collapse -

Basically the plan is to maintain an

by Tony Hopkinson In reply to Good one

illusion of control.
To give a base line to measure something against.

Nothing wrong with that, have to have something, just remember you are measuring real progress against a fictitious plan, too often people get them backwards.

My favourites are
A detailed break down of the estimate, without doing any work....

How many unknown unknowns are there, with out doing any work.

How much time can you shave off your estimate to make the plan look doable, without doing any work.

If you are asked any of these, they are planning a failure.
The sumfin' for nuffin' boys.

Collapse -

That was strange

by NexS In reply to Now you are wilfully igno ...


Business plans.. Realisable?

Who said that climbing Mount Everest was easy? The salesman, that's who!

Collapse -

It's a lot easier than it used to be

by Tony Hopkinson In reply to That was strange

with all this new technology.

Well that's the thing, the goal should be realisable, the vision valid, the plan is a guide how to get there, not the thing itself.

Basic case of the map is not the territory.

Collapse -


by NexS In reply to It's a lot easier than it ...

Though, there's got to be some form of legitimacy to the plan. A well structured plan will come close to the end result, but things will always happen that either push time out, or push prices up or something else.

Inevitability is life.

Collapse -


by Marc Thibault In reply to Zackly

Listen to yourself. "Things will _always_ happen..."

We may not be able to predict the specifics, but a lot of low-probability events combine into one high-probability event. We can depend on something happening and history can give us a probability distribution on the impacts. That can be baked into the plan.

Throwing our hands in the air and designing a plan for failure because we don't know specifically or with certainty what will happen is not really serving our client well.

On a one year project, there's a 2% probability of a fifty-year storm. A planner who doesn't know what to do with that information should turn in his badge.

Collapse -


by NexS In reply to What's wrong with the Pla ...

You need to make your project look attractive to the manager. It's only after you've put resources in 'too-deep' before you spring the bad news, and by that time it's already too far into the project to pull the pin.

It's logically perfected over the many years of failures and wondering why the boss says 'no'.

Collapse -

I have seen plans that do factor risks

by JamesRL In reply to What's wrong with the Pla ...

At the Fortune 100 company I worked at, they had a very developed project process.

A standard part of the planning process was to come up with a "contingency" factor. This was based on the assessed risk, technological risk, resource risk etc. Then the project stakeholders would review the risk and agree upon a contingency factor. It could be 5% for a simple change to an existing piece of stable software, or it could be twenty percent based on diving into an area that was an unknown for the organization. Then there would have to be developed a risk mitigation plan - how do we plan to avoid the risks? What are the potential costs if we don't? How much should we spend to avoid the risk? And you are right, at the minimum, it should be compared to other similar projects.

But you only know that if you measure the performance of every project and have a basis of comparison. Few companies take the time after the project is done to measure how close the project was to plan, so that they can adjust their assumptions for the next project.

As a business analyst at a bank, I wrote a project risk management plan based on a purely technical anlysis. It had to be approved by someone from the bank's risk management office before the project could make it part of the plan.

Collapse -

Exactly pseudo science

by Tony Hopkinson In reply to I have seen plans that do ...

Ask me for an estimate, I give you a range or a maximum. That's based on how much work, my current comprehension of the problem, and the complexity of the solution plus if I've been there long enough I'll factor in the potential for gotchas.

The idea of a similar project is a fiction, all the cost savings given you are using the same people to the new one are comprehension and maybe a bit of copy and paste. The dubious assumption that you understand the problem and that this code is easy to reuse will offset that easily.

I've heard numpties come out with garbage like your estimates should be within 8.75% of the actual. It's an illusion, software's power is that it's mutable so change is a given. A bit more concentration on should we do this as opposed to can you do this would help.

An adjusted assumption, is both assumptive and another assumption, an illusion.

The real risks are you don't understand the problem, or you don't understand how to solve it, there's only one real way to address those, you do it....

Related Discussions

Related Forums