Project Management

The Art of Guesstimation: Why Shouldn’t We Estimate?

From the Disciplined Agile Applied Blog
by
This blog explores pragmatic agile and lean strategies for enterprise-class contexts.

About this Blog

RSS

Recent Posts

#NoFrameworks at Agile Middle East 2020

The Art of Guesstimation: Why Shouldn’t We Estimate?

The Art of Guesstimation: Why Should We Estimate?

The Art of Guesstimation: Estimation on Software Projects

Planning: The Efficiency Zone



In The Art of Guesstimation: Why Should We Estimate? we explored the reasons for why it can make sense to estimate the cost or time that an endeavor will require.  But this isn’t the whole story.  An important principle of business analysis, and in project management for that matter, is to not only define what is in scope but also to indicate what is out of scope. The implication is that it also makes sense to explore why we shouldn’t estimate an endeavor, which is the topic of this blog. 

There are several reasons why we should consider reducing the amount of effort we put into estimation if not eliminating it entirely:

  1. Estimation takes time and money. There is a cost associated with creating an estimate. As with any other activity, we want to perform the least amount of work possible that gets the job done and no more because anything more than that would be a waste.  The article The Value of Planning provides a detailed explanation of the importance of creating artifacts, in this case estimates, that are just barely good enough (JBGE).  
  2. Estimation is an overhead.  From a lean point of view we want to reduce, and better yet eliminate, any waste in our process.  As the #NoEstimates movement is very clear about, estimation is an overhead that does not directly add value to a customer (except in the form of providing inputs into their decision making process). At a minimum we want to find ways to reduce the amount of effort that we put into estimation and ideally to eliminate it completely where possible. 
  3. People commit to important decisions too early. The more effort that we put into producing an estimate, typically because we desire greater precision in the estimate, the more motivated we are to commit to whatever decisions that we make when developing the estimate.  For example, to develop a reasonably precise estimate for a software project we may need to invest several weeks, or even months, to identify the requirements and architectural solution for an endeavor.  The more work that is put into defining the requirements, or the architecture, the greater our reticence to evolve those decisions later in the project.  Even in the face of a different market environment, or an improved understanding of what our customers actually want, we will be wary of rethinking the commitment that they made earlier to the original requirements upon which the original cost and time estimates were produced.  In effect we’ve made very important decisions early in the project when our understanding of the problem, or the potential solution, was vague at best. In the end we may be on time and on budget, but we’ll have produced the wrong solution to the problem and thus have still failed in the eyes of our stakeholders. 
  4. Estimates answer the wrong questions. A cost estimate tries to answer the question “How much do we believe X will cost?” and a schedule estimate tries to answer the question “How long do we believe X will take?”  I appreciate that this will sound like heresy to many people, but should we not be focused on more interesting questions than that?  For example, rather than focusing on cost should we not strive instead to spend our money wisely?  Is getting a low-quality product on budget really a win?  Particularly when we’ll need a second effort to fix the quality problems?  Similarly, rather than focusing on a delivery date should we not strive to deliver what our customers need when they actually need it?  Is getting something built to specification delivered on time really a win when the requirements evolved while we were building the product?  Would it not be better to let the date slip and produce something people actually want, or deliver a partial solution early that meets some of their needs right now?
  5. Better ways of working (WoW) require less estimation.  You can dramatically reduce the effort required to estimate something, and even eliminate it completely, if you adopt effective WoW.  For example, consider a long-standing team (often called a product team) who are following Disciplined Agile’s (DA) Continuous Delivery: Agile lifecycle.  This is a team of fifteen people and they release into production every Wednesday morning at 11 am.  Estimating the delivery date for the team is easy, it’s “Wednesday at 11 am.”  Estimating the cost of that release is also easy, it’s fifteen times the charge out rate for one person for one week.  It’s at this point in the conversation that people say that it’s not that easy, because you still need to indicate when you’re going to deliver a specific thing.  Yes, you’re still going to need to do a bit of work prioritization and in the case of regulatory work or contractual work you’ll have to size your work somehow, prioritize it, and manage to the date.  So keep your sizing effort as simple as possible, or organize your work into similarly sized chunks, which also requires a bit of effort to accomplish, to enable this level of work management.  In short, improve your WoW and squeeze out the management bureaucracy.

The point that I’m making is that although we’ve seen that there are reasons why we what to estimate time and cost there are also reasons why we don’t.  A fundamental observation of the Disciplined Agile (DA) toolkit are that there are no “best practices,” that every strategy has strengths and weaknesses, that every strategy makes sense in some situations and not others.  This observation applies to estimation, just like it applies to everything else.

In the next blog in the series we will work through why estimates are probability distributions.

 

Posted on: January 17, 2020 12:00 AM | Permalink

Comments (5)

Please login or join to subscribe to this item
Dear Scott
Interesting your perspective on the topic

I liked the idea of ​​presenting the pros and cons of making cost and time estimates

If you are developing a product, service, solution for a customer resulting from a sale, does the buyer agree to close a deal without a set time and cost?

If the product, service or solution is not delivered on time and at the negotiated cost, who bears the cost gap and deadlines until the agreed delivery?

Welcome to the fantastic world of software development

In the predictive development approach there are techniques and tools that allow you to make estimates using the probability distribution.

#3 is spot on. I've lost track of how many times I've given a ROM estimate only to have someone try and use it as a definitive estimate.

Very interesting., thanks for sharing

@Luis, it depends. Some people do in fact commit to projects, often large and complex ones, on a time and materials basis.

Where I get concerned is the situations where people believe they are committing to fixed cost or time (or both) only to discover that they've really committed to time and materials in practice. Certainly within IT this has proven to be the norm for "predictive" projects and seems to be common outside of IT too. For example, I live in Toronto and the city is in the initial stages of messaging us that the subway project is trending towards being $400 million over budget and even later than previously thought.

Dear Scott
Thanks for your comment

See my answer as a joint reflection on the advantages and disadvantages of making estimates

I cannot comment on the subway project to which it refers, for several reasons:
1. I don't know what techniques and tools they used to make cost and time estimates
2. I don't know if there was a change request
3. I don't know the impact that these change requests had on the scope, cost and timeframe
4. I don't know what the overall value of the project is in order to have an idea of ​​the magnitude of the 400 million to which it refers

Contract time and materials
Who is the main beneficiary? The salesperson or the customer?

Based on the assumption that a time and materials contract is closed, how does the customer control the time and materials used?
Instead of such a contract, why not a contract based on delivered results (now called outcomes)

Even in contract time and materials, the seller provides a high-level estimate to the customer

Please Login/Register to leave a comment.

ADVERTISEMENTS

"Bad artists copy. Good artists steal."

- Pablo Picasso

ADVERTISEMENT

Sponsors