In this essay
A programme lead presents forty minutes of progress slides. Near the end, the sponsor hears that a supplier decision could move the launch. The group requests a comparison of the alternatives. Another meeting is booked, while teams continue working against different assumptions.
The missing document was a decision paper. Its job is to make a specific choice understandable to the people authorised to make it. Status reports can support that choice, but a collection of green and amber indicators does not explain what the meeting should approve.
Consider a fictional organisation replacing its regional service-booking system. The software is ready for a controlled trial, but support training and one supplier connection remain incomplete. The programme needs a choice between a limited regional pilot and a later full rollout. The example below is a proposed working method, not a case study or a universal governance requirement.

Put the requested authority on the first page
"Discuss rollout" is too vague. A useful request identifies the action, boundary and conditions: approve a pilot in two named operating regions, within the existing trial budget, after the service owner confirms support coverage and the supplier connection passes the agreed test.
The paper should state who can approve that scope. A steering group might recommend an option while a budget holder or operating authority makes a separate decision. Record these as separate approvals. A favourable discussion does not supply authority that the attendees do not hold.
GovS 002 describes decisions that can approve, reject or give further direction, including conditions with assigned responsibility. Its requirements apply to UK government delivery. The decision record proposed here borrows that distinction without assuming every private organisation has the same approval structure. GovS 002, decision making
Use the steering escalation guide to resolve the route when authority is unclear. This paper concentrates on what the decision maker needs to compare once the route is known.
Compare options against the same question
A preferred option can look convincing when it includes only its advantages and the alternatives include every possible risk. Use the same outcome, time horizon and cost boundary for each option. Include the consequence of staying with the current arrangement.
For the booking programme, the question is whether to start a limited operational trial now or wait for broader readiness. A pilot that cannot be supported is not a credible compromise merely because it is smaller.
| Option | Customer and operating scope | Evidence still required | Consequence the group accepts |
|---|---|---|---|
| Limited regional pilot | Only eligible bookings in two regions; existing service remains available elsewhere | Support cover, supplier test and a workable return to the old process | Duplicate operating arrangements during the trial and a later expansion decision |
| Full rollout later | All planned regions move after outstanding work closes | Training completion, supplier readiness and a verified transition plan | A later benefit start and continued cost of the old service |
| Keep the current service for now | Existing process continues while the release approach is revised | Confirm remaining supplier commitments and the cost of deferral | Lost learning opportunity and an explicit review date |
The paper should include comparable cost ranges where they affect the decision. Avoid giving an exact pilot cost against an unbounded description such as "full rollout expensive." If a supplier quote is missing, say which assumption is provisional and how a change would affect the recommendation. The RAID and steering guide covers the supporting registers; the decision paper should link to their relevant entries rather than reproduce every row.
Preserve the disagreement that could change the choice
Suppose delivery prefers the pilot because it creates real operating evidence. The service owner prefers waiting because the same support team must also operate the old system. Summarise both reasons fairly. The decision maker needs to understand the constraint, not which function supplied the more persuasive slide.
Separate disagreement about facts from disagreement about preference. Whether support staff are available can be checked against a roster and other commitments. Whether the learning is worth the temporary operating burden is a judgment for the authorised owner. Resolving the first question does not automatically settle the second.
Identify the evidence that would reverse the recommendation. If the pilot depends on a successful supplier test, failure of that test should trigger reconsideration. A paper that says "recommend pilot" without exposing that dependency cannot guide the team when conditions change after the meeting.
Make deferral a visible option with a deadline
Deferring can be responsible when the evidence is insufficient. It still has consequences. Explain what expires or becomes harder if the group does not decide: supplier availability, a training slot, a customer communication or the period available for a controlled trial.
Do not manufacture urgency. Link the decision date to a real dependency. If the vendor's reservation can be extended, show that option. If no irreversible action is due, the right request may be permission to gather evidence rather than permission to launch.
Identify the authority required and the consequence of waiting.
Show which facts could change the recommendation and who can resolve them.
Assign implementation and communication owners.
A named owner verifies each condition; escalate changed conditions before proceeding.
Do not describe the recommendation as approved. Rework or return with the requested evidence.
Preserve the original options and rationale so the choice can be reconstructed later.
Proposed programme workflow. A discussion, recommendation or conditional approval does not itself satisfy an outstanding release condition.
Record the decision in words that survive the meeting
Minutes saying "pilot discussed and supported" are insufficient for a team preparing customer communications. Save the chosen option, permitted scope, authority, unresolved conditions and the person who confirms closure. Attach the evidence available at the decision date, so later updates do not rewrite what the group knew.
For the fictional pilot, the decision could require support cover and a supplier test by the agreed readiness review. If either fails, the release remains held and the owner returns with a revised option. Once both are confirmed, communicate the permitted regions, fallback and trial review date to delivery, operations and customer-facing teams.
The steering paper can then be archived with its outcome. Its value is the trace from evidence to authority to action. A colleague who missed the meeting should be able to read it and know exactly what can proceed.
Closing thought and further reading
A steering paper should make a decision possible before the meeting starts. Show the choice, the evidence and what each outcome authorises.
Need help applying this to your business?
Explore practical support for payment operations, product decisions, program delivery and AI automation, grounded in the challenges behind this essay.


