A go/no-go meeting is the last checkpoint before a change goes live. Done well, it takes fifteen minutes and prevents the outage you would otherwise spend the night fixing. Done badly, it is a status meeting where everyone says “looks fine” and nobody writes anything down.
This guide covers what to check, who decides, and how to record the decision.
What a go/no-go decision is for
The purpose is not to re-plan the change. It is to answer one question with evidence: are we ready to start, and can we get back if it fails?
That breaks down into three parts:
- Readiness: the prerequisites are done and verified.
- Risk: the people doing the work agree the risk is acceptable right now.
- Recovery: there is a tested rollback plan and someone who owns it.
The checklist
Use these as checks (yes/no), questions (must be answered in writing) and follow-ups (things that must happen before execution).
Checks
- All prerequisite tasks are complete, with evidence attached and verified.
- Backups or configuration snapshots are taken and their location is recorded.
- The change window is confirmed with the customer and affected teams.
- Monitoring and alerting are in place for the affected services.
- The rollback plan is written, reviewed and assigned to an owner.
- Everyone executing a step is available for the full window.
Questions
- What is the expected customer impact, and has it been communicated?
- What is the point of no return, and what is the decision deadline before it?
- Which step is most likely to fail, and what does failure look like?
- What would make us abort mid-change?
Follow-ups
Anything that comes up in the meeting and must happen before execution. For example, “notify the service desk” or “confirm the partner’s on-call number”. Follow-ups should block the change steps until they are done, not live in someone’s notebook.
Who votes, who decides
- Voters: one person per team that executes a step, plus the service owner. Each votes GO or NO-GO.
- A NO-GO always needs a reason. That reason is the most valuable thing the meeting produces.
- One decision owner makes the final call. Votes inform the decision; they do not replace accountability.
Document the decision
An auditor (or you, three weeks later during an incident) needs to see:
- who attended and how each person voted;
- the answers to the questions;
- the decision, who made it, and when;
- which follow-ups were created and when they were completed.
If this lives in a chat thread, it is effectively lost.
Running it in TurboProject
TurboProject turns this checklist into a change hub attached to the change task:
- checks, questions and follow-ups are a validation checklist that must be complete before the decision owner can say GO;
- votes are recorded, and a NO-GO requires a reason;
- on GO, every follow-up becomes a task and is added as a prerequisite to every step that depends on the hub;
- change steps are then routed to their owners, and a failed step starts the rollback plan in reverse order;
- if things go wrong, the hub can be escalated to a war room that already contains the full history.
See how change management works in TurboProject, or book a demo and bring your own checklist.