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:
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.
In the previous blog in this series, The Art of Guesstimation: Estimation on Software Projects, we explored the differences between guesstimates and estimates, and in this blog I will use the term estimate to refer to both. Because estimation isn’t limited to projects I will use the term endeavor to refer to efforts that are organized either as a project or as a non-project. As Simon Sinek suggests in Start With Why: How Great Leaders Inspire Everyone to Take Action we should start by explaining why something is important. From that point of view, it makes sense to ask why should invest the effort to estimate the time or cost of an endeavor?
Estimates are often required for several reasons:
To summarize, there are several reasons why we should consider investing the time and money required to produce estimates. In the next blog in this series I will explore reasons for why you don’t want to invest effort in estimating.
This is the first of several blog postings that I'm going to write on the Art of Guesstimation. I guesstimate that I'll be writing 7 +/- 2 postings on this subject, depending on how our conversation progresses and how I decide to divide the overall topic into blog postings (I currently have a plan but I suspect it will evolve based on feedback). My eventual goal is a detailed article on the subject, likely sometime in February 2020.
You've liked noticed that I have been using the term guesstimate rather than estimate. This isn't a typo.
In early December I was in Las Vegas at SeminarsWorld co-teaching the inaugural Disciplined Agile Lean Scrum Master (DALSM) workshop with Al Shalloway. One of the topics that we covered was Agile Estimation where I brought up the fact that estimates are often guesses, particularly in the IT space. This was a bit of a shock for some students as it went against their project management belief system. Interestingly one student had a story about they had recently had a conversation about this very issue with some of her stakeholders when they weren't given the "exact answer" as to the potential cost and schedule of an IT project they were about to embark upon.
So let's move away from a belief-based discussion in favour of a fact-based discussion by seeing what the dictionary has to say on the subject. Merriam Webster defines estimate as:
So, particularly given 2 and 3, there is a bit of wiggle room in our estimates. Now let's consider the definition of guesstimate, which has been a "real word" since 1923. According to Merriam Webster, a guesstimate is an estimate usually made without adequate information. Hmmm.... sounds a lot like the situation faced by most teams in the software space, doesn't it?
The traditional response to the problem of inadequate information is to perform detailed analysis and design early in a project. In theory this should work, but it flies in the face of several unfortunate challenges faced by software teams:
None of these challenges are addressed well by detailed, up-front modelling and planning. The unfortunate reality is that at the beginning of a software project, and I suspect for any project similarly focused on intangible things, the information that we will base our initial estimates on will be vague at best. This tells us that in the early days of a software project we are clearly guesstimating. As the project progresses our stakeholders have a better understanding of what they actually need and the team has a better understanding of how they're going to meet those needs. The implication is that over time we can tighten up our guesstimates until we eventually find ourselves in a situation where the term "estimate" begins to become viable.
Future postings in this series will focus on how estimates are really probability distributions, what we're really saying when we say "on time" or "on budget", why we should provide ranged guesstimates even though many people still want to hear "exact" estimates, truisms about guesstimation, and how Disciplined Agile (DA) improves upon Agile's classic burn down and burn up charts to provide ranged estimates.
Planning: The Efficiency Zone
Yogi Berra was fond of saying “If you don’t know where you are going, you’ll end up someplace else.” What Yogi was getting at was that it’s a good idea to do a bit of thinking, a bit of planning, before you get started. In the previous blog, Planning: When Have you Done Enough? we explored the factors that affect how much planning we should do. The challenge is that the factors are qualitative in nature, requiring us to make a decision that is based on intuition.
In this blog we explore how to increase the chance that we get as close as we can to achieving the maximum value from our planning efforts. The following figure is organized into four planning quadrants, each one of which represents a target area for our planning efforts.
Figure – The four quadrants of planning efficiency.
Let’s explore each quadrant. In order from most desirable, to least desirable, they are:
Eisenhower said “Plans are worthless, but planning is everything.” There can be significant value in planning, but it is possible to go too far, to plan too much. Although more research is needed in this space, it appears that the value of planning follows the law of diminishing returns – there is significant value in doing some planning, but that value quickly reaches a maximum point. Determining that maximum point is a qualitative, “gut feel” decision based on a collection of factors such as the complexity and risk of the situation, the skills and experience of the people involved, and the uncertainty that you face. Surprisingly, the most efficient approach to planning is to aim for your plans to be slightly insufficient, to be close but in need of a bit more work when you discover that you need to work through a few more details. I hope this blog series has been food for thought.
Planning: When Have We Done Enough?
In the previous blog we examined what the value of planning is, so that we can then determine how much planning we need to do. The answer to this question was “it depends,” and the implication was that we need to do just enough planning for the situation that we face and no more. In this blog we go deeper to explore what this depends on in practice.
We learned in the previous blog that our planning efforts should be sufficient, what we referred to as just barely good enough (JBGE) in Agile Modeling, for the situation that we face. The following figure depicts the contextual factors that we should consider, with the factors motivating us to do more planning on the left-hand side under the red arrow and the factors enabling us to do less planning on the right-hand side under the green arrow. These factors are mostly qualitative in nature, implying that it requires a judgement call on the part of the people involved with the planning effort to determine whether they’ve planned sufficiently. Let’s explore each of these factors in more detail.
Figure. The factors to determine whether you’ve planned sufficiently.
There are four factors that motivate us to increase the amount of planning we do:
There are six factors that enable us to reduce the amount of planning that we need to do:
To summarize, the answer to “when have we planned sufficiently?” is “it depends.” In this blog we explored several factors that motivate you to increase the amount of planning we need to do and several factors that enable us to reduce the amount of planning. In effect we went beyond the typical consultant answer of “it depends” to the more robust answer of “it depends on this.”
In the next blog in this 3-part series we explore how to be efficient in our planning efforts. I suspect the answer it won’t be what you’re expecting.