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:
- 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).
- 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.
- 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.
- 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?
- 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.
