How to Solve the Double Standard of Software Estimates

The double standard exists. There is an antidote.

Photo by Pixabay

Recently, I had some repairs done to my car.

“There’s a noise coming from the rear wheels. The faster I go, the higher frequency of the sound. I think it’s on the left side.”

Ok, that sounds like a rotational noise. We can take a look — our diagnostic fee is $259. We will apply that to any repairs based on what we find. We will call you with what we find and confirm how to proceed.

My family had some home remodeling done last year to update the roof and siding on our house.

Here is our estimate for material and labor, based on what we can see from the outside. As we get into the work, we may find other work you need. We will call you each time with the details and let you know how much more it will be.

In both cases, I was the stakeholder. The artisans were my engineers. Both experiences left me thinking about what I can learn from these disciplines to apply to software engineering.

I would receive a call when they found something new. As a stakeholder, I would be informed of the details as they emerged. The artisans kept the time to surprise to a minimum.

Each experience was matter-of-fact about the work. New tasks were identified, which needed to be completed and paid. I knew the original estimate of time and money. Yet, I still had to wait and pay for the extra result.

The workers could not predict the new work from the outside. It wasn’t until taking things apart and digging into the details that they could identify all the work. Along the way, I would get frequent calls to update me on the current status.

When new work did emerge, the artisans adjusted timelines. Working late was not an option for safety reasons. The workers treated weekends the same way. Working faster did not mean anything. Cutting scope meant accepting an unacceptable level of quality.

My experience with stakeholders of software teams has been a complete contrast to what I saw with the trades:

  • immediate negotiations to bring the time and cost down
  • a strong desire to control everything upfront, before taking things apart
  • an emotional reaction when the team does notify stakeholders of any changes.

Stakeholders can learn from their interactions with the trades. Apply that thinking to your Engineering teams. This results in trust, better relationships, more creativity and a high-quality product.

Use Meaningful Words

Engineers have to control the narrative when it comes to estimates. The first step involves actively setting expectations. Along with that, explaining the words you are using becomes crucial.

deadline is a point in time that, if missed, will result in dire consequences.

Deadlines are standard when there is an expensive next step. For example, newspapers (when they were printed) needed to be set and run on the presses. Likewise, physical items need to be manufactured after they are designed.

A deadline without consequences is meaningless. Using artificial deadlines adds tension and erodes trust. Both the date and the consequences have to make sense.

Deadlines do make sense when you need to coordinate with somebody else’s schedule.

commitment is a promise that something will happen.

Commitments can only come from those involved in doing the work. Commitments are binding. Commitments are obligations that you take on wholeheartedly.

An estimate is an informed guess.

Based on some prior experience, an estimate is a guess about how long a piece of work will take.

When you want to get some work done on your house, you’ll get an estimate. The workers will tell you how much it will cost and how long the job will take. They come to this based on the size and shape of your roof and their experience working on similar roofs.

schedule is a list of intended events that will happen.

Estimates will contribute to a schedule. Other events outside of this work will also contribute to the plan. Plan is a synonym for schedule. A good plan assumes that you’ve listed out everything that will take up your time.

Finally, a forecast is the rate of executing against an estimate. A forecast uses the trends from recent history to predict how things will go. A forecast is an informed estimate, backed by data about completed work.

Given what I know now, this is my estimate. This is a guess. It’s not a forecast based on a trend, and it’s not a commitment or a promise that we will hit a certain date. As we learn more, I will adjust the estimate and keep you updated.

The biggest confusion in software development happens when estimates turn into deadlines without everyone involved. Use the specific term to explain what you are talking about. Contrast that to that other terms that you are not using.

Set and Manage Expectations

Engineering teams can apply these critical lessons:

  • explain what
  • set the expectation that we will learn more after we get started
  • come to terms — explain the difference between an estimate, a forecast and a commitment
  • immediately share what changes along the way
  • hold yourself to safety and quality standards.

Use analogies your Stakeholders understand.

When you are talking to someone in Finance, or the CEO for that matter, compare software estimates to a financial forecast. Explain that, like the companies annual plan, an estimate cannot double as a prediction. As you encounter more information, you will update the plan and inform your stakeholders.

When you are talking to some in Sales, compare it to the sales targets. These are goals, informed by the market, that will direct the behavior of the sales team. And the sales team will work as hard as they can to reach this goal. When it is set, however, a sales target does not represent the final sales number you will get at the end of the period.

When you’re talking to Marketing or Operations, contrast the custom innovative work you are doing with the repetitive task-based work of the agencies that they work with.

Cut through the double standard. Explain the terms you use, what each word means. Contrast your terms with what it does not mean. Use analogies to other departments, and to common trades, to drive your point home.

Your actions are the antidote to the double standard.


Posted

in

by