Why We Estimate

We’ve received multiple questions about how to approach estimation after we shared our thoughts on Twitter. As Rozi and I were discussing our ideas around engineering project time estimation, we realized that there tends to be a crucial nuance that’s missing when folks discuss estimation: why you are making an estimate is critical in determining how you should approach making that estimate.

Estimation advice is worthless if you aren’t paying attention to the underlying reason behind the estimation request. This is where our journey will begin.

Table of Contents:

  1. The Fundamental “Why”
  2. The Situational “Why”
  3. The Philosophical “Why”

The Fundamental “Why”

There are two interlocking reasons we provide estimates in all facets of life.

First: we are creatures that live in a world dominated by Time. None of us can stop, slow, or reverse the unyielding march of Time.

Second: we do not operate in the world alone. We are interactive, community-based creatures. We live in a complex ecosystem that depends on cooperation and coordination to function at all, let alone properly. Without cooperation and community, our civilizations and astounding achievements would not exist.

In order for humans to coordinate, plan, and work together, we need to understand how other humans operate in the world.

Estimates are one tool that we use to facilitate coordination and cooperation.

This fundamental “why” behind estimates is not debatable. We estimate because Time is important. A refusal to estimate – “it takes as long as it takes” or “I’m not telling you how long I think that will be” – ignores the fact that time matters when attempting to coordinate humans. This is especially true within an embedded systems project.

We live in a universe ruled by Time. You cannot talk your way out of its importance.

The Situational “Why”

While the fundamental “why” behind estimation is inescapable, the situational “why” is ever changing.

Estimation is more than attempting to make a perfect guess at how long something will take you. When we lock onto that singular context, it’s easy to dismiss estimation as “impossible”, and understandably so: who can be right on the money every single time?

The truth of the matter is that there are a variety of different reasons underlying a request for an estimate. Likewise, different estimation approaches are suitable for different situations and it is always possible to make such estimates.

Consider these common situations in an engineering company where we provide time and cost estimates:

  • Giving a timeline to the wider team during a status update meeting
  • Allocating work for a week or sprint
  • Providing a proposal to a client
  • Making an operational budget for the year or quarter
  • Setting company goals and priorities for the year or quarter
  • Comparing two tasks in terms of relative complexity, time commitment, and cost, with the goal of determining which to pursue
  • Determining whether the current team can meet the stated goals, or whether to hire additional man power
  • Figuring out what features can make the next scheduled release
  • Figuring out what the team can complete while working toward a drop-dead date
    • This could be any drop-dead date: committed manufacturing run, contract with a client, company will run out of money if you don’t ship, company needs to raise a new round of funding, etc.

Each of these scenarios has a different purpose in mind for the estimates, and each implies different precision/accuracy/confidence targets. If you cannot understand the underlying scenario, you are likely to provide the wrong level of precision or information that is not valuable to the requesting party. A project manager trying to hit a release date that is two months out may want a detailed task-by-task breakdown, while an executive deciding which direction to take the company in needs gross estimates and confidence intervals.

For example, here is a high-level overview of the work Embedded Artistry has planned for 2020. We set company goals for the year. I looked over the list of goals to determine what I thought was feasible, then made a high-level schedule for how I plan to achieve those goals.

The estimates provided are in months and we do not provide daily or weekly breakdowns for the projects. The estimates might be wrong, and we can recover if are by deprioritizing certain projects, shifting around plans, changing the scope of our efforts, or getting external help. We believe there is a high probability that we weill stay on track – we considered our insight into these projects, the work already done, and the work required to complete them in order to make the initial estimates.

This kind of estimate looks very different from one we’ll make internally for a client project, as shown below. Notice in this image that we list high-level tasks, significant sub-tasks that dominate the time spent on a higher-level task, and target due dates. We use these due dates to help us determine the final project delivery date. We adjust the dates until we are comfortable with the perceived risk levels of each major task and the overall project.

This differs in the detail we present to our clients in a proposal, where we list the start date and completion date: the two pieces of information our clients need. For most projects, our clients simply do not care about the task breakdown or day-to-day estimates – those details are just noise. They want to know when they can count on a solution to their problem.

You must understand the reason you are being asked to provide an estimate. The underlying situation dictates the method, decision-making criteria, desired precision, and desired accuracy.

The Philosophical “Why”

We can step beyond the fundamental reality of living in our universe, and the situations we’re dealing with, to see how estimates can serve us.

One of my role models, Ruth Malan, shared these underlying philosophical reasons back in 2014. We cannot forget that estimates are merely a guiding tool that helps us make some sense of the world:

Estimates are “stakes in the ground” so we can see the lay of things, so we can sense and probe where the unexpected is rearing its unsettling head so we can move the stakes and design for and around. Estimates are simply tools in the “how to use conscious purpose” game. They help us learn. We figure out as best we can, and then we sense and probe. We assess, orient and adapt. To surface and illuminate issues. To respond. To better understand. To become more wise. More wise, because there is uncertainty and it takes insight and foresight to shape systems – including the social systems creating systems – to enable more the outcomes we want.

We use estimates because there is a world of infinite possibility at our feet. We need tools for deciding how to invest our limited time and resources.

So why bother with estimates? Because we have to make investment and prioritization choices on the one hand – sorry, we can’t do it all, so how do we decide what to do, and what to not do?

Humans rarely work alone. We often have dependencies on other humans, and other humans have dependencies on us.

And, on the other, we have dependencies and we are trying to raise awareness around what those dependencies are, how they interact, and what to expect – even as we actively reshape what we expect.

Estimates are one tool that we use to shape expectations and interactions within the context of the system we’re taking part in.

We estimate, because we don’t know. Estimate – you know, roughly, approximately, judge what we anticipate the cost and schedule to be. Under great uncertainty – very roughly! But we do so to see how we are tacking, so we can estimate and re-estimate expectations for all the flows of activities we’re bringing together – not just different pieces of the system like infrastructure or hardware, and software or firmware, or whatever, but also so others in the value stream can be doing their parts.

We can’t avoid the fact that interdependent teams need to understand when and how they can work:

For teams that fit within broad webs of interdependencies from threads and flows of value that come together various ways (for new products, there’s manufacturing setup, supply chain preparation, channel readiness, partners that need to stay in sync, hw/fw/sw teams, etc.), it helps to have open communication, including a sense – that is updated and adapted as more is learned – when and how others can play their roles.

We know that nothing works out perfectly according to our plans. Estimates serve as a tool that helps us decide when to invest in contingencies, alternative courses of actions, adding buffer to other parts of the system (e.g. “raise more funds, this is uncertain”). On Twitter, Ruth expanded her thoughts by pointing out that estimates are a tool we can use to promote learning:

They are about making (our expectations, understanding of dependencies, etc) VISIBLE — So that we can learn.

We are limited creatures, willfully and unwilfully blind to the immensity of the world. By surfacing our expectations, learning about dependencies, and seeing what we missed, we can adjust our thinking for the next task/project/product. We can push past our emotional nature and make our behavior just a bit more transparent.

Remember “Why”

Fundamentally, our colleagues need visibility into how long certain features will take to develop. Before you apply any effort toward estimation, you must remember to dig in to the situation and understand why you are being asked to deliver an estimate. Then you’ll want to provide the right information, within the right context, at the right levels of granularity/accuracy/precision/confidence for each estimate request. Providing work product time estimates is an important part of keeping the engineering world turning, especially on multi-disciplinary efforts such as embedded systems development. Estimation is certainly not an impossible feat.

Share Your Thoughts

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