Project estimation accuracy from past projects

Most teams quote the next project the way they quoted the last one: someone who knows the work breaks it into parts, puts hours against each part, adds them up, and the number feels right. It felt right last time too, and last time ran 40% over. The record of what actually happened is sitting in the timesheets, and almost nobody reads it before the next quote goes out. This post is about reading it: how to turn finished projects into a single estimation accuracy figure, what that figure says about the next quote, and how to correct for it without padding everything blindly.

Why teams under-estimate the same way every time

The optimistic estimate is not a personal failing. The largest published study of estimate-versus-actual we know of, by Flyvbjerg, Holm and Buhl in the Journal of the American Planning Association (2002), looked at 258 transport infrastructure projects and found costs under-estimated in almost nine out of ten of them, with actual costs on average 28% above the estimate. Their later finding is the uncomfortable one: the error had not shrunk in the seventy years their data covered. Better models and more data did not help, which is why the authors reject "bad data" as the explanation. Errors that come from noise average out to zero; these errors all point one way.

Two explanations survive their data, and both apply to a software house or a consultancy as much as to a railway. The first is optimism bias, what Kahneman and Lovallo call the planning fallacy: when you estimate from the inside, by listing the tasks and imagining each going to plan, you leave out everything you did not think of, and the things you did not think of are never free. The second is strategic misrepresentation: the low quote wins the work, so the estimate that reaches the client has already been shaved by someone who wanted the deal. The two feed each other. A fixed-price quote is an estimate that was leaned on by an optimist and then by a salesperson.

Those papers measure roads and railways, not sprints. Flyvbjerg notes that comparative research finds the same pattern in IT systems and new-product development, but he gives no software figure and neither will we. What matters for your team is not the industry average; it is your own ratio, and that you can measure.

Measuring estimation accuracy from finished projects

The metric is simple once the inputs exist: actual effort divided by estimated effort. A ratio of 1.0 (100%) means the estimate was right; 1.4 means the work took 40% more hours than quoted. Schedule gets the same treatment, as the number of days delivered after the due date, and the share of milestones delivered on or before it. To compute any of this you need three things recorded at the time, not reconstructed later:

1. An estimate written down before the work started, against a unit small enough to finish: a milestone, a sprint, a retainer month. A project-level total is too coarse to learn from, because one bad milestone hides inside four good ones.
2. Hours logged against that same unit as the work happens. If the team logs time weekly from memory, the "actual" is itself an estimate, and you are comparing two guesses.
3. A due date and a delivered date, so schedule accuracy can be read separately from effort accuracy. They fail independently: a milestone can land on time at twice the hours because two people were thrown at it.

With those in place, the last ten projects give you one overall ratio and, more usefully, the slices underneath it. Three slices are worth keeping: per milestone, so the worst overruns can be named and discussed; per project type, because a fixed-price build for a new client, a retainer month and an internal tool do not miss in the same way; and per person, because estimation is a skill and the ratio shows who has it. The per-person view is the one most likely to be misused, so set the rule before you look: it is for calibration, not blame. Someone whose estimates run at 130% is not a worse engineer than someone at 100%; they are a worse estimator, and the fix is a multiplier, not a conversation about effort.

The table is made up to show the shape, not a dataset. Even so, the shape is typical: the client-facing fixed-price work runs furthest over, the retainer months hover near the allowance because the allowance caps them, and internal work is estimated honestly because nobody is trying to win it. Average those five together and you get 117%, a number that is true of nothing. Averaged by type, you get three numbers you can act on.

What the ratio tells you about the next quote

Here the research hands you a method rather than a number. Flyvbjerg's 2006 paper in the Project Management Journal describes reference class forecasting, the technique built on Kahneman and Tversky's work: instead of estimating the new project from its parts, you place it in the distribution of outcomes from similar finished projects. Three steps: pick a reference class of past projects that are genuinely comparable, work out the spread of their outcomes, then position the new project inside that spread. Your per-type ratios from the previous section are exactly that reference class, built from your own history rather than an industry table.

The ratio converts directly into an uplift on the bottom-up estimate. If fixed-price client builds have landed at 135% of estimate on average, the honest quote for the next one is the bottom-up figure times 1.35, and that is before you decide how much risk you want to carry. Flyvbjerg's worked example for the UK Department for Transport makes the second decision explicit: for roads, a 15% uplift gave a 50% chance of staying within budget, and a 32% uplift gave an 80% chance. The figures are for roads and will not be yours, but the logic transfers. The median uplift is right for a portfolio where one overrun is paid for by another underrun; a stand-alone fixed-price contract with no room to absorb an overrun wants the 80% level. The paper adds a line worth pinning above the quoting desk: a team is justified in using a lower uplift only if it has evidence that it estimates better than the people whose projects make up the reference class.

How to correct

• Keep two numbers: the estimate and the quote. The bottom-up estimate is recorded first, untouched. The commercial adjustment, if there is one, is a separate line. Then the accuracy figure measures the estimators, not the negotiation, and the strategic shaving becomes visible as its own number.
• Apply the uplift by project type, not globally. One buffer across everything over-prices the internal work and still under-prices the client build. Three reference classes is usually enough to start: fixed-price for a new client, fixed-price for an existing one, and retainer.
• Re-estimate at every milestone. The estimate made on day one is the least informed one the project will ever have. When a milestone closes, compare its ratio with the project's assumed one, and if it is running at 140%, re-forecast the remaining milestones at 140% and tell the client now. We cover the retainer version of this, catching the overrun mid-period rather than on the invoice, in agency retainer burn: see it before the invoice.
• Calibrate people, do not rank them. Give each estimator their own ratio and let them apply their own multiplier. Someone at 125% who starts quoting at 125% is now accurate.
• Add a milestone when scope changes; never edit the estimate. A revised estimate that absorbs the extra scope destroys the record. The original milestone keeps its ratio, and the addition is estimated and measured on its own.

How Trackline shows it

Everything above needs the estimate, the hours and the dates in one place. In Orbiz that place is Trackline, the delivery and profitability tool. A project is modelled the way it was sold: internal, fixed-price with milestones, or a retainer with monthly periods. A fixed-price project carries estimated hours, and every milestone, sprint or period carries its own estimate, due date and owner. When you create a milestone Trackline suggests the estimate from the dates and the team, working days times eight times the combined allocation, which you can accept or overwrite. It counts weekends but not public holidays, so the suggestion runs a little high in a month with a holiday.

Hours arrive from AMS, where people clock in and log time against a project, a milestone and optionally a Cadence task; they can also be entered by hand. Link a Cadence board to the project and its sprints appear as milestones marked as mirrored from Cadence, with the board's tickets and bugs rolling up alongside. Each milestone then shows two healths. Effort health is actual over estimate: within estimate under 85%, near estimate between 85% and 105%, over estimate past 105%. Schedule health reads the dates: on schedule, due within seven days, overdue by N days, and once delivered, on time or late by N days. A retainer project is marked ongoing at project level rather than measured against a total, but each monthly period inherits the retainer's hours per month as its estimate, and the retainer statement lists allocated against logged hours with the variance per month.

The Insights page is where the finished projects add up. Its estimation accuracy tile is actual divided by estimate across completed milestones, with 100% as perfect; it turns amber above 110% and red above 130%. Next to it sit the on-time delivery rate and the average slip, delivered minus due across late milestones. Below are two tables: the worst estimate overruns, each milestone with its estimated hours, actual hours and ratio, and estimation accuracy by owner, the number of milestones each person owned, their average ratio and their on-time rate. That is the per-milestone and per-person slice from earlier, maintained for you.

Cost follows the same hours. Trackline multiplies logged hours by the hourly rate on each person's pay profile at the moment you look, so a rate change is reflected everywhere at once and nothing is copied. A milestone shows estimated cost against actual cost, and the project its cost per month. Rates and money columns are visible only to members with the financials permission; everyone else sees hours.

Who this suits

The method pays off for anyone who quotes effort in advance and is held to it: software houses selling fixed-price builds, consultancies mixing fixed-fee phases with retainers, and product teams whose "estimate" is a sprint commitment. It pays off least for a team doing purely time-and-materials work with no commitment to a number, where accuracy is a planning concern rather than a margin one. It also needs a minimum of history. One or two finished projects do not make a reference class; Flyvbjerg's point is that the class has to be broad enough to mean something. Ten is a reasonable place to start taking the ratio seriously, and the title of this post is not an accident.

A checklist for the next quote

1. Pull the last ten finished projects and compute actual over estimate per milestone. Discard any milestone whose estimate was edited after the work started.
2. Group by project type and average within each group. Note the spread, not just the mean; a type that swings from 80% to 200% needs a bigger buffer than its average suggests.
3. Record the bottom-up estimate for the new project before anyone discusses price.
4. Multiply by the ratio for its type. Decide, with the client-facing lead, whether you are pricing at the median or at the level that keeps you within budget four times out of five.
5. Give every estimator their own ratio from the per-owner table and let them calibrate.
6. Put a re-forecast on the calendar for each milestone close, and agree in advance what you will tell the client if the ratio comes in above the assumption.