What a go-live
recommendation should actually contain.

The go/no-go meeting is the moment all the delivery effort is judged. Yet the evidence presented is often thin: a traffic light, a pass rate and a count of open defects by severity. Leaders are asked to approve a release that will affect customers, staff or patients on the strength of a single colour.

When things go wrong after go-live, the post-incident review nearly always finds that someone knew about the risk. It simply never reached the decision-makers in a form they could weigh. A good go-live recommendation exists to prevent exactly that.

Who the recommendation is for

A go-live recommendation serves the person or forum with authority to approve the release: the authorised delegate, steering committee or programme board. Its job is to give them an honest, complete and understandable picture of readiness, so they can decide whether to proceed, proceed with conditions or delay.

It is not a vehicle for the delivery team to declare victory, nor for the testing team to protect itself. It should be written for decision-makers, in business terms, with the technical detail available but not in the way.

Different audiences may need different views of the same recommendation. A steering committee may need a single page, while operational managers need the detail of workarounds and support arrangements. The underlying evidence should be the same for both, so that the summary and the detail never tell different stories.

The essential elements

A recommendation that supports a real decision covers a consistent set of elements:

• Scope and coverage: what was in scope, what was tested and how coverage relates to the business risks identified at the start.
• Business acceptance status: which critical processes have been accepted by their business owners, on what evidence, and which remain outstanding.
• Open defects with business impact: not just counts by severity, but what each significant open defect means for users and operations.
• Residual risks: the risks that remain after testing, their likelihood and impact, and the named owner who accepts each one.
• Conditions: anything that must be true before or immediately after release, such as a data correction, a manual workaround or additional support staff.
• Contingency and rollback: what happens if the release fails, how quickly it can be reversed and who decides.
• The recommendation itself: proceed, proceed with conditions or do not proceed, with the reasoning stated plainly.

Post-incident reviews usually find that someone knew about the risk. It simply never reached decision-makers in a form they could weigh.

Coverage that relates to risk

Coverage figures are only meaningful if they relate to what matters. “Ninety-five per cent of test cases executed” says little on its own. “All twelve critical business processes tested end to end; two high-risk integrations tested only with simulated partner systems” tells decision-makers exactly where confidence is strong and where it is limited.

This is why risk-based test strategies make recommendations easier. When coverage was designed around business risk from the start, the recommendation can report against those same risks at the end.

Limitations should be stated as clearly as achievements. If a partner system was unavailable, if a data migration was rehearsed only once or if performance was tested in a smaller environment, the recommendation should say so and explain what that means for confidence. Decision-makers can accept limitations they understand. They cannot accept ones they were never told about.

Defects in business language

Defect counts by severity are useful to delivery teams but hard for executives to weigh. A single “medium” defect in a payment calculation may matter more than ten “high” defects in an internal admin screen. Separating technical severity from business priority, and describing significant defects in terms of their effect on customers and operations, gives decision-makers what they actually need.

Workarounds should be described too, including who will perform them, for how long and at what cost. A workaround that relies on a small team manually correcting records every night is a real operational commitment, not a footnote.

Residual risk with names attached

Every release carries residual risk. The question is whether it is visible and owned. A good recommendation lists each significant residual risk, rates its likelihood and impact, notes any mitigation and names the business owner who accepts it. Named ownership changes the conversation, because risks that nobody is willing to own are a strong signal that the release is not ready.

Keep the decision where it belongs

Testers and assurance teams should provide the evidence and make a clear recommendation. They should not make the decision. The authorised delegate owns the release decision because they own its consequences. PinnacleQM’s approach, used on government and enterprise programmes, is to give an independent, evidence-based recommendation while keeping the final decision with the client’s delegate, and to record that decision along with the conditions attached to it.

After the decision

The recommendation does not end at go-live. Conditions need to be tracked until they are met, early-life support should monitor the risks that were accepted, and any issue that does emerge should be compared with what the recommendation predicted. That comparison is how organisations improve their next release decision.

A good go-live recommendation will not guarantee a smooth release. It will ensure that nobody is surprised by what they were entitled to know.

Organisations that do this well keep a simple record of each release decision: the recommendation, the risks accepted, the conditions set and what actually happened. Over several releases, that record shows whether recommendations are reliable, where risks tend to be underestimated and which parts of the release process need strengthening.