Showcase

Running a successful delivery · Before signature

An estimate they can’t refuse.

1Why estimates miss
2Four pitfalls
3How to estimate
4From estimate to contract

For Sales and TechPrashant Mittal, realfast

About twenty minutes. Sales and Tech together. Open with the title.

The title is borrowed from The Godfather. An offer you can't refuse is one with no room to argue. That is what we want from an estimate: not the lowest number, and not the one the client hoped for, but one that is so clearly reasoned that neither side wants to argue with it.

Today is about the weeks before signature, when Sales and Tech put a number on work nobody fully understands yet. On many of our projects that number turns out wrong, and we find out in month three, when it is expensive for both sides.

Four parts. Why estimates miss, even good ones. Four pitfalls that make them miss more. How to estimate well, step by step. And how to turn the estimate into a contract.

Most of this comes from outside realfast: estimation research by Steve McConnell and Magne Jørgensen, Bent Flyvbjerg's work on overruns, and forecasting practice from agile teams. Sources are on the last slide.

1 · Why estimates miss

When you write the proposal, the real cost can be anywhere from a quarter to four times your number.

Source: Steve McConnell, Software Estimation (2006), after Barry Boehm (1981). Best-case ranges for skilled estimators.

An estimate they can’t refuse · Sales and Tech02 / 18

Walk the cone left to right. Stop on the shaded band.

This is the cone of uncertainty. Barry Boehm first drew it in 1981, and Steve McConnell made it famous. It shows how far off a good estimate can be at each stage of a project.

At the initial concept, the real cost can land anywhere from a quarter of your estimate to four times it. That is a sixteen-fold range, and it is the best case, for skilled estimators. Once the product is defined, it narrows to half to double. Only when requirements are complete does it get to about plus or minus fifty percent.

Now look at the shaded band. That is where we write proposals: somewhere between the first call and a defined product. We are estimating in the widest part of the cone.

So the first lesson is about honesty, not technique. At this stage, a single number is not an estimate. It is a guess with false precision. Everything in the rest of the talk is about working with that range instead of hiding it.

1 · Why estimates miss

The average overrun is 27%. The real risk is the one project in six.

Figures: Bent Flyvbjerg and Alexander Budzier, 1,471 IT projects, Harvard Business Review (2011). Curve shape is illustrative.

An estimate they can’t refuse · Sales and Tech03 / 18

1 · Why estimates miss

An estimate, a target and a commitment are three different numbers.

When the target falls outside the range, change the scope or the date. Don’t change the estimate.

An estimate they can’t refuse · Sales and Tech04 / 18

The vocabulary slide. Most estimation arguments are about the wrong word.

Steve McConnell makes a distinction that clears up most estimation arguments. There are three different numbers, and we usually use one word for all of them.

The estimate is what the work will probably take. It is a range, here eleven to twenty-one weeks, most likely fourteen. It belongs to the people doing the work.

The target is what the business wants. Here, week ten, because there is a launch event. Targets are legitimate. They belong to the client.

The commitment is what we promise. Week eighteen, for an agreed scope. It is a decision, taken knowing the estimate and the target.

Here the target sits outside the estimate. That is a normal situation, not a crisis. It is the start of a conversation about scope: what can we deliver by week ten? What gets cut, or moved to a second release? What you must not do is quietly change the estimate to match the target. That moves the problem to month three.

2 · Four pitfalls

Pitfall one: the client’s number moves yours, even when you’re told to ignore it.

Group told

“The client thinks 50 hours”

77 hours

Group told

“The client thinks 1,000 hours”

632 hours

0Median estimate, software professionals, same specification632 h

Estimate before you hear the budget. Then compare.

Magne Jørgensen and Dag Sjøberg, “The impact of customer expectation on software development effort estimates” (2004).

An estimate they can’t refuse · Sales and Tech05 / 18

The most important research in this talk. Let the numbers land.

Magne Jørgensen at Simula in Norway has spent twenty years studying how software people estimate. In one experiment, he gave two groups of professionals the same specification. One group was told, in passing, that the client thought it would take about 50 hours. The other was told the client thought 1,000 hours. Both groups were told that the client knew nothing about software, and that they should ignore the number.

The median estimates were 77 hours and 632 hours. Same work, eight times apart. And when asked, the professionals said the client's number had not influenced them.

This is anchoring. Any number you hear first pulls your estimate towards it: the client's budget, a competitor's quote, what the salesperson hopes for, last year's similar deal.

The fix is simple and a little uncomfortable. Tech estimates before hearing the budget. Then compare the estimate with the budget, openly. If they are far apart, that's a scope conversation, which is slide eight.

For Sales: keep asking for the budget. It is essential for shaping scope. Just don't pass it to the estimators until they've written their number down.

2 · Four pitfalls

Pitfall two: asked for ranges they were 90% sure of, people got fewer than 3 in 10 right.

2.8of 10

average score on McConnell’s 90% confidence quiz

Range held the answerRange missed

Our ranges are too narrow, because a wide range feels like admitting we don’t know. At proposal stage, we don’t.

A wide honest range beats a narrow wrong one. Widen it until you’d bet on it.

An estimate they can’t refuse · Sales and Tech06 / 18

Optional: run three quiz questions with the room first.

McConnell's book opens with a quiz. Ten general-knowledge questions, like the surface temperature of the sun or the year a famous person was born. For each one, give a range you are 90 percent confident contains the answer. If you do it right, you should get nine out of ten.

The average score is 2.8 out of ten. People make their ranges far too narrow, even when there's no reason to. Nobody is judging them, and they are explicitly told to be 90 percent sure.

McConnell's point is that the pressure to look precise comes mostly from ourselves. A wide range feels like admitting we don't know. But at proposal stage, we don't know. The cone said so.

A practical test: would you bet a month's pay that the real number lands inside your range? If not, widen it until you would. A range of ten to twenty weeks that holds is far more useful than "twelve weeks" that doesn't.

2 · Four pitfalls

Pitfall three: most estimates cover the code and forget the project.

What gets estimated

Build the features

What the project needs

Build the featuresEverything else

Environments and access

Integration with their systems

Testing and bug fixing

Security and privacy review

Data migration and cleanup

Deployment and release

Demos and weekly updates

UAT support

Waiting on client inputs

Documentation and handover

Code review

Project and delivery management

Add a line for every item, even if it says zero. A zero you chose is fine. A zero you forgot is an overrun.

Bar proportions are illustrative. Checklist after McConnell’s list of commonly omitted activities.

An estimate they can’t refuse · Sales and Tech07 / 18

Read three or four items aloud. Ask the room which ones they've missed before.

When engineers estimate, they estimate what they picture: building the features. That part is often estimated quite well. The trouble is everything else a project needs.

McConnell lists omitted activities as one of the most common sources of estimation error. Look at the checklist. Getting environments and access. Integrating with the client's systems, which is never as simple as the docs say. Testing and fixing bugs. A security review. Data migration. Deployment. The weekly demo and update. Supporting the client's UAT. Waiting for client inputs. Handover documents. And managing the whole thing.

The proportions on the bar are illustrative, but on many projects this "everything else" is close to half the effort. If your estimate is a list of features with days next to them, it is missing it.

The fix: keep this checklist next to every estimate, and add a line for each item, even if the line says zero. A zero you decided on is fine. A zero you forgot is an overrun.

2 · Four pitfalls

Pitfall four: under pressure, we negotiate the estimate. Negotiate the scope instead.

Negotiating the estimate

Client“Can you do it in eight weeks?”

Us“We’ll make it work.”

Same work, less time. The gap doesn’t go away. It shows up in month three, for both sides.

Negotiating the scope

Client“Can you do it in eight weeks?”

Us“Here’s what fits in eight weeks, and what moves to phase two.”

Less work, same honesty. The trade-off is visible, and the client makes it.

It’s easy to haggle over a single number. It’s hard to haggle with a range that shows its reasons.

An estimate they can’t refuse · Sales and Tech08 / 18

The Sales slide. This is where most estimates actually break.

The fourth pitfall is the one we feel most. The client says "can you do it in eight weeks?" The deal is close. And someone says "we'll make it work."

What just happened is that the estimate changed, but the work didn't. Flyvbjerg has a name for the pattern at scale: the planning fallacy, which is honest optimism, and strategic misrepresentation, which is shaving a number to win. Either way, the gap between the work and the time doesn't disappear. It moves to month three, where it is a problem for both sides: we lose margin, and the client gets a late or rushed delivery.

The alternative is to negotiate the scope, not the estimate. "Here's what fits in eight weeks, and here's what moves to phase two." Now the trade-off is visible, and the client makes it, which is where that decision belongs.

This is easier when the estimate is a range with reasons behind it, which is part three. It is hard to argue with a well-reasoned range. It is easy to haggle over a single number.

3 · How to estimate

Step one: break the work down, then sort each piece by how much you know.

Treated as

Everything estimated the same way

What it really is

KnownAssumedUnknown

Bar proportions are illustrative.

Known

You’ve built it before, or you could write the test today.

A tight range

Assumed

You believe it, but nobody has checked. The API exists. The data is clean.

A range, plus the assumption in writing

Unknown

Nobody can answer yet. Model accuracy on their data. How the old system behaves.

No estimate. A timeboxed spike

An estimate they can’t refuse · Sales and Tech09 / 18

The core move. Small pieces, then three bins.

Step one is to break the work into pieces small enough to reason about. A rule of thumb: no piece bigger than about two weeks of one person's work. Big pieces hide surprises. Include the forgotten-work checklist from slide seven as pieces too.

Then sort each piece into one of three bins. Known: you have built it before, or you could write the acceptance test today. Give it a tight range.

Assumed: you believe it, but nobody has checked. The API exists and does what we think. The data is clean. Give it a range, and write the assumption down, with what happens if it's false. Those assumptions go into the proposal.

Unknown: nobody can answer yet, not us and not the client. Don't estimate these at all. Any number would be invented. Give them a timeboxed spike instead: "three days to find out how the old system handles refunds", then estimate after.

Look at the bars. We usually estimate everything the same way, as if it were all known. In reality, part of it is assumed and part unknown. The proportions here are illustrative, but try it on your last estimate.

3 · How to estimate

Step two: give every piece a best, likely and worst case. The likely case is not the average.

expected = (best + 4 × likely + worst) ÷ 6

Add up the expected values, not the likely ones.

Three-point (PERT) estimation. Example task is illustrative.

An estimate they can’t refuse · Sales and Tech10 / 18

One formula. Show why it matters with the example.

For every piece, ask three questions. If everything goes well, how long? What's most likely? And if things go wrong, the realistic worst case, not the apocalypse?

Here's one task. Best case ten days. Most likely fifteen. Worst case thirty-five. Notice the shape again: it can't go much faster than ten, but it can go a lot slower. Remember the long tail.

The classic three-point formula, from PERT, weights it: best plus four times likely plus worst, divided by six. Here, that is 17.5 days, not fifteen. The long right side pulls the expected value up.

That is the point of the slide. If you add up the "most likely" numbers for fifty tasks, you will be late, because each one is a little optimistic and they add up. Add up the expected values instead.

A bonus: when someone gives you a worst case three times the likely case, that's a signal. That task probably belongs in the assumed or unknown bin.

3 · How to estimate

Step three: estimate alone first, then talk about the biggest gaps.

Three to six people, at least one who will build it. Sales joins after the number is written down.

Wideband Delphi, after Barry Boehm (1981). Values are illustrative.

An estimate they can’t refuse · Sales and Tech11 / 18

The gaps are the value, not the average.

One person's estimate carries one person's blind spots. The fix is a method called Wideband Delphi, which Barry Boehm popularised. Planning poker is a lighter version of the same idea.

Three to six people. At least one of them should be someone who will actually build it. Each person estimates alone, in writing, so nobody anchors on the most senior voice. That's pitfall one again.

Then look at the spread. In round one here, it runs from six to twenty-eight weeks. Don't average it. Ask the highest and the lowest to explain. Almost always, they're imagining different work. One assumed the client's API is ready. The other has integrated with that kind of system before and knows it isn't. That conversation is the most valuable thing in the whole estimate. Write down every assumption it surfaces.

Then estimate alone again. The range narrows because people now share the same picture of the work, not because they're pressured to agree. Two or three rounds is usually enough.

Sales joins after the number is written down, for the same reason: no anchoring. Then Sales brings the budget, and you compare.

3 · How to estimate

Step four: check the total against your own track record.

The bottom-up estimate

×

What this kind of project really took last time

=

The number you quote

Keep one shared sheet: sold effort against actual effort, by project type.

Project type	Sold	Actual	Actual ÷ sold
Agent build	60 d	78 d	1.3×
Integration	40 d	46 d	1.15×
Rescue a build	30 d	57 d	1.9×
Rewrite	90 d	180 d	2.0×

Illustrative figures. The tick marks 1×, on plan.

Ten real data points beat any amount of optimism.

Reference class forecasting: Bent Flyvbjerg, after Daniel Kahneman and Amos Tversky.

An estimate they can’t refuse · Sales and Tech12 / 18

The numbers here are made up. Say so. The habit is the point.

Everything so far is a bottom-up estimate: you look at this project from the inside. Daniel Kahneman showed that inside views are reliably optimistic. He called it the planning fallacy. The correction, which Flyvbjerg calls reference class forecasting, is the outside view: how did similar projects actually turn out?

We can do this with our own history. One shared sheet. For every finished project: the type, what we sold, what it actually took, and the ratio. When you estimate a new project, multiply the bottom-up total by the typical ratio for that type, or at least explain why this one is different.

The numbers on the slide are illustrative, not ours. But the pattern is common: work you know well runs a little over, and rescues and rewrites run far over.

The sheet doesn't exist yet. Ten real data points would already beat anyone's gut feeling, including mine. That's one of the asks at the end.

3 · How to estimate

Step five: quote a range and a confidence, not a single number.

Say it as: “14 to 18 weeks. We commit to 18, for this scope.”

Probabilistic forecasting, as practised with Monte Carlo simulation (Troy Magennis). Curve is illustrative.

An estimate they can’t refuse · Sales and Tech13 / 18

This is the estimate they can't refuse. A range, a confidence, and the reasons.

Once you have three-point estimates for every piece, you can do something better than adding them up. You can ask: what is the chance of finishing by each date? A simple Monte Carlo simulation in a spreadsheet does this: it plays out the project thousands of times, picking a random duration for each piece within its range, and counts how often you finish by each week. Troy Magennis has free spreadsheets for exactly this.

The result is a curve like this one. Read it like this. By week fourteen, there's a fifty percent chance you're done. That's P50, a coin toss. By week eighteen, eighty-five percent. That's P85.

Most teams quote the P50 without knowing it, because they added up most-likely numbers. That means they're late half the time, by design.

The habit: commit to P85, and say the range out loud. "Fourteen to eighteen weeks. We commit to eighteen, for this scope." That sentence is hard to argue with. It shows you've done the work, it's honest about uncertainty, and it gives the client something firm to plan against.

You don't need the simulation every time. Even the three-point totals give you a rough P50 and P85. The point is to stop pretending a range is a number.

4 · From estimate to contract

When the range is too wide to price, buy information first.

At the proposalproduct defined

0.5×2×

After a paid discoveryrequirements done, 2 to 3 weeks

0.67×1.5×

0.5×1× the estimate2×

Discovery hands over

What we will build, in handover terms

A Definition of Done both sides sign

The unknowns, now spiked

An eval set, for AI work

A P85 build estimate

Fixed fee, credited against the build. The client leaves with a plan they can use either way.

Ranges: McConnell, cone of uncertainty. Diagnose before prescribing: Blair Enns.

An estimate they can’t refuse · Sales and Tech14 / 18

The biggest single move. When estimating can't narrow the range, discovery can.

Sometimes you do everything right, and the range is still too wide to price. Too much is in the unknown bin. That's the cone talking. No estimation technique can fix it, because the information doesn't exist yet.

So buy the information. A short paid discovery, two to three weeks at a fixed fee, moves you along the cone. On McConnell's numbers, from half-to-double at "product defined", to roughly two-thirds to one-and-a-half once requirements are done. That's the difference between a guess and a price.

Discovery hands over five things: what we'll build in handover terms, a Definition of Done both sides sign, the unknowns turned into answers by spikes, an eval set for AI work, and a P85 estimate for the build.

Blair Enns, who advises professional services firms, puts it as: diagnose before you prescribe. Two things make it easy to sell. Credit the discovery fee against the build, so the client pays earlier, not extra. And make the output useful on its own, so they get value whether or not we build it.

4 · From estimate to contract

Let the width of the range pick the contract.

Narrow rangeWide range

Fixed price

P85 within about 25% of P50. Mostly known work.

Who carries an overrun

realfast

Fixed price with a checkpoint

Re-estimate after the first sprints. Continue, re-baseline, or exit.

Who carries an overrun

Shared, at the checkpoint

Target cost

Agree a target. Split any overrun or saving by a set ratio.

Who carries an overrun

Both, for example 50:50

Flexible scope

Fixed budget, capped time and materials. A ranked backlog.

Who carries an overrun

No overrun: scope flexes

A fixed price on a wide range isn’t a price. It’s a bet, and both sides lose it together.

Agile fixed price and checkpoint: Opelt et al., Agile Contracts (2013). Target cost: NEC4 Option C.

An estimate they can’t refuse · Sales and Tech15 / 18

Connect the estimate to the commercial model.

The gap between P50 and P85 tells you how much uncertainty is left. Let it pick the contract.

Narrow range, say P85 within about a quarter of P50: fixed price is fine. Any overrun comes out of our margin, but it's a small, priced risk. The 25 percent is a rule of thumb, not a law.

A bit wider: fixed price with a checkpoint. This comes from the book Agile Contracts. After the first few sprints, both sides re-estimate with real data, then continue, re-baseline, or exit.

Wider still: target cost, borrowed from construction. Agree a target. If it comes in over, both sides share the overrun by an agreed ratio. Under, and both share the saving.

Widest: fixed budget, flexible scope. Capped time and materials with a ranked backlog, built from the top.

A fixed price on a wide range isn't a price. It's a bet. And when it goes wrong, it goes wrong for both sides: we lose margin, the client gets a stressed team and a late delivery.

4 · From estimate to contract

You can’t estimate what nobody can list. Rewrites and takeovers need an audit first.

“With enough users, all observable behaviour will be depended on by somebody.” Hyrum’s Law

Finish the build. Rewrite it on a modern stack. Make it do what the current system does.

Estimate it in this order

01
A fixed-fee audit of the code or the old system.
02
Record what it really does, with tests against the running system.
03
A parity list both sides sign. That list is the Definition of Done.
04
Now estimate, piece by piece, from the list.

An estimate they can’t refuse · Sales and Tech16 / 18

The work that lives in the long tail. It sounds clear and isn't.

Remember the track-record table: rescues and rewrites ran far over. Here's why.

Some scope sounds very clear. "Finish the build." "Rewrite it on a modern stack." "Make it do what the current system does." Everyone nods. But none of these defines done. They point at something else and say "that". Even a vague Definition of Done is better, because it at least tries to say what done means.

Bottom-up estimation needs a list of work. For a rewrite, the users will list the screens and the main flows. That's the tip of the iceberg, and that's what gets estimated. Below the water is everything else the old system does: business rules nobody wrote down, edge cases someone fixed years ago, bugs that people now depend on, reports and nightly feeds, defaults and ordering. The old system is the only complete spec of itself. This is the feature-parity trap.

Hyrum's Law, from a Google engineer, says it well: with enough users, every observable behaviour will be depended on by somebody. Bugs included.

Taking over a half-finished build from another team has the same shape. Nobody knows what finished means, or what state the code is in.

So estimate in this order. A fixed-fee audit first. Record what the old system really does, with tests against it. Turn that into a parity list both sides sign: that's the Definition of Done. Only then estimate, piece by piece, from the list.

Before any estimate goes out

Three habits for Sales and Tech, starting with the next deal.

01

Estimate before you hear the budget.

Tech writes the number down first, alone. Then Sales brings the budget, and you compare openly.

02

Always a range and a confidence.

“14 to 18 weeks, we commit to 18, for this scope.” Never a bare number.

03

Record sold against actual.

Every project, one line in the shared sheet. In a year, it’s the best estimator we have.

An estimate they can’t refuse isn’t the lowest number. It’s the one with its reasons showing.

Range, confidence, reasons.

Close. Three habits, then the asks.

Three habits, starting with the next deal.

One. Estimate before you hear the budget. Tech writes the number down first, alone, then Sales brings the budget and you compare openly. That's the anchoring fix.

Two. Always give a range and a confidence. "Fourteen to eighteen weeks, we commit to eighteen, for this scope." Never a bare number. That's the overconfidence fix, and it makes the scope conversation possible.

Three. Record sold against actual, for every project. One line in a shared sheet. In a year, that sheet will be the best estimator we have.

To sum up. Estimates miss because of the cone and the long tail, and they miss more because of anchoring, overconfidence, forgotten work and pressure. The fix: break the work down and sort it, three-point every piece, estimate alone then compare, check your track record, and quote a range with a confidence. When the range is too wide, buy information first, and let the width of the range pick the contract.

That's the estimate they can't refuse. Not the lowest number. The one with its reasons showing.

Two asks. On your next proposal, run one Delphi round before anyone mentions the budget. And send me your last three projects, sold against actual, so we can start the sheet.

Sources

Where the ideas come from.

Cone of uncertainty. Steve McConnell, Software Estimation: Demystifying the Black Art (2006); Barry Boehm, Software Engineering Economics (1981).

IT overruns and the long tail. Bent Flyvbjerg and Alexander Budzier, “Why Your IT Project May Be Riskier Than You Think”, Harvard Business Review (2011).

Estimates, targets and commitments. Steve McConnell, Software Estimation, chapter 1.

Anchoring. Magne Jørgensen and Dag Sjøberg, “The impact of customer expectation on software development effort estimates” (2004); Løhre and Jørgensen, “Numerical anchors and their strong effects on software development effort estimates”.

Overconfidence. Steve McConnell, Software Estimation, the 90% confidence quiz.

Omitted activities. Steve McConnell, Software Estimation, chapter 4.

Planning fallacy, reference class forecasting. Daniel Kahneman and Amos Tversky; Bent Flyvbjerg.

Three-point estimates and Wideband Delphi. PERT; Barry Boehm, Software Engineering Economics (1981).

Probabilistic forecasting. Troy Magennis, Focused Objective, Monte Carlo forecasting spreadsheets.

Diagnose before you prescribe. Blair Enns, Win Without Pitching; “Phase Your Client Engagements”, 2Bobs.

Contracts. Opelt, Gloger, Pfarl and Mittermayr, Agile Contracts (Wiley, 2013); NEC4 Option C target cost.

Feature parity and Hyrum’s Law. Hyrum Wright; “The End of the Legacy Rewrite Trap”; project-rescue guides from Syndicode and Oktopeak.

An estimate they can’t refuse · Sales and Tech18 / 18