Software·43,770 discussions

What’s wrong with the Plan?

Locked

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?

Topic

Now you are wilfully ignoring the purpose of the plan

In reply to What’s wrong with the Plan?

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.

🙁

Good one

In reply to Now you are wilfully ignoring the purpose of the plan

Chuckle.

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.

Basically the plan is to maintain an

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.

That was strange

In reply to Now you are wilfully ignoring the purpose of the plan

…

Business plans.. Realisable?

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

It’s a lot easier than it used to be

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.

Zackly

In reply to It’s a lot easier than it used to be

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.

Exactly

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.

Because:

In reply to What’s wrong with the Plan?

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’.

I have seen plans that do factor risks

In reply to What’s wrong with the Plan?

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.

Exactly pseudo science

In reply to I have seen plans that do factor risks

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….

Assumptions versus expert estimates

In reply to Exactly pseudo science

Are you saying that you don’t know your own trade well enough to make reliable estimates about how long it should take to write a particular piece of code?

More to the point, if I ask you for a number you can meet or beat with a 75% probability, do I get doe eyes, or an estimate that has 3:1 odds for success?

Even better, could you use this tool (http://smpro.ca/crunch/distshaper.xls) to give me a probability distribution?

No I’m not saying I couldn’t give an reliable estimate

In reply to Assumptions versus expert estimates

on how long it would take me to write the code.
I’m saying I don’t have enough reliable information about what the existing code does, what it should do and what impact meeting that will have on the rest of the monolithic, unrefactored, undocumented written for DOS originally frankensoftwae I inherited off the last version. :p

I can give you an estimate I can definitely meet anytime you want, as long as one year minimum is acceptable. 😀
That would be a caption change on one form we don’t use anymore….

This is a nice one .
A colleague as his initiation into our weird and wonderful code base got asked to put a couple more fields on a form which meant resizing it width ways.
Did that patted himself on the back, sent it to QA.
Came back with a defect numbers intermittantly appear on the right hand edge of the window.

So why didn’t he take this potential difficulty into account with his estimate?

You’ll love the reason for it.
We were rolling about.

I wouldn’t call it pseudo science, though imperfect

In reply to Exactly pseudo science

Whats the alternative, not have a plan at all?

A plan is only as good as the planner and the inputs they get can make it. When I was doing risk studies, I interviewed the participants.

I argue that while no plan is perfect, its a well proven fact that the more time and effort you spend on planning, the less screwup happen later on. There have been studies showing that the later a mistake or bad assumption is found in the project, the more costly it is (and when you think about it, its common sense).

At that big company, we were measure each month where we were, see if we used up our contingency, and ask ourselves if anything had changed that required us to reset the plan or re-evaluate our assumptions. Problem is with many companies, once the plan is finalized, its chiselled in stone.

Yep cast in stone, even that’s not unreasonable

In reply to I wouldn’t call it pseudo science, though imperfect

It will take two people ten weeks to do is a nice hard number for the bean counters and for manager who has several other things on their plate that are or were in competition for that resource.

So in an ideal world you get what you want in a maximum of 11 weeks if you both people stay available.

But this is software in a far from ideal world, so you discover for one reason or another the plan is bollocks, an outright fantasy concocted out of ignorance or mendacity.

The traditional approach is to keep going, achieve something vaguely related to the documented goal and then blame people for not following THE PLAN…..

Won’t work, can’t work…
Ever

I’m a big believer in pulling the plug myself, if the plan turns out to be bollocks, look at it in the light of the new information, whether that’s this is harder than we thought, we thought wrong, or someone important changed their minds is irrelevant.

The hardest people to fight over that are those who have invested in it, set expections with peers or customers, put their reputation on the line etc, all based on his fiction they chiseled in to a granite slab.

Pseudo science was reference to the “science” of estimation.
Take a guess, then add 10% for utilisation, 15%, for known unknowns, 10% for unknown unknowns and your estimates shoukld be within 8.75236785401 of actual.
Every one of those numbers is a guess, Writing down a fixed percentage guess of a guess still leaves a guess….

Why guess?

In reply to Yep cast in stone, even that’s not unreasonable

So, don’t guess–measure.

Methinks you’re a victim of inadequate tools.

Well yes, but what have my bosses

In reply to Why guess?

got to do with anything?

😀

Well lets see now.
I guess I can do this much in a day, and I guess it will take this long, so by my measure the answer is length of task/length per day, the I guess all the things I don’t know now that I will find out later, will have an impact of I% so the the completely accurate formula is

x / y + (x * I / 100) = 42

Or I could just ask the local astrologer…

[Author]

Replies