A technology scoping report is the document that converts "we should probably do something about this" into work a team can start on Monday and a number a sponsor can approve. It sits between the vague intent and the technical design, and it exists to make a decision possible.
That is the test. If a sponsor cannot approve or reject something after reading it, the report has failed, however good the analysis inside it is.
Who is a scoping report for?
The approver, not the implementer. This distinction determines everything about how the document is written, and getting it wrong is the most common failure.
| Scoping report | Technical design document | |
|---|---|---|
| Reader | The person funding or approving | The people building |
| Question it answers | Should we do this, which way, and what will it cost? | How exactly do we build the thing we decided on? |
| Options presented | At least three, including do-nothing | One — the chosen approach |
| Level of detail | Enough to size and compare | Enough to implement |
| Written when | Before the decision | After it |
Merging the two produces a document that is too technical to approve and too vague to implement — a familiar artefact that circulates for three weeks and moves nothing.
What belongs in it?
1. Problem statement
What is wrong today, stated in terms of consequence rather than technology. "Order reconciliation takes two people three days a month and produced eleven customer-visible errors last quarter" is a problem statement. "We need to migrate off the legacy reconciliation service" is a proposed solution wearing a problem's clothes, and it forecloses the options analysis before it begins.
2. Current-state assessment
What exists now: the systems involved, how they connect, where the manual steps are, what breaks. Include the things that work — a scoping report that only lists faults invites the suspicion that the author arrived with a conclusion.
This section is where the honest constraints surface. The integration nobody documented, the batch job that must run before 6am, the team of two who are the only people who understand the pricing logic. These constraints will shape the answer more than any technical preference, and they belong in writing early.
3. Requirements, split three ways
- Must — the work fails without it.
- Should — significant value, tradeable against cost.
- Could — desirable, first to be cut.
The split matters because it is what makes phasing possible later. A flat requirements list cannot be sequenced; a split one sequences itself.
4. Options analysis
At least three options, always including do nothing. Each one gets the same treatment: a description, an effort estimate as a range, the consequence of choosing it, and what it forecloses.
Do-nothing is not a throwaway. Costing the status quo — the three days a month, the eleven errors — is frequently the section that actually persuades. Without it, the report asks a sponsor to spend money against an unstated baseline of zero, which is never the real baseline.
Options should be genuinely different, not three variants of the same approach at different sizes. Buy, build and hybrid; or replace, wrap and incrementally migrate. If all three options share the same fundamental bet, you have presented one option with a price slider.
5. Recommendation
Name one. A scoping report that presents three balanced options and declines to choose has passed the hard part back to someone with less information.
State the recommendation, the single fact that most drove it, and — critically — what would change it. That last clause is what separates a recommendation from an opinion.
6. Risks and unknowns
Split what you know from what you assume from what you must discover.
- Known — verified facts about the current system.
- Assumed — believed but unverified. Each assumption gets a line saying what happens to the plan if it is false.
- Unknown — must be discovered before the estimate can tighten. This is where schedule risk lives, and naming it is the most valuable thing the report does.
An estimate's reliability is set by the size of the unknown column, not by the care taken over the known one. A report that hides its unknowns produces a precise number that will be wrong on a schedule nobody planned for.
7. Phased plan
Break the work into phases with a deliverable and an exit criterion each. The sequencing rule that matters: the first phase should retire the largest unknown, not deliver the easiest visible win.
It is tempting to front-load something demonstrable to build confidence. The cost is that you discover the hard problem in month four, with the budget spent and the schedule public. Retiring the biggest unknown first means the bad news, if there is any, arrives while the decision is still cheap to reverse.
8. Cost and resourcing
Present ranges, not points, with the width reflecting the unknowns you just named. Include the people, not only the money — "two backend engineers for eight weeks plus 20% of a data engineer" is more actionable than a currency figure, because capacity is usually the binding constraint.
How precise should scoping estimates be?
Precise enough to decide with, and honest about their range. A scoping estimate claiming precision it cannot have destroys credibility the first time reality diverges — and reality always diverges when the unknown column is non-empty.
A workable convention: express estimates as a band whose width encodes confidence, and say what would narrow it.
- ±20% — the approach is proven here and the unknowns are small.
- ±50% — the approach is sound but one or two significant unknowns remain.
- 2–3× range — genuine novelty. Recommend a time-boxed discovery phase to convert unknowns into knowns before committing to the rest.
That last case is a legitimate and often correct output of scoping. "We cannot responsibly estimate this until we have spent two weeks proving the integration works" is a real recommendation, and sponsors accept it far more readily than teams expect — considerably more readily than they accept a confident number that later triples.
What to leave out
- Implementation detail. Class designs and schema drafts belong in the design document. In a scoping report they signal that the author has already stopped considering the alternatives.
- Technology advocacy. If a specific framework genuinely matters to the decision, it is a requirement or an option, and it should be argued as one.
- Anything you cannot defend. One unsupported claim in a scoping report undermines the estimate it sits next to.
The one-page version
Whatever the full report's length, it should open with a page that stands alone: the problem in two sentences, the three options as a table with costs, the recommendation, the largest risk, and the ask. Many approvals happen on that page and the rest of the document exists to survive the questions it provokes.
Write that page last, once you know what the report concluded — and write it as though it is the only page anyone will read, because for the person signing, it frequently is.
Scoping usually surfaces a build-versus-buy question and a cost question. Both deserve their own treatment: see the build-vs-buy framework and, where the work involves model inference, costing an AI feature before you build it.
Frequently asked questions
What is the difference between a scoping report and a technical design document?
A scoping report is written for the person approving the work; a design document is written for the people doing it. The scoping report establishes what problem is being solved, which options exist, what each costs, and what could go wrong — and it stops there. The design document assumes that decision is made and specifies how the chosen option is built. Merging the two produces a document that is too technical to approve and too vague to implement.
How detailed should cost estimates be at the scoping stage?
Detailed enough to be decision-useful and honest about their range — typically a band rather than a point, with the width of the band reflecting how many unknowns remain. A scoping estimate that claims precision it cannot have destroys credibility the moment reality diverges; one presented as a range, with the assumptions that would move it named explicitly, survives contact with delivery.