What this briefing is about and who should read it. This note explains the specific decision a board or Senior Responsible Owner (SRO) must make when a programme asks to move from discovery into procurement and funded delivery. It is for boards, SROs, chief executives, finance directors and programme leads who approve funding or contracts but are not procurement or technical specialists.
What 'procurement' means here. In this briefing, 'procurement' covers two linked activities: buying a technology system (software or platform) and commissioning the implementation services to deliver and operate it. It also covers the contracting arrangements that bind suppliers, third parties and the buyer.
The decision to make. The board must decide whether to approve the programme to proceed to market and receive funding for delivery. That approval should be conditional on a small set of verifiable artefacts that make scope contractible and acceptance testable. The choice is between approving a verifiable, testable package or approving a narrative that will almost certainly lead to variations, delay and rework.
Why discovery outputs often fail to be procurement‑ready
Discovery typically produces outcomes, service narratives and high‑level user needs. These are useful. They are not enough for contracting.
Common failure pattern. Commercial teams create lots from narratives. Suppliers turn lots into assumptions. The integration and operations teams only see the gaps at test. The result is late contract variations, price uplifts and delayed cutover.
Three predictable failure modes. (1) Untestable requirements: acceptance criteria are vague or missing, so testing becomes subjective. (2) Uncontractible data work: migration, reconciliation and tolerances are unspecified. (3) Hidden supplier coupling: critical third‑party dependencies and single‑supplier paths are discovered too late, making reversibility impractical.
The exact executive decision leaders should frame
Treat approval to tender or fund delivery as a conditional decision, not a simple yes or no.
Frame the decision like this: approve progression to market and funded delivery on receipt of a 'procurement‑ready acceptance ledger' that demonstrates three outcomes: (A) the scope is contractible; (B) the acceptance tests are executable and composable across suppliers and operations; and (C) critical data and reversibility tests are defined and can be relied on by the buyer and the market.
This reframing means the board approves a verifiable artefact set rather than a hope that suppliers will interpret a narrative correctly.
Key terms (defined on first use)
Epic: a large, coherent piece of work that delivers a user outcome. An epic is split into smaller features for development and testing.
Acceptance criteria: clear conditions that must be met for work to be accepted. Each criterion must be measurable or described as a scenario with pass/fail rules.
Acceptance test / acceptance experiment: an end‑to‑end check that shows the delivered solution meets the acceptance criteria under realistic conditions.
Service level indicator (SLI): a metric that measures performance of a service, for example 'percentage of transactions completed within 2 seconds'.
Service level objective (SLO): the target or threshold for an SLI, for example '99.5% of transactions complete within 2 seconds over a 30‑day window'.
Ledger: a structured, versioned record — here, a single authoritative register of epics, tests, evidence and dependencies.
Reversibility: the ability to extract live data and switch operation to an alternative supplier or in‑house provision within an agreed time and resource bound.
Runbook: a step‑by‑step operational guide for routine and degraded operation, and for executing acceptance tests or switching suppliers.
What 'procurement‑ready' means — essential artefacts
Procurement‑ready is intentionally compact. It must allow three parties — the buyer, a prospective supplier, and an integrator or operator — to run the same acceptance experiment and reach the same pass/fail outcome.
Essential (must have) artefacts. These are the minimum items a board should require before it approves tender, awards contract or permits transition:
1) Epics and user journeys with measurable acceptance criteria. Each epic must list: the specific acceptance tests, the operational owner, and the systems and processes that will deliver and operate the outcome. Acceptance criteria must be either a measurable SLI/SLO or a scenario with clear success thresholds.
2) A composed acceptance test suite. A map that shows how SLIs and SLOs compose across suppliers and legacy systems into end‑to‑end tests. It must identify test data needs, reconciliation rules and failure thresholds. Machine‑readable format is preferred but a clearly structured document is acceptable.
3) Data migration and extract specification. Precise definitions of records to move, canonical sources of truth, reconciliation tolerances, anonymisation rules for test data and a reversible extract that can be validated prior to cutover.
4) Dependency ledger with owners. A ranked list of internal and external dependencies, named owners, controls in place and the conditional approvals required if a dependency fails.
5) Supplier reversibility and exit tests. Contract clauses that require the supplier to demonstrate validated data extracts, schemata and the ability to handover to an alternative provider or in‑house operation within agreed resources and timescales.
6) Operational runbooks and staffing assumptions. Runbooks for normal and degraded operation, and clear confirmation of who (buyer or supplier) will provide each role during acceptance tests and at cutover.
7) Evidence ledger and acceptance pack template. A versioned template for the evidence the programme will supply: test logs, reconciliation reports, configuration versions, sign‑offs and third‑party validation results.
What is recommendable but optional (good practice)
These items reduce risk and speed acceptance but are not strictly essential for a tender to be viable:
1) A machine‑executable test harness and synthetic data sets that mimic production volumes and anonymisation constraints.
2) An independent third‑party to validate the sample migration extract and reconciliation method.
3) Pre‑qualification records that show prior reversibility exercises or demonstrated migrations on similar programmes.
4) A small, payable 'rehearsal' lot in the contract that funds a supplier to execute the rehearsal before primary payment milestones.
How the artefacts map to decision gates
Boards should require specific artefacts at three conditional gates. For each gate the board either approves progression or requires the programme to return with the missing artefacts.
Gate A — Approval to tender (conditional). Essential artefacts: epics with measurable acceptance criteria; dependency ledger with owners; data migration extract specification; staffing assumptions for acceptance tests. If there are unresolved medium‑or‑higher risks in third‑party dependencies, the board should require the programme to either exclude that scope or present a procurement approach that contains commercial or contractual remedies.
Gate B — Authority to award contract. Essential artefacts: composed acceptance test suite; supplier reversibility clauses reviewed by legal; test harness description; initial supplier runbook. Condition: the award must be conditional on a witnessed supplier rehearsal where the supplier demonstrates the reversible extract, a reconciliation run and one end‑to‑end acceptance test.
Gate C — Authority to transition to live (staged go‑live). Essential artefacts: a populated evidence ledger showing green runs against acceptance tests; completed staffing confirmations; completed supplier reversibility exercise. Condition: if rehearsals show reconciliation tolerances are unmet, transition is delayed until remediation succeeds and the evidence ledger is updated.
A realistic example: a council replaces its case management system
Context. A county council decides to replace its legacy social care case management system and to outsource hosting and integration. The board must decide whether to approve the programme to tender and to release delivery funding.
Discovery. The discovery team produces: a set of epics (new case creation, case transfer, statutory reporting); user journeys; and high‑level data maps. The programme also prepares a dependency ledger that notes a third‑party identity service and lists owners for payroll and reporting interfaces. The team writes measurable acceptance criteria for each epic — for example, 'create case: 95% of new cases accepted and visible to social workers within 30 seconds, measured over a two‑week rehearsal'. A sample production extract and schema are produced for testing.
Tender. The procurement team issues a tender pack that includes the procurement‑ready acceptance ledger: epics with acceptance criteria, the composed acceptance tests that join the new system to the identity service and legacy reporting, and the reversible extract specification. Contracts include a supplier reversibility clause and a conditional award clause requiring a rehearsal prior to mobilisation payments.
Contract award and rehearsal. The chosen supplier signs but the contract conditions payment on a witnessed rehearsal. In a sandbox environment the supplier delivers a data extract, runs the reconciliation scripts and completes the end‑to‑end test with named council staff operating the runbooks. Independent validation of the sample extract confirms the schema and reconciliation tolerance.
Implementation and transition. The project team populates the evidence ledger with test logs, reconciliation results and runbook sign‑offs. A staged cutover is scheduled. During the dress rehearsal the supplier demonstrates a reversible extract and the council practices a fallback to a contingency plan. Because the acceptance criteria were measurable and rehearsed, the board is confident the transition can proceed in stages, and the council avoids the typical late variations that arise from vague discovery outputs.
How process, people, data, systems and suppliers must be organised
A procurement‑ready ledger sits where operating model, people, process, data and technology meet. Each artefact must name a responsible individual and a test owner (buyer, supplier or third party).
Discovery must include the people plan. If discovery does not identify who will operate and test a capability, the acceptance experiment will fail. The procurement team must not be left to invent operational ownership at tender.
Data migration is both technical and operational. A migration spec proves the receiving organisation can trust data on day one. Reversibility is both contractual and technical: contracts must require the technical tests that demonstrate extractability and transferability.
Common red flags in board papers
1) Ambiguous acceptance wording: phrases such as 'meets user needs' with no measurable thresholds. Red flag: no SLIs/SLOs or reconciliation scripts in the annex.
2) Missing data provenance: migration described as 'full extract' without schema, sample records or reconciliation method. Red flag: no sample extract or tolerance described.
3) Unowned supplier dependencies: flows rely on third parties with no named owner or test. Red flag: dependency ledger entries lack mitigations or contractual remediation.
4) Operations excluded from testing: acceptance described only as 'system testing'. Red flag: runbooks and staffing confirmations absent.
When these appear, the board should make approval conditional and require the missing artefacts before funds or authority are released.
Evidence leaders must demand, not accept plans
Boards and SROs should insist on demonstrable, testable evidence rather than promises.
Practical evidence includes: an executable acceptance test mapping or an explicit test harness; a signed dependency ledger with named owners; a sample migration extract validated by an independent reviewer; and a supplier reversibility demonstration consisting of a time‑bound extract and a restore into a sandbox.
Ask the programme for a populated evidence ledger at each gate. The ledger must show test runs, reconciliation outputs, runbook validation and supplier staff declarations. If a supplier will not demonstrate a reversible extract in rehearsal, treat that as a material commercial and operational risk and require contract changes or a change of supplier for that critical path.
Approval to tender is not permission to hope. Boards should only fund procurement that can be executed and accepted — not specifications that require discovery to be rediscovered during delivery.
Antares recommended actions
These are Antares's recommended first actions for organisations turning the issues in this article into practical governance and delivery.
- Require a procurement‑ready acceptance ledger before approving tender. Essential items: epics with measurable acceptance criteria, a composed acceptance test suite, a data migration/extract specification, a dependency ledger with named owners, supplier reversibility tests and operational runbooks.
- Make approval conditional. If any medium‑or‑higher risk dependency lacks mitigation, require the programme to exclude that scope from the initial tender or to include conditional commercial remedies and acceptance rehearsals in the contract.
- Insist on a supplier rehearsal as part of contract award. The selected supplier must demonstrate a validated data extract, a complete reconciliation run and one end‑to‑end acceptance test under witness before mobilisation payments are released.
- Demand a living evidence ledger. Test results, logs, configuration versions and sign‑offs must be populated and owned before each gate; the board should receive the ledger itself, not only a high‑level narrative.
- Treat reversibility as a testable contractual obligation. Include time‑bound extract and handover tests in the contract and require proof of capability in rehearsal; where reversibility is infeasible, require explicit commercial pricing for that residual risk and a clear contingency plan.
Our insights are provided for general information only and reflect the position at the date of publication. They do not constitute legal, financial, regulatory, cybersecurity or other advice tailored to your circumstances and should not be relied upon as a substitute for appropriate professional advice.
While we take reasonable care over our content, we do not guarantee that it is complete, accurate or current. Reading our insights does not create a client relationship with Antares Consultancy. To the fullest extent permitted by law, we accept no liability for decisions made or losses arising from reliance on this content. External links are provided for convenience and do not imply endorsement.
