Demystifying Go/No-Go!

The countdown… 3… 2… 1… Launch… YAY!! (Celebrations follow)

If things work out well EVERYONE comes to know about the launch, after it is done with. SOME do know about and witness the launch sequence (for instance the people watching a shuttle launch, while the shuttle program was active). However, ONLY A FEW take part in the “Go/No-Go".

So, What is a Go/No-Go?

Well, simply said, it is a decision point in a product release cycle, a very important one. At this decision point the team responsible for the launch of a release needs to decide whether the 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).

Why do we need a Go/No-Go?

As with every action in life, rational beings take decisions (consciously or subconsciously) before proceeding with an action. The “rational being” that we referred to here could be a person, a team or an entire organization.

Sometimes the decision is about which path to take. Sometimes it is about whether to take steps back. And sometimes it is about whether to move forward or not. “Go/No-Go” is a decision on whether to move forward or not.

Product launches or version releases are important actions in the life of an organization/team. A successful release could boost the organization to new heights of success, while an unsuccessful one could destroy its reputation and value. Thus, taking a collective decision on whether to move forward with the launch absolutely makes sense, doesn’t it?

How to run a Go/No-Go?

“Go/No-Go” is the responsibility of the person who bares the ultimate responsibility for the launch. In case of a Project, it generally is the Project Manager. Let’s look at how to run a “Go/No-Go” meeting.

The basics of a “Go/No-Go” meeting are simple – you have to bring together the right people to make a collective decision on whether the release can go live or not.

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

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.

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

Conclusion

Hope that clears a bit of dust around “Go/No-Go” events. End of the day, it is a decision milestone on whether to go live or not. Would love to hear your thoughts and opinions and also, how you run your Go/No-Go.

Note that in the context of rolling updates and environments with A/B testing and other forms of dynamic rollouts, the form of a “Go/No-Go” could change, and in some cases move partially or completely into rule-based automation (depending upon the type of the release). More on that – later!