After Hours

10 ways to avoid stupid project estimates

You can't run a successful project with bad estimates, any more than you can build a solid house with faulty bricks and lumber. These simple steps will help you filter out the bad numbers you get today and improve the numbers you get tomorrow.

You can't run a successful project with bad estimates, any more than you can build a solid house with faulty bricks and lumber. These simple steps will help you filter out the bad numbers you get today and improve the numbers you get tomorrow.


Projects run on estimates. You either have to provide estimates of things such as how much effort your task will require or you will need such information from others. Unless you're in one of a small handful of roles, you will surely come to rely on estimates of others, even if it's just to frame your own estimates. And if you're a project manager, the estimates of others are probably all you have to work with.

Overall, project estimates are only as good as the individual estimates associated with the component tasks. But as much discussion as there is on the estimation process, there isn't a great deal of information on getting better estimates from others. Here are a few ideas to help you see this aspect of estimating more clearly -- and to help you avoid leading your project astray before it ever starts.

Note: This article is also available as a PDF download.

Vetting the estimates you get today

1: Let history be your guide

It is true: History does repeat itself. I can't tell you the number of times I've seen developers give an estimate of two days and actually take four. There's nothing wrong with that, because there was probably four days' worth of work to begin with. The problem is that I also see people in meetings repeatedly believing them. If it has taken twice as long as the estimate the last five times an estimate was given, why would anyone think the estimate will hit this time? Beats me, but some people continue to fall for it. Unlike the stock market, past performance can be an indicator of the future.

2: Ask for details (proof)

Learn the justification for an estimate. If you ask why they think it will take two days, and you get a reasonable task-by-task break down of the two days' work, two days may be right on the mark. But if your developers just shrug their shoulders, it may be time to worry. This also provides a great opportunity to assess their assumptions.

3: Challenge the numbers

Push back. Ask questions. Project managers seem to do this pretty naturally, but challenge the developer or development team to explain why they think it will take so long. If they can justify their estimate, at least you will know that they gave it some thought. If they can't, perhaps they should be thinking about their estimate some more before you start relying on their figures.

Don't be surprised if the estimate actually goes up. It would not be the first time I've seen a discussion with developers expose previously undiscovered project tasks. While not great news, it's still better to find out about this sooner rather than later. Left hidden, those tasks would have surely destroyed the timeline when they came to the surface and jumped onto the critical path.

4: Measure

Okay, you know your developers are always missing their estimates, but by how much? If you aren't measuring it, you really don't know whether you have a big problem -- or maybe don't have a problem at all. This also ties into the history suggestion above. How long does it usually take? You don't know unless you track this information.

Metrics also go a long way toward improving estimates. Like any process, you can't improve it if you don't measure it. Unfortunately, a deep dive into this topic would be an entire article (or two) in itself. But if you don't have a clue where to start, just start capturing expected date versus actual delivery date. You might be surprised by the patterns that develop.

5: Bracket the work

This is for those who just can't come up with a time estimate for the work. First, try helping them break down their work into smaller, more manageable, tasks. Next, you may find it useful to use a simple bracketing technique to help the person zero in on the figure that is appropriate. "Is five days enough time?" "Can you do it in less than 10?" Continue in this fashion until you get a figure that everyone is comfortable with. Of course, you should be challenging and asking for details throughout this process.

6: Get a second opinion

When you're hiring a builder, they say you should get several estimates, throw out the highest and the lowest, and then go with the one in the middle. There might be something to that approach. When working with a team, you're probably getting your estimates from the team's point person -- a lead developer, for example. While this is efficient, it may add some risk to the accuracy of any estimate you receive, especially if there is a wide variance in the estimates of the individual team members. You may be getting the result of a faulty team consensus, a blatant falsehood to avoid having to face some development reality, or an estimate flawed by an innocent miscommunication.

If you have reason to suspect an estimate may be off, or if the team has a bad track record for this sort of thing, a second opinion may be in order. Seek an informal read from other members of the team. If you run the team estimate past an individual developer, and he wrinkles his nose at it, you may have some more digging to do. If everyone is of a like mind, you probably have as good a number as you can expect.

7: Remember that two heads are better than one

Run your figures past someone who might have experience with your type of project. If this person is not on your project, all the better. Perhaps you're a sucker for good news. Perhaps they are telling you what you want to hear. An objective third party is exactly what you need to free you of your bias and give you a clearer view of reality.

Improving future estimates

8: Give feedback

You have captured task estimates, and you have tracked actual. From this, you may have learned that certain groups always underestimate by 25 percent. That is certainly good to know, but don't let the value stop there. Provide feedback to the team members. Help them identify patterns in how they estimate and challenge them to find the root cause of their bad estimates. Generally speaking, people really do want to do a good job, so provide them the tools and a few suggestions. Your folks will be able to take it from there.

9: Reward and penalize

Penalize the bad estimate, not that a task estimate is too long. When estimates are shortened, it's generally because that shorter number is what's expected. That is where the "If all goes well, it will take..." comes from. Be serious. When was the last time "all went well"? There's nothing wrong with qualifying an estimate, but adding an unrealistic assumption as a way to give a bad estimate only hurts the project. You want to drive toward behaviors that give better estimates. Celebrate when estimates are hit. When estimates are missed, you don't need to tar and feather the offenders, but you can treat it as a remedial education opportunity (the very act of which will be a penalty of sorts).

Be careful about rewarding beating an estimate differently from hitting it. If you create the situation where it is better to beat an estimate than simply meet it, you will create an incentive for overestimating.

10: Develop a culture

Using the correct rewards and penalties goes a long way toward establishing the right culture, but what is the right culture? Certainly, it's one in which those providing estimates feel safe in providing accurate information as opposed to providing the information they believe supervisors want to hear. However, it must also be one in which everyone strives to improve the quality of their estimates and the notion of providing a bad estimate is as bad as providing bad program code. Managers must also respect those providing them with information, once those people have proven themselves. Ultimately, if you can get peer pressure to "manage" the estimates, your job will become considerably easier.

Improve your project, one estimate at a time

You can't run a project well with bad estimates, any more than you can build a house with faulty bricks or lumber. Fortunately, you don't need to do everything yourself (nor could you) to get estimates you can trust. Exercising the simple ideas above will help you filter out the bad numbers you get today, improve the numbers you get tomorrow,  and generally make your life a whole lot better -- at least as far as your project is concerned.


Finally: 10 Things... the newsletter!

Get the key facts on a wide range of technologies, techniques, strategies, and skills with the help of the concise need-to-know lists featured in TechRepublic's 10 Things newsletter, delivered every Friday. Automatically sign up today.

15 comments
bblackmoor
bblackmoor

In my current position, every estimate I give is correct, and every estimate I give is ignored. "I don't think it will take that long." Then why did you ask me? "I don't see it that way." And yet, I am the one who knows what he is doing, and you are not: that's why you hired me. It really is quite frustrating.

lcdata
lcdata

The only point worth anything is "history". We're talking *estimates*, people. We're also dealing with developers, who, generally, have no sense of time or timing. Finally, analysis and programming are forms of art and are not measurable in any way, no matter how stiff management heads wanted it. "How much time do you think you'll need to analyze this problem?" That must be the stupidest question ever, same as asking police detective how much time it takes to solve a murder. The *only* thing anyone can give you is an ESTIMATE!!! You can't punish wrong estimates. That's again just stupid. Also, what's gained by pushing developers to give you a shorter estimate? Make them work harder?!! If they already don't work hard - fire them. No need to ask hypothetical and abstract questions and then humiliate the person by interrogating him. Let the estimate be exactly that - an estimate. You don't like it, make an estimate yourself.

lawrence.f
lawrence.f

Good one. Especially for beginners.

Tony Hopkinson
Tony Hopkinson

Why are estimates still poor. Estimate of what? Usually done at the point of the process where the least is known of what is required, and early enough for there to be a plethora of unknowns to rear their heads. Which bit of estimate don't you understand. There is no such thing as an estimate of two days. three days +/- one day is an estimate. Justify an estimate, who to?. On what basis could a PM understand it, unless they were a developer on that code base last week, forget about it. Similar project means nothing if there is an existing code base. Interesting slip. "Why will it take that long?" Oh yes indeedy. More informative questions, "Why must it take that long". "Can't you do it quicker?" "Do you need that much contingency?".... While I did bang my head as a child it didn't do any permanent damage, most estimates are massaged to fit the plan, not the other way round. Penalise for bad estimates. Are you kiddin' me? Why would an estimate be bad? Not enough resource to do an effective one. Not enough information at the time to do an effective one. Developer retension. Poor code base Poor documentation Poor analysis Poor developer. That can be poor, as in not good, or poor as in shat on again... Estimates will never get better while the process doesn't get better. Quality development costs money. If cost is a bad word then so is quality. The question business rarely asks itself. What are the business benefits of software quality. Costs, they've got that one down pat. Too much, and we can blame this poor chump again anyway. Give me a break... You have very few panes left in your greenhouse, personally I'd stop throwing bricks about.

Woody Goode
Woody Goode

My standing rule is that any estimate with a task duration longer than 80 hours gets challenged. If it takes more than two weeks, it's an activity, and must be broken down into tasks. (I'm using the Phase-Activity-Task hierarchy; if you use different buzzwords, translate accordingly.) I have never seen anyone who produced accurate estimates when they were taking bigger bites than two weeks. Also, point 6 and point 7 seem pretty similar and you might want to replace 7 with "Define completion." If I consider "done" to be "coded, tested, reworked and moved to production" and you think it means "coded", we've got an obvious problem.

windycityken
windycityken

In a perfect world, the developer doing the work is the developer creating the estimates. In the real world, this is not always true. So, it's difficult to determine the accountable individual for an inacurate estimate. Was the estimate off, or was the productivity of the developer off?

Jerry L
Jerry L

I think many of us have been in the situation you describe. Obviously, the 10 points of the article are for someone who is trying to get it right. You are correct... it is quite frustrating. -jl

Jerry L
Jerry L

I disagree - analysts and developers are very capable of providing accurate estimates. If they are not able to "in any way," then perhaps there is a development opportunity there for them.

Tony Hopkinson
Tony Hopkinson

The fact it has no basis in reality, is irrelevant when you can blame the developer.

Jerry L
Jerry L

I couldn't agree more - the process does need to get better, and some have further to go than others. (For the record, not every project out there is a train wreck.) -Jerry

Jerry L
Jerry L

The difference between points 6 & 7 is the person you are checking with. Point 6 suggests drilling down among those providing the estimate, where 7 might be getting the take of a peer (e.g., fellow PM). That not withstanding, I do take your point that they may seem similar. Thanks. -Jerry

Ed Woychowsky
Ed Woychowsky

I learned a lot from the history of estimates at one company. Management would ALWAYS divide the estimates by three. So a three week estimate would become one week, a three month estimate would be one month and so on. By using my indepth knowledge of past estimates, I would estimate to the best of my ability, then multiply by three. :)

Tony Hopkinson
Tony Hopkinson

Could they have been greater successes, more than quite possibly. Everything in software changes except the plan with the original cost and deadline. That's the real problem. Change is a given and has to be managed. If you gave them an accurate estimate to the minute, they still wouldn't be happy, as almost certainly the deliverable won't deliver what they need now...

Jerry L
Jerry L

Very funny (and sadly, not totally unheard of). So that proves that analyzing history works. lol. Thanks.

Editor's Picks