Six Tips to Break the Estimation Doom-Loop

I’m guessing that many readers of my blog spend their lives working on projects. Whether you’re a business analyst, project manager, or architect, chances are that you’re working on at least one project right now. And whatever type of project you’re working on, you almost certainly have to estimate work as well as comment on estimates that other people have produced. If you work in an internal business analysis/change team, your estimates are likely to be around effort and time. If you work for a managed service provider (MSP) or vendor, you may well be delivering estimates to clients that relate to cost as well as time. As hard as we try to highlight that we are providing an estimate (rather than a final concrete figure), the stakes can be extremely high. As soon as a number is agreed upon it tends to be seen as the definitive number. And if it changes, we’ll find ourselves in a very difficult situation!

 

Estimation often feels like a dark art. We often need to estimate very early on in a project, long before we have a full and thorough understanding of the scope. If we’re unlucky, we’ll find ourselves bartering with our stakeholders. I’m sure we’ve all seen or been involved in dialogue that goes something like this:

 

Estimator: “This is a pretty big task, it’ll take 4-7 weeks with the resources we have”

Manager: “Great, thanks, but we need it done in two weeks. You’ll find a way, I have every confidence!”

Estimator: [Walks away thinking “not again!”]

 

In fact, there are many good Dilbert cartoons around this dilemma.

 

Breaking the estimation doom-loop

The good news is that this cycle of estimation and disagreement can be avoided—although it takes a change in tact. Here are some tips:

 

1. Break the estimate / commitment cycle: A lot has been written in the Agile and other communities about the difference between an estimate and a commitment. In fact, there are proponents that would argue it is better not to estimate at all (see the #noestimates movement on Twitter). However, in any case, it is important to make a clear distinction between an estimate and a commitment. If I commit to delivering something to you by Friday, then it is probably a well enough understood piece of work, and the scope is understood, that I can say with high certainty that it’ll be ready by Friday (and if for some reason things go awry, I’ll know and will be able to manage your expectations along the way). Commitments require a task to be certain, and for the parameters around it to be stable.

However an estimate is ultimately a guess. It may be a guess based on data, or assumptions, but it is still at its core an educated guess. Making this distinction clear from the outset can be useful.

 

2. A range rather than a number: If an estimate is a guess, then why do we insist on giving a single number? A range shows tolerance; it shows uncertainty. If I tell you I estimate it’ll take me 4 weeks, and it takes 5, you’ll be disappointed. If I tell you it’ll take 3-6 weeks, you’ll more than likely be happy. If I tell you it’ll take somewhere between 10-100 weeks this signals significant uncertainty.

 

3. Show how the estimate was derived: There are a whole range of estimation techniques available, from the proverbial ‘finger in the air’ guess, through to complex parametric methods, Delphi, creating a work-breakdown structure and many, many more. An estimate gets credibility when we show our working. And if someone presents you with an estimate, don’t be afraid to ask “How did you arrive at that figure?”

 

4. State assumptions: Estimates are based on assumptions. Stating these up front ensures that everybody’s expectations are aligned. Perhaps as well as saying “We estimate it’ll take 4-7 weeks” we also need to say “Providing we need to interface with just one known system, and the key stakeholders are available when we need them.”

 

5. Effort or duration: State clearly whether the estimate relates to effort or duration; else there is a risk of misunderstanding.

 

6. Discuss but don’t slash: Often there is a pressure to slash estimates. However, it is better to discuss rather than ditch an estimate completely. If we think it’ll take 4 weeks of effort, but somebody else is pressing us to do this with just 2 weeks of resource, let’s ask them where the two week figure was arrived at. Perhaps by showing them how we arrived at our estimate, and comparing it with their working, we can see whether we have misunderstood the scope. Either way, this can be a useful way to gain a mutual understanding.

 

The key with estimation, as with so much on projects, is to arrive at a shared understanding. Communication is paramount, and these tips will help to achieve a clear communication of any estimates.

 

 

I hope you’ve found this article useful. Do you have any estimation tips?  I’d love to hear from you – please add your comments below.

 

If you’ve enjoyed this article don’t forget to subscribe.

 

---

 

This post was brought to you by IBM for MSPs and opinions are my own. To read more on this topic, visit IBM’s PivotPoint. Dedicated to providing valuable insight from industry thought leaders, PivotPoint offers expertise to help you develop, differentiate and scale your business