Estimates and the desire to be lied to

A manager who does not accept estimates with range for uncertainty demonstrates a desire to be lied to.

A mundane corporate drama

We’re at a staff meeting of a company reliant upon but not about software.

Halfway through the hour long meeting, they start talking about a new software dependent product. The product has been a bullet point and a few sentences for months but now has some artwork and wireframes.

After a general conversation, the sponsor turns to the development team, “How much work is this?”

The team makes an educated guess – whether on the spot or after some closed room review. They express this as:

  • a rough sense of effort (easy, hard)
  • analogous to some other project or effort (at least as much work as)
  • a broad timeframe (month, quarter, week)
  • a range (it will take 2-4 days/months)
  • The team also describes some of the risks and uncertainties in general terms.

“Yes, but on what date will it be done? How much will it cost?”


What is an estimate?

A prediction made at a point in time with best available knowledge.

An estimate is fraught with more or less uncertainty. Early on an estimate has a very high degree of uncertainty — as high as an order of magnitude. As work proceeds depending on the risks involved, an estimate can become more accurate.

An estimate is subject to risk tied to the nature of the work, the organization, and/or external conditions.

Formal estimates (intended for consumption outside the team itself) should be expressed at an appropriate precision for the point in time they are made and with an appropriate range of error. Formal estimates should always include some analysis of the risks that might affect that estimate.

In our drama, the range of error is wildly large.

  • What is being built has never been built before — or — if it has, not by this particular team.
  • The build requires new learning and original problem solving.
  • The product launch is dependent upon third party tools, existing systems or data.
  • The ‘team’ doesn’t represent all the skills and access required to complete the software.

More fundamentally:

The sponsor doesn’t know what they want and to the degree they think they know what they want it will change during the course of the project.

And, even more fundamentally:

The sponsor isn’t the end user and doesn’t exactly know what those end users will find useful or desirable.


An estimate is a planning tool. Not a bid. Not a commitment.

A bid is a proposal to do a certain amount of work for a certain cost. It may or may not lock in a minimal required delivery. If so, it is managed as a revenue stream and losses against that stream are made up by other streams. A certain overhead for profit is planned in. A contract formalizes this as a business arrangement.

A commitment is a determination by a group of people to meet a certain goal. It is a real commitment if people make it themselves, there’s a clear and demonstrable definition of completion, if they believe it is achievable, if it is achievable, and if achieving it actually makes a difference for the individuals involved and for their company.


“Yes, but on what date will it be done? How much will it cost?”

“Give yourself a margin for safety – say 10% to 15%. I want a date I can trust.”


Why do estimates become a contract?

  • Companies lock in resources and budgets months before any work is under way.
  • Managers are under pressure to provide hard dates and costs to their bosses.
  • Managers may be used to working with outside vendors on a fixed cost basis.
  • Managers may be experienced in another kind of business with well-established, repeatable processes.

When people are under pressure they embrace certainty – even when they know none exists. Short of that certainty they want to know their staff cares, will work hard and is committed to delivering for them.

And they want the team to demonstrate their commitment by making a commitment.

But if the manager is capable of trust and new learning, has good intentions, and is focused on achieving their goals a team can turn this dysfunction around over time.

If not, seriously, look for another job because this one will cause you pain and stress. It will likely waste your hard work. It will rob you of joy and it may drive you from the software field altogether.

Rather than refuse to commit or make a bullshit commitment, commit to working toward your mutual success:

  • Communicate an understanding of what a sponsor is trying to acheive.
  • Demonstrate through your actions that you are working to help them achieve it.
  • Acknowledge their need to make schedule and budget commitments to the degree they really need to do this
  • Provide your estimates but be honest about the risks and uncertainties.
  • Attack the idea of “done”. The software may (should) be releasable before the full scope is built and it will require work after it is released.
  • Challenge and test assumptions about what features/implementations are needed.
  • Demand the sponsor’s participation in negotiating scope all along the process.
  • Make your progress visible both in tracking metrics against the goal and in demonstrating actual working code. Revise your projections as you go based on better information.

And don’t just build what your told. Build what people need. Waste as little as you can to get there.

On the Media – cruelty and vulnerability on the internet

Streams of two segments from the NPR show On the Media:

Smirch Engine

There’s a name for how cruel people can get given a little anonymity on the internet. It’s called “online disinhibition effect” and the resulting venom can ruin your day or worse, destroy your good name.

The Net’s Mid-Life Crisis

The basic architecture of the Internet hasn’t changed since it was conceived 40 years ago. But what was once the playground of wonks is now the main staging area for the global economy and open to an array of security vulnerabilities.

Fail fast

Panic Button by aperte on flickrFail fast is a technique for improving the quality of software:

“failing immediately and visibly” sounds like it would make your software more fragile, but it actually makes it more robust. Bugs are easier to find and fix, so fewer go into production. — Jim Shore

Scrum aspires to a fail fast approach to building software.

It describes practices that surface problems:

  • a backlog prioritized by the product owner and estimated by the team (accountability)
  • short iterations
  • frequent retrospection
  • a role dedicated to removing impediments

It champions values that motivate individuals to address problems:

  • delivering business value
  • collaborating with customers
  • empowering teams
  • building quality in
  • continuous improvement
  • courage and honesty (a refusal to hide risk)

Possessing these values and practices, an organization is less likely to overlook or tolerate dysfunction when it materially affects the setting and achieving of project goals.

  1. risks are identified before they become problems
  2. simple problems are detected and resolved quickly
  3. thorny problems are mitigated
  4. catastrophic problems are aired to all concerned parties (informed consent)

Cases #1-3 increase a project’s chance of creating value.

Case #4 compels an organization to cancel a doomed project.

All four cases represent a better outcome for the business. Assuming that business offers value to the world, that’s better for our end users, our reputation, and our society.

Immediate and visible failure. Much preferable to hidden, prolonged and inevitable failure.