SOW vs Discovery Phase: Which Comes First, and Why
ยท 8 min read
A statement of work (SOW) fixes deliverables, price and acceptance for a piece of work; a discovery phase is the short, separately paid step that finds out what that work actually is. When the requirements are unclear, the order is discovery first, then the SOW for the build, written from what discovery found. Signing a fixed SOW before that usually means pricing guesses, and one side pays for them later.
This article describes common practice, not legal advice. Have a lawyer review contract wording that matters to you.
What a SOW is, and where it breaks down
A SOW describes what will be delivered under a contract: the deliverables, the dates, how each one will be accepted, and usually the price and payment terms. A template published by the Georgia Technology Authority, for example, describes it as identifying goals, dependencies, constraints, deliverables and acceptance criteria, without describing how the work will be done. It often sits under a master services agreement that holds the legal terms.
That works well when both sides know what they are buying. It breaks down when they do not:
- The deliverables are written as features nobody has examined. "User management" can mean a login page or a full roles-and-permissions system.
- Acceptance criteria are missing or vague, so "done" becomes a negotiation at the end.
- The price assumes things nobody checked: that an API exists, that data is clean, that one stakeholder speaks for all of them.
None of this is a drafting problem. The SOW is precise about things that have not been worked out yet.
What a discovery phase agreement is
A discovery phase agreement is a small contract, or a short SOW of its own, for the discovery work only. It is usually two to six weeks long and buys a defined set of outputs rather than software. It typically covers:
- Duration and team: how many weeks, which roles, how much of the client's time is needed.
- Activities: stakeholder interviews, reviewing existing material, workshops, technical investigation.
- Deliverables: for example goals and metrics, users and journeys, prioritised requirements with acceptance criteria, an architecture outline, a roadmap with an estimate range, and a list of risks and open questions.
- Fee: fixed, or time and materials with a cap.
- Ownership: the client owns the deliverables and can use them with another vendor.
- Exit: what happens if discovery shows the project should be smaller, different, or not happen at all.
The point of the agreement is that its own scope is clear even when the product's scope is not. If you need a reminder of what the work itself involves, see what a discovery phase is in software development.
Why a fixed SOW before discovery goes wrong
Estimates made before the requirements exist are wide by nature. In Steve McConnell's Cone of Uncertainty, an estimate made at the initial concept stage can be off by up to 4x in either direction, and the range narrows as requirements and design are completed (Construx). A fixed price signed at that point has to absorb that uncertainty somewhere.
In practice it goes one of three ways:
| What the vendor does | What happens next |
|---|---|
| Prices low to win the work | Change requests pile up, or the vendor cuts corners to stay in budget |
| Prices high to cover the unknowns | The client overpays for risk that may never materialise, or chooses someone cheaper |
| Prices fairly but scopes vaguely | Both sides argue about what was included when the build is half done |
A discovery phase does not remove uncertainty, but it moves the expensive questions to a point where they are cheap to answer: before anyone has written code.
The sequence: discovery, SOW, build
The simplest working sequence has three steps.
- Sign a discovery agreement. Short, with a clear fee and clear deliverables. The client commits a small, known amount.
- Write the build SOW from the discovery results. The deliverables come from the agreed requirements, the acceptance criteria from the requirements' own criteria, the price from the estimate range and its assumptions, and the exclusions from the "out of scope" list.
- Build, with a change process. New ideas go through a written change request with its effect on cost and dates, instead of quietly growing the work.
Discovery also gives both sides a natural decision point. After step 1 the client can go ahead, shrink the first release, run a smaller pilot, take the results to another vendor, or stop. A good discovery agreement says this openly.
The risks found in discovery should travel into the SOW too, either as assumptions or as named exclusions. This is what a risk list looks like in the public example report, for an invented project called Fieldwise: a blocker on another team's API, a mitigation for a user trust risk, and open questions with no owner yet.
Each of those lines changes how the build SOW should be written. The API blocker becomes an assumption with a date; the signature question must be answered before the acceptance criteria for closing a visit can be final.
What goes in each document
| Discovery agreement | Build SOW | |
|---|---|---|
| Purpose | Find out what to build and what it will cost | Deliver the agreed software |
| Length of work | Usually weeks | Usually months |
| Deliverables | Documents and decisions: goals, requirements, architecture outline, roadmap, risks | Working software, by milestone |
| Acceptance | Deliverables reviewed and accepted by the client | Requirements' acceptance criteria pass |
| Price | Fixed fee or capped time and materials | Fixed per milestone, or time and materials, based on the discovery estimate range |
| Assumptions | Access to people, material and systems | The assumptions listed in the discovery estimate |
| Out of scope | Building software | The "out" and "later" lists from discovery |
| Change handling | Rarely needed; extend or stop | Written change requests with cost and date impact |
Two details are worth getting right. First, reference the discovery output in the build SOW by version and date, so everyone knows which requirements were priced. Second, copy the assumptions over word for word; they are what makes the price fair when one of them turns out to be wrong.
How to sell discovery to a client who wants a quote
Clients ask for a fixed quote because they need a number for their budget, not because they enjoy fixed-price contracts. Give them a number they can use, and explain what it buys.
- Give a wide range now, and say why it is wide. "Based on what we know, this is somewhere between X and 3X. Discovery is how we narrow that." The Cone of Uncertainty is a useful, neutral picture to show.
- Price discovery as a small, fixed amount. The decision is easier when the first commitment is limited and its outputs are listed.
- Make the output portable. If the client owns the discovery results and can take them to another vendor, the offer reads as advice, not as a sales funnel.
- Show an example of what they will get. A real-looking set of deliverables answers "what am I paying for?" better than a list of activities. The discovery phase template lists the usual sections, and the example report shows a complete one for the invented Fieldwise project.
- Offer to credit part of the fee against the build, if your margins allow it. It lowers the barrier without making discovery free.
- Name the decision at the end. Go ahead, shrink, pilot or stop; the client should know they keep that choice.
If you run discovery for several clients at once, keeping each one's material and output in one place helps. Discovery Phase AI, for example, can draft the discovery stages from a client's existing decks, documents and call transcripts, and exports the result as a report in PDF, Word, PowerPoint or Markdown; the SOW itself is still yours to write.