Go/no-go decision process: launch readiness decision tree

What the go/no-go decision process: launch readiness decision tree process is

A go/no-go decision is not a stage in a workflow, it is a judgement. By the time a release reaches the readiness gate the work is done; what remains is to test the evidence against criteria agreed in advance and to say, out loud and on the record, which of its named outcomes applies. Most teams have the questions somewhere (in a checklist, a runbook, a recurring meeting invitation) but they are rarely written as a tree, so nobody can see which answer leads where, which question is a hard stop and which merely attaches a condition, or who is actually entitled to answer each one.

This page is deliberately a decision tree rather than a process map. A process map answers "what happens next, and who does it": tasks in sequence, handoffs between teams, one main path with exceptions hanging off it. A decision tree answers "which option do we choose, and who decides": a spine of questions, each answerable from evidence, with branches labelled by the answer rather than by the next task, terminating in distinct named outcomes. If you want the end-to-end flow around this gate (scope freeze, build and test, staging and UAT, deployment, smoke tests and monitoring) use the Software release process flowchart at /templates/software-release-process. This page is the zoomed-in view of the single decision that sits inside it.

The tree below runs twelve questions across four assessment stages, with the swimlanes naming who answers rather than mapping departments: Release manager, Engineering and QA, Operations and support, and Executive sponsor. It ends in six distinct outcomes (go, go with named conditions, a limited go to a pilot group, no-go because the acceptance criteria were not met, no-go with a re-scheduled date, and abort) because a review that can only say yes or no forces every partial readiness into one of two wrong answers. The two no-go exits are deliberately separate: failing the first gate on unmet criteria is a different finding from clearing quality and losing the change window.

What this flowchart covers

In this template

• Four decision-rights lanes rather than a department map: Release manager, Engineering and QA, Operations and support, and Executive sponsor, laid out over four stages: Evidence review, Quality gate, Operational gate, and Decision and outcome.
• The acceptance criteria branch: "Acceptance criteria all met?" answers Met or Gaps, and Gaps routes to "Are the gaps waivable?", where Waivable logs the waiver and its owner before rejoining the quality gate and Blocking ends the review at its own exit, 'No-go: acceptance criteria not met'.
• The defect threshold branch: "Defects within severity thresholds?" answers Within or Above, with Above routed to "Fix or waiver agreed?" so an over-threshold release only proceeds on a recorded agreement, not on optimism.
• Two readiness questions that can survive a partial answer: "Dependencies and vendors ready?" falls through to "Can we ship without them?", and "Rollback tested successfully?" falls through to "Is the change reversible at all?", where a No is the one route to abort rather than to a re-scheduled date.
• Support and timing as separate hard gates: "Support trained and staffed?" and "Change window and calendar clear?" each answer straight to no-go on Not ready or Clash, keeping operational readiness out of the engineering conversation.
• A closing pair of decisions that names the outcome: "Executive sign-off given?" (Signed or Withheld) then "What scope is authorised?", branching Full, Conditional and Pilot only into three separate endpoints alongside the no-go and abort terminators.

When to use this template

• You hold a readiness or launch review and the criteria live in people's heads, so the outcome depends on who is in the room and how the week has gone.
• Your reviews only ever produce "go" or "delay", and partial readiness (a late vendor, a thin support rota) has nowhere to land except a full stop or an unrecorded gamble.
• You need to settle decision rights before the next release forces the argument: who can waive an acceptance criterion, who can accept an over-threshold defect, and whose sign-off is required.
• You are documenting how changes are authorised, tested and approved for an audit or a customer security questionnaire, and need to show the criteria as well as the approval.
• You are running a post-incident review of a release that should not have shipped, and want the discussion to be about which question was skipped rather than a reconstruction from memory.

How it works

1. Rename the lanes to your real decision rights

   Replace Release manager, Engineering and QA, Operations and support and Executive sponsor with the roles that genuinely hold the answer in your organisation. Keep the lanes to who answers, not who is involved: if three teams contribute evidence to one question but one person decides it, that question sits in the deciding lane. Merge any lane where you cannot name a specific person or role.

2. Write the thresholds down before you need them

   The tree is only as good as its tests. On "Defects within severity thresholds?", record the limit per severity for the released scope, who may override a breach, and whether the count includes known issues carried from earlier releases. Do the same for "Acceptance criteria all met?" by marking each criterion mandatory or desirable at scope freeze, so the gate is not renegotiated on the day.

3. Define what a tested rollback means

   "Rollback tested successfully?" should mean rehearsed against a production-like environment, timed, with a named person able to execute it and a written trigger for calling it. Note the data question explicitly, because a schema or migration change is often what turns the answer to "Is the change reversible at all?" into No, and that branch is the only route to abort.

4. Make the conditional and pilot outcomes real

   A conditional go is only different from a plain go if each condition carries a named owner, a due date and a stated consequence if it is missed. A pilot go needs its cohort defined, the exposure percentage or customer list written down, and the criterion for widening. Add both to the comment field on "What scope is authorised?" so the review cannot end on an unqualified nod.

5. Separate no-go from abort

   No-go means the same release ships later, so it needs a re-scheduled date and a named blocker before the meeting closes. Abort means the release is pulled and the scope goes back for rework or reconsideration. Keeping them as distinct endpoints stops a genuine abort being recorded as a two-week delay that quietly repeats.

6. Publish it, then review it after each gate

   Share the tree where the review actually happens, alongside the evidence pack, and capture sign-off from the people named in the lanes. After each release, check whether any question was answered without evidence and whether an outcome you needed was missing. Keep the earlier versions so you can show when the criteria changed and why.

Frequently asked questions

What is the difference between a go/no-go decision tree and a release process map?

A release process map answers "what happens next, and who does it". It shows tasks in sequence across swimlanes — scope freeze, build, test, deploy, monitor — and treats the go/no-go call as a single node. A decision tree answers "which option do we choose, and who decides". Its spine is a chain of questions rather than tasks, its branches are labelled with answers such as Met, Above, Waivable or Withheld rather than with the next activity, and it terminates in several distinct outcomes instead of funnelling back into one happy path. Use both: the process map for the end-to-end flow, at /templates/software-release-process, and this tree for the gate inside it.

What questions belong in a go/no-go decision?

Seven cover most launches. Are all mandatory acceptance criteria met? Are open defects within the agreed severity thresholds? Are dependencies and third parties ready? Has the rollback been tested, not merely written? Are support and operations trained and staffed for the expected volume? Is the change window clear against the business calendar as well as the technical one? Is executive sign-off in place? Each should be answerable from evidence collected before the meeting, which is why the tree starts with a readiness evidence pack rather than with the first question.

Who makes the go/no-go call?

One named person should chair it, usually the release manager or whoever owns production, but the useful discipline is assigning each question rather than the whole decision. Engineering and QA answer the acceptance and defect questions, operations and support answer rollback and staffing, the release manager answers dependencies and the change window, and the executive sponsor answers sign-off. Written that way, the chair's job is to run the tree and record the outcome, not to arbitrate every question personally. Recording who answered what also matters for evidence: control frameworks such as SOC 2 expect changes to be authorised, tested, approved and documented, and a decision tree with named decision rights is a straightforward way to show it.

When should a go/no-go end in a conditional go rather than a no-go?

When the outstanding item does not put the release at risk and someone will own it after launch. A conditional go is a real outcome only if each condition has a named owner, a due date and a stated consequence for missing it; otherwise it is a plain go with extra paperwork. Reserve no-go for anything that would leave users exposed or unsupported. In this tree, blocking acceptance gaps, an unagreed over-threshold defect, a hard dependency you cannot ship without, an unready support function and a change window clash all route to no-go with a re-scheduled date.

What is the difference between no-go and abort?

No-go means the release is deferred: the same scope ships at a re-scheduled date once the blocker clears. Abort means it is pulled and the scope returns for rework or reconsideration, with no date attached. Keeping them apart matters because a release that cannot be reversed at all, or one where the executive sponsor withholds sign-off on business grounds, is not waiting on a fix — recording it as a delay leads to the same review being held again a fortnight later with the same evidence.

How do I limit a launch to a pilot or canary group?

Treat it as an outcome of the decision, not as a compromise reached in the room. In this tree the final question, "What scope is authorised?", branches Full, Conditional and Pilot only, so a limited release is chosen deliberately after every readiness question has been answered rather than as a way of avoiding a no-go. Before the review, define what a pilot means in your product: which cohort or exposure level, how long it runs, what is monitored, and the criterion that authorises widening it.