Confirmation session with key members to approve go-live/cutover
Agenda & Purpose:
The Go / No Go meeting which agrees whether the project move into roll-out. This meeting is normally very close to the planned implementation and has an attendee list with senior stakeholders.
At this decision point the team responsible for the launch of a release needs to decide whether the solution/release is ready and verified and is in a condition that is acceptable to be released into the live environment.
Go/No-Go is a milestone. It is an event in time. Go/No-Go separates the development and testing of a product or service from its release. The release CANNOT go live WITHOUT a “Go” resulting from the “Go/No-Go” event.
Theoretically, the preparations for the launch only start after “Go/No-Go” has resulted in a “Go”. In practice however, preparations for the launch may start even before the Go/No-Go has been completed (with the assumption that in case of a “No”, all preparations could be a waste).
Decision-making Process: Unanimous vote. It is considered a “Go” only when every item in the checklist is voted “Go”. Even if a single “No-Go” is there, the outcome is “No-Go”. The checklist and the vote should be signed-off. For reasons of clarity as well as team spirit, a simultaneous verbal vote is also helpful.
Attendees: Everyone responsible for at least one item in the “Go/No-Go” checklist should attend.
Duration: Brief. Ideally between 5 to 15 minutes. At max 30 minutes.
Medium: The best option is to meet in person. If not possible, you can set up a conference call. In any case, absolutely NO email-based participation should be entertained.
Artifacts: The artifact needed is called a “Go/No-Go” checklist. It could have two forms:
- Person vote list – Each person votes on whether he/she approves the launch.
- Responsibility vote list – Person responsible for a specific module or function for the launch votes on his/her item, whether it is a “Go” or not. This is generally used for bigger launches where visibility across modules is not available.
This could be in a sheet of paper or software (eg. ClickUp). This list needs to be available with the team much before the “Go/No-Go” meeting so that everyone is prepared for it. Ideally, each item in the “Go/No-Go” checklist is captured as a requirement/test-case that gets tested much before the release arrives at the doors of “Go/No-Go”.
Result: The result of a “Go/No-Go” event has to be binary: either a “Go” or a “No-Go”. It cannot have ifs and buts.
“No-Go” could come with a decision to redo the “Go/No-Go” at a later point in time, but it is still a “No-Go”.
“Go” means that the release is approved for launch and the launch sequence needs to get started.
“No-Go” means that the release is not approved for launch. A follow-up meeting/discussion needs to result in identifying the items that needs to be taken care of in order for the next “Go/No-Go” to result in a “Go”.