Six Tips to Break the Estimation Doom-Loop

Swirling picture of clocks, a visual representation of "the complexity of now"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

IBM Logo




tumblr tracker


rolandhesz

One of the best books – in my opinion – is Steve McConnell: Software Estimation: Demystifying the Black Art (http://www.amazon.co.uk/Software-Estimation-Demystifying-Developer-Practices-ebook/dp/B00JDMPOVQ/)

One can argue with some points made, or exact techniques, but the underlying reasoning, the logic and explanations are spot on.

And what a surprise, he starts – if I remember correctly, literally the first chapter – with differentiating between an estimation and a requested deadline.

In my personal experience, I was able to give the absolute best estimates when I had data on hand, a la Personal Software Process. The one created by Watts Humphrey.

I also found the FogBugz way of tracking “Probability of date of finishing the project” approach really helpful.

Practically everything that helps impressing the fact that time and cost is an estimate, it is fuzzy and it is no exact, and here is the data and reason why.

Another related thing: risk and impact estimates. Low/Medium/High. It is not helpful, it is confusing. It should again be expressed as a probability, or probability range and for the impact a £/$/Euro/whatever value range.

Otherwise we end up with impacts that are both High and one will cause a £40,000 loss, the other £4,500,000.

Plus a Medium impact with a £39,000 loss.

A really thorough book on the topic is Douglass W. Hubbard: The Failure of Risk Management: Why It’s Broken and How to Fix It (http://www.amazon.co.uk/Failure-Risk-Management-Why-Broken-ebook/dp/B0026LTMAU/)

And of course Douglass W. Hubbard: How to Measure Anything: Finding the Value of Intangibles in Business (http://www.amazon.co.uk/How-Measure-Anything-Intangibles-Business-ebook/dp/B00INUYS2U/)

Sorry for the linkfest 🙂

Adrian Reed

Thanks Roland, for a really insightful reply with some very useful links. I was aware of Hubbard’s work, but was not aware of some of the others — so I will add them to my reading list. I am currently consuming a lot of books on my Kindle and also audio books, so it is always very useful to have others to add too.

Perhaps we should start an book club?

All the best — Adrian.

rolandhesz

We definitely could start a book club. Are you “on” Goodreads? It is a pretty good site, people tracking the books they have/want to read/have read and full of reviews.

I am reading a lot too, this year’s goal is 100 books, and I have finished 78 so far – admittedly a mixture of professional, fiction and non-fiction books, so it’s not only “heavy” stuff.

Check out http://goodreads.com

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.