Agree what readiness means before release week

Define the release boundary and the evidence required to support it while there is still time to act on gaps. Include the user journeys being introduced, the dependencies involved and the responsibilities that begin once customers use the change.

Different releases need different levels of review. A contained content change and a new customer account flow do not create the same exposure. Scale the readiness discussion to the potential consequences, including operational complexity and the difficulty of recovery.

Clarify who can authorise the release, who supplies readiness evidence and who can pause deployment when the agreed conditions are not met. Confirm this authority rather than relying on assumptions about who usually attends the meeting.

Review evidence against the release boundary

Connect verification to the behaviour the release promises. A list of completed tests is easier to interpret when it identifies the critical journeys, the environment used and any limitations that affect confidence.

Bring known issues into the same discussion. Describe the affected users, the available workaround and the reason an issue is considered acceptable or release-blocking. A defect count alone does not describe customer impact.

Confirm the status of external dependencies as well. Access, configuration, supplier readiness and business approvals can determine whether an implementation that works in testing can operate as intended after deployment.

Make operational ownership explicit

Identify who will observe the release, interpret unexpected behaviour and coordinate the response. Support teams need a clear description of the change, known limitations and the route for raising issues. Engineering needs access to the information required to investigate them.

  • Observation: which signals will the team review?
  • Response: who assesses an issue and coordinates action?
  • Communication: who informs affected stakeholders?
  • Coverage: when are the necessary people available?
  • Handover: when does ownership move into normal operation?

Validate these arrangements with the people expected to carry them out. A name in a checklist is only useful when that person understands and accepts the responsibility.

Test the recovery assumptions

Describe the response if the release does not behave as expected. Depending on the change, that may involve stopping a rollout, disabling a capability, restoring a previous version or applying a forward correction. Establish which options are actually supported.

Recovery can become more complicated when a change alters stored data or depends on an external action that cannot simply be reversed. Ask the responsible engineers to explain those limits and the conditions under which each response is appropriate.

Illustrative readiness question

“If the new order flow creates records in a changed format, can the previous application version still read them? If it cannot, what response has been prepared, and who has authority to initiate it?”

Record the answer with the deployment plan. The go-live meeting should review the agreed recovery approach and unresolved limits, with enough time to address a material gap.

Record the decision and the review point

A concise release decision should capture the approved scope, the evidence reviewed, the remaining risks and the accountable owner. Record any conditions that must be satisfied before deployment and identify who verifies them.

Set a post-release review point to assess actual behaviour and close outstanding responsibilities. Examine user impact, operational issues and whether the release achieved the intended outcome. Feed relevant findings into the next readiness review.

Good governance makes responsibilities and accepted exposure understandable to the people carrying the release. It also gives leadership a clear basis for proceeding, narrowing the scope or changing the timing. The stakeholder alignment article explains how to structure that choice.