The supplier demonstrations have gone well. The preferred proposal is detailed, the budget has been approved and delivery dates are appearing in calendars. Procurement feels almost finished.
Yet one of the most important decisions may still be unresolved: what, exactly, must be true for the organisation to accept the new service as ready?
Attention shifts to mobilisation: contracts, dates, governance and workshops. The proposal becomes the working definition of the project.
This is often where ownership quietly changes hands. Nobody decides to give control away; the supplier simply holds the clearest description of the work, so its interpretation begins to govern the project.
A proposal can reduce uncertainty about how a supplier intends to deliver while leaving uncertainty about what the organisation actually needs almost untouched. Detail about the first can conceal the absence of the second.
A proposal sets out the supplier’s interpretation and commercial offer: the work, approach and price. A requirement belongs to the organisation. It defines the operating outcome, constraints, responsibilities and evidence needed for business sign-off.
Requirements define success.
A proposal describes one supplier’s route to it.
In a project review, asking for the approved requirements often produces the supplier proposal. That substitution says more about control of the project than the status report does.
Start with the outcome, not the proposal
“Replace the CRM” is not an operating outcome. Neither is “launch a modern member portal”. Those phrases name a category of solution.
A useful requirement explains what must become possible in the organisation. In a renewal service, members must be able to renew and pay in one coherent journey, staff must handle exceptions without creating duplicate records, finance must reconcile each payment to the correct invoice and ledger entry and support must see where a failed transaction stopped.
Those outcomes can then be translated into requirements, supplier deliverables and evidence of readiness. The chain also makes ownership clear:
Traceability does not require a large requirements database. A concise table can be enough for the most important outcomes:
| Business outcome | Requirement | Supplier deliverable | Evidence of readiness |
|---|---|---|---|
| Members renew and pay online | Renewal preserves member status and creates a reconcilable payment | Configured renewal journey and payment integration | End-to-end tests cover successful, failed and duplicate payments; finance signs off reconciliation |
| Staff manage renewal exceptions | Authorised staff can correct common exceptions with an audit trail | Exception screens, roles and workflow | Operational users complete agreed scenarios using realistic permissions and data |
| Support resolves failures | Staff can identify the transaction state and the responsible system | Error handling, monitoring and support procedure | Support exercise proves that an incident can be detected, diagnosed and escalated |
The table exposes deliverables without outcomes and outcomes without evidence. Use it before signature. Rebuilding traceability during recovery usually reveals a chain of unowned assumptions, by which point options are fewer and change costs more.
Detail can conceal uncertainty
Product descriptions can be specific while boundaries remain vague. A timeline can name every workshop but omit client decisions. A responsibility matrix can list roles without proving the organisation has the authority and capacity to perform them.
By the time we are asked to review a struggling project, the missing requirement rarely looks like a blank page. It appears as two or three reasonable but incompatible interpretations of a phrase everyone thought was clear.
Four progressively stronger statements illustrate the difference:
- The supplier says that payment integration is included.
- The supplier demonstrates a payment in its standard product.
- A payment successfully passes through the configured components.
- The organisation has evidence that real renewal scenarios create the correct membership, payment and finance records, including failure and recovery paths.
Only the fourth supports an operating decision. The others show progress, not readiness.
Detail creates confidence.
Evidence creates certainty.
Look for the omissions that become expensive later
The most expensive gaps usually sit inside a phrase that each party has interpreted differently. In recovery work, “included” is often where the argument starts because it says nothing about limits, responsibilities or proof.
Before approving the work, make sure the proposal and the underlying requirement deal explicitly with:
- Data migration: what will move, how quality and totals will be assured and who will sign off.
- Integrations: which interfaces are included, who owns each side, how failures will be detected and who will support them after launch.
- Business rules: grades, eligibility, pricing, approvals, exceptions and historical cases that do not fit the standard demonstration.
- Testing: which journeys and failure paths must work, what realistic conditions are needed and who judges the results.
- Client capacity: the decisions, subject experts, content preparation, testing and approvals the client must provide, and whether those people have time when needed.
- Operational readiness: support, monitoring, training, handover, communications, finance procedures and supplier escalation.
- Non-functional needs: security, accessibility, performance, resilience, audit and retention.
- Business sign-off: what will allow the authorised owner to declare the outcome ready, not merely the activity finished.
These are operating conditions, not technical extras.
Some uncertainty is appropriate. The problem is what nobody has identified, owned or planned to resolve. Discovery is valid if it names the unknowns, decision owner and commercial consequence. An assumption is neither an agreed exclusion nor a confirmed requirement.
The Outcome Traceability Review
The Outcome Traceability Review tests the chain with four questions.
1. What must become possible?
Describe the outcome without naming a preferred product. If the discussion begins and ends with a platform, comparing alternatives or challenging costly features becomes harder.
In procurement meetings, asking for the outcome without the product name can be the point at which different sponsors realise they have been buying towards different versions of success.
A demonstration shows what a product can do under chosen conditions. The requirement establishes what the service must do under the organisation’s conditions. During selection, the Supplier Evaluation Record keeps that distinction visible for every material claim.
2. What is inside, outside or still unknown?
Classify each material item as confirmed, assumed, excluded or unresolved. If two proposals rely on different boundaries, client contributions or definitions of completion, their prices are not directly comparable.
Proposals that appear far apart in price can move closer together once exclusions, client effort and unresolved integrations are placed on the same page.
3. Who must decide and operate the change?
Affected departments must recognise their responsibilities. Finance should see its controls, membership teams their business rules and support teams their procedures after launch.
Operational teams recognise their hidden project work when responsibilities are described as decisions and rehearsals rather than as occasional “input”.
If the requirement belongs only to the technology team or the supplier, operational gaps will remain hidden until testing or launch.
4. What evidence will support sign-off?
Trace every essential deliverable backwards to an outcome and forwards to evidence of readiness. “Delivered in accordance with the specification” is inadequate if the specification omits the complete journey or proof required.
Acceptance criteria written late tend to describe the evidence the project can readily produce, not the evidence the business originally needed.
Completion is a supplier status. Acceptance is a client decision, supported by evidence.
Welcome supplier expertise without giving away ownership
Good suppliers help refine requirements by identifying simpler processes, missed constraints or the need for discovery. That expertise is valuable. It does not transfer ownership of the problem.
Every supplier sees the project through its platform and commercial assumptions. The client must decide whether that perspective fits its organisation and long-term interests.
With several suppliers, a CRM proposal may assume the website agency will change an integration while the agency believes the CRM supplier owns it. Both appear complete until the organisation assigns end-to-end responsibility.
Most organisations do not hand ownership to a supplier through one explicit decision.
It slips away gradually as unanswered client questions become supplier assumptions so that delivery can keep moving.
When the client cannot maintain this ownership, a project can become supplier-led even when the supplier is competent and acting in good faith.
A practical action before approving the proposal
Run a 60-minute traceability review of three to five critical outcomes with the sponsor, operational owners, commercial or finance lead and technology owner. Complete one table row for each outcome.
In these sessions, the first disputed cell can be more useful than a page of completed rows because it identifies where two reasonable accounts of the project have diverged.
Classify every blank or disputed cell as confirmed, assumed, excluded or unresolved. Assign an owner and decide whether to settle it before signature or through bounded discovery.
If the chain from outcome to business sign-off cannot be explained for the most important journeys, the proposal is not yet a safe basis for commitment. Resolve the gaps that could materially change the price, responsibility or likelihood of an operable result.
A proposal should make the supplier’s route credible.
A requirement should make the outcome testable.
A well-controlled project needs both. It never mistakes one for the other.