Have you ever inherited an estimate and had to manage a project to it? Was it a pleasant experience? The only person who should be allowed to quote an estimate is the person who will manage the project. That is the only person with an incentive to get the estimate right.
If you do take over a project and an attached estimate, in the first week review everything and if the estimate is wrong shout loudly (and by implication blame your predecessor). If you leave it for more than a week or so it's your fault, you caused it. Unfair, but that will be the perception.
Best advice of all is: never take over a (large) project half way through - you never know what you're taking on,
you never know what stones have been left unturned that conceal nasty surprises.
Go on holiday, retire, get pregnant - whatever it takes. But if there's no escape and you're forced to
take a project over, in that first week lift up all those stones, even get an independent review (see the
project support chapter). Maybe you'll be lucky, everything's fine. But why did the previous project manager leave?
Why people get estimates wrong
There are many reasons people get estimates wrong:
Suggestions for getting it right
Break a big programme into sub-projects, releases, stages. Estimate each bit separately and add it all back up.
Keep the first release to essential functions. This helps in two ways. Release 1 is obviously smaller than the whole thing would have been and therefore inherently easier to estimate, but you will tend to put the stuff into Release 1 that's best understood and therefore easier to estimate. Leave all the vague stuff till a later release by which time one hopes it will have become clearer.
Don't quote narrow ranges. If someone told you a project was going to cost between 100 and 120 which number would you hear? Probably 100. But the estimator is thinking it will cost 120. Immediate mis-communication.
Quote a very wide range to indicate your level of uncertainty. "I've been looking for you, I've got to go to a Board meeting - can you tell me roughly what a project to do... would cost?" "Yes I can. It will definitely cost you between ten thousand pounds and ten million pounds." "Can't you be more precise than that?" "No, not on what you've told me so far." (One project manager carried a pair of dice for such occasions. He would roll the dice and if they showed, say, nine he'd say: "The project will cost nine." "Nine what?" "I don't know, you decide.")
Don't factor in savings from new tools. First use will probably increase costs due to the learning curve.
Have a fixed budget. This can greatly empower the project manager to say 'no' to non-essential functions. "I'd like to do that for you but I'm afraid it won't fit into the budget." If you've ever run a project you will know that some things are going to be easy to do, other things you just know are going to cause difficulties. Any excuse not to include things like that if they are non-essential is useful.
Test those who come to you with an estimate: "What is the chance the work will cost less than this estimate?" If the person now starts laughing helplessly what does that tell you? It's going to cost a lot more than their estimate. Ask them to try again and come back with a revised figure and tell them there must be a 50% chance the work will cost less than the estimate.
Check the estimator lives in the real world. Some people live in a fantasy world in which nobody makes mistakes, nobody changes their mind, nobody has holidays or goes sick... They are estimating what the project ought to cost. That figure is of no use to man nor beast. We want to know what the project's going to cost in the real world. Indeed, some experienced project managers never ask anybody for 'an estimate', they never use that word. They ask the question like this: "Please would you go away and work out for me how much you think this piece of work really will actually end up costing us?" And they say if you ask the question that way you'll get a much more realistic figure than if you asked for 'an estimate'.
Avoid automated estimating tools. The estimating tool asks you several hundred questions. Some questions you don't understand, so you guess at their meaning and give an answer. The tool gives you a very precise but very wrong answer - garbage in, garbage out!
When top down estimating, and you don't know who will be in the team, you have to assume an average skill level. But remember you will probably have more junior people than senior people so the average skill level isn't half way down, it's lower than that. If in doubt assume any A.N.Others will have the skill of a raw trainee.
Sketch out the plan/schedule before quoting the estimate. If you list all the tasks you think you'll have to do, size each one and add it up you'll get an estimate. But when you start to build the plan you will find you have to add extra tasks in to make it all fit together properly. They weren't on your list.
When bottom up estimating get team members to agree to the estimates for their tasks.
Put your estimate in writing, stating the assumptions upon which it is based. If the estimator of our wall-painting project had said: "Well, assuming the wall's prepared and there's a pot of paint and a roller there and I've got to give it one coat it'll take two hours", it would have been obvious we had quite different understandings of the project scope.
Be aware of some individual's inclinations. Some will give macho estimates: "Me? I could do that in a day easy." Others are very pessimistic: "Ooh, that could take weeks..." Perhaps ask them how long it would take someone else to do the work: "I could do it in a day but him? About a week?"
The real secret of good estimating is recording on today's projects how many hours of work each and every project task actually takes so next time we have hard evidence and don't have to guess. More on this in the next chapter.
If you estimate properly and allow for everything we have suggested does that mean all your estimates
will be too high and all projects will start coming in way under estimate?
No. If you include in the estimate everything that will in fact cost you time and money estimates will simply be more
If you do find that all projects come in under estimate then start to worry that people are padding estimates.
But the risk is usually the other way: people tend to underestimate. In theory half of the projects should
come in slightly over estimate and half slightly under so that across the organisation it balances out.
Full collection of project management proverbs
"The person who says the project will take the longest and cost the most is the only person with a clue how to do it."
Please click here to go to
Project Management Book Chapter 7
Project Management Book
Copyright M Harding Roberts 2012 2013 2014 2015 2016 2017
Home Sitemap Contact Us Project Management Articles Project Management Book IT Project Management Course