Client session: Go/no-go

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”.