How to scope a project so the estimate holds

The estimate was never the problem

When a project runs long, the conversation usually turns to estimating skill. In most cases the estimate was reasonable for the project that was described. The problem is that the project that was delivered was never the project that was described.

Scope and estimate are the same conversation. You cannot produce a reliable number for work that has not been defined, and no amount of estimating technique compensates for a vague brief. The work of making an estimate hold happens before the estimate is written.

Write the boundary, not the title

A project called "website rebuild" or "operations review" has no estimable content. It is a label with an implied set of expectations, and those expectations differ by person.

Replace the title with a boundary statement: what is definitely included, and what is definitely excluded. Two columns, both specific enough that a reasonable person could disagree with them, because that disagreement is what you want to surface now rather than in month three.

An example of the difference: "includes migration of the product catalogue and images for the current range; excludes migration of historical orders, customer accounts, and any content older than the current site" is a boundary. It tells an estimator what to count and tells the client what is not being paid for.

Exclusions are not defensive. They are the mechanism by which scope can be added later as a decision rather than a dispute.

Define done before you count effort

For each part of the work, write the acceptance criteria: the observable condition that means this piece is finished. "Report delivered" is a label; "report delivered as a document containing the sections listed below, reviewed in a single session with the client, and revised once" is an estimate.

Acceptance criteria do three useful things at once. They bound effort, because revision is included explicitly rather than absorbed silently. They reduce rework, because the standard is agreed before the work begins. And they make progress visible, because completion is a fact rather than a claim.

Where the criteria are genuinely unclear, that is a finding, not a detail. Unclear acceptance is the most common source of scope growth, and it is worth spending an hour with the client to resolve before quoting anything.

Break the work down to things you can reason about

The right level of breakdown is the level at which you have experience to draw on. Most people can reason sensibly about a task that takes half a day to three days. Beyond that, the uncertainty compounds quickly.

Break the project into deliverables, then into the pieces needed to produce each deliverable, and stop when the pieces are small enough that you could describe how you would do them. Then estimate each piece and combine with the dependencies in mind.

Two disciplines matter here. First, account for the work that is not production: review cycles, approvals, waiting for information, meetings, rework, and the handovers between people. On many projects this coordination work is a substantial share of the total, and it is routinely omitted because it does not feel like the project. Second, keep the assumption behind each estimate visible. If a piece assumes the client supplies specifications in a usable format, write it down.

Separate the known from the unknown

A single number implies a certainty that rarely exists. Split the estimate into what you can reasonably predict and what you cannot, and treat them differently.

For well-understood work, a straightforward estimate is fine. For unfamiliar work, use a range and state what drives it: a low figure if things go as hoped, a high figure if the risky parts require more than one attempt. Where a piece is genuinely unknowable without investigation, do not guess: make the investigation its own small deliverable, and estimate the rest once its output is known.

This is more honest than a padded single number, and it gives the client a meaningful choice: proceed with the uncertain work now at a range, or fund a short discovery step first. Clients usually prefer the second, because it converts an anxious guess into information.

Treat contingency as a decision, not a secret

Adding an invisible margin to every line is a common habit and a poor one. It makes the estimate hard to read, hard to defend, and easy to erode in negotiation without anyone noticing that the margin was protecting the project.

Instead, price two things separately: the estimate for the defined work, and an explicit contingency for identified uncertainty, with the risks it covers named. State who can authorise its use and what happens if the project finishes without consuming it. Clients accept a visible contingency far more readily than an inflated base, because they can see what they are buying.

Publish the assumptions

An estimate is only valid within the conditions it assumes. Write them out, briefly:

• Decisions the client will make, and by when.
• Inputs the client will provide, and in what form.
• The number of review rounds included.
• Named people whose availability is assumed, especially on the client side.
• External dependencies such as suppliers, licences, or third parties.
• Anything assumed about existing systems, data quality, or access.

Assumptions are not a complaint in advance. They are the terms under which the number is true, and when one stops holding, that is a change to discuss rather than a failure to absorb.

Set up change control at the same time

Change is normal. Unmanaged change is what breaks estimates. Define, before the work begins, how a change is handled: who can request it, how it is assessed, who approves it, and how the effect on schedule and cost is recorded. A one-page log is enough.

The practical rule that makes this work is simple: nothing enters the project without a corresponding decision about what it replaces or what it costs. When there is no room to add, say so plainly and offer the options, a later phase, a swap, or a higher price. That conversation is far easier at the moment of the request than at the end.

Review at gates, not continuously

Break the project into a small number of stages and review at the end of each one, against three questions: is the work as described, has anything changed, and does the remaining estimate still hold? Gates give you the chance to correct scope while correction is still cheap, and they create a natural point to re-baseline if the situation has genuinely moved.

Between gates, resist re-estimating on every query. Frequent re-estimates are usually driven by anxiety and they undermine confidence in the plan.

When someone asks for a single fixed number

Sometimes you will be pressed to give one figure for everything. Do it, if you must, and do it in a way that survives: fix the scope tightly, list the assumptions and exclusions explicitly, include the contingency visibly, and make the change process part of the agreement. A fixed price with a loose scope is not a commitment, it is a delayed argument.

The reverse is also worth saying: if the client cannot define scope, a fixed price is not in their interest either. An open-ended project quoted as a fixed sum is usually quoted high to compensate for the risk, and the client pays for the uncertainty either way.

A scoping checklist

• Outcome described as a result, not an activity.
• In-scope and out-of-scope lists, both specific.
• Acceptance criteria for each deliverable, including review rounds.
• Work broken down to pieces you can reason about, with coordination effort included.
• Uncertain work isolated, with a range or a short discovery step.
• Contingency visible, with a named owner for releasing it.
• Assumptions written down and agreed.
• Change process defined before work starts.
• Review gates at natural boundaries.

None of this is slow. It is an hour or two of precision in exchange for a project that can be managed against something real, which is what most people mean when they say they want a reliable estimate.