Structuring Go/No-Go Meetings and good preparation make sure you get the right decision

Your whole project plan is often geared to a key decision point - the Go / No Go meeting which agrees whether the project move into implementation and roll-out. This meeting is normally very close to the planned implementation and often has a large attendee list with senior stakeholders which are difficult to reschedule. Therefore it is important that good preparation occurs and the correct decision is made. I'll take you through my approach in this post.

Outcomes from Go/No-Go Meeting

You might think that the meeting outcome is binary but in my Go/No Go meetings there are 3 possible outcomes and this is often useful to keep the project on track.

My definition of the 3 outcomes is as follows:

1. GO - The meeting agrees that the project can proceed into implementation
2. NO GO - The meeting agrees that the project cannot proceed into implementation for reasons which are minuted. When these points are addressed another meeting needs to be scheduled for consideration. With most projects, a no go decision is likely to create delay to the key go live milestone
3. GO WITH CAVEATS - The meeting agrees that the project can proceed into implementation if minuted points (caveats) are closed off in a set time. The meeting delegates the determination of whether these have been closed off to the Project Manager and no follow up meeting is required

Establish criteria by which a decision will be made

Well in advance of the meeting, agree the criteria by which the decision will be made. This gives you a definite framework for running the meeting and stops a "free for all" discussion. The exact criteria may change between projects but if you can make it less subject to interpretation then that is what you should strive for. Here are some example criteria from IT system Go/No Go meetings I have run:

• Testing complete? - evidenced through a signed off test completion report
• Business Readiness complete? - evidenced through sign-off from person responsible
• Implementation Plan fully approved & resources for implementation event secured?
• Post implementation enhanced support plan agreed - evidenced through a signed off document
• Any Issues or Risks to highlight? - this allows me to highlight things to the meeting such as residual project risks, implementation risks or indeed an issue which might impact the go decision
• ITIL change process approved? - normally by approval of a record in the particular change management system

As this meeting is an example of a Gated Entry meeting, you might also want to read my post on the general concepts of these meetings

Try and secure the evidence in advance of the meeting

If you can secure the evidence against each criterion in advance of the meeting you are well placed for a Go decision. So in the example above, secure the appropriate sign-offs of the Test Completion Report and there should be no discussion on testing in the meeting. If the report highlights some residual risks then this should be included in your risk assessment part of the meeting.

Create a document with RAGB statuses against each agreed criteria

Create a document with a RAGB status against each criteria based ideally on an objective assessment else make a judgement. Blue is a colour I use to indicate complete, Red, Amber, Green depending on how much concern the item is for the Go decision.

Use this document to manage within the project team as you approach the Go / No-Go meeting - the trick is where things aren't Blue or Green to have side discussions in advance of the meeting.

Then you should formally issue the INPUT document to the meeting attendees in advance of the meeting

Running the Go/No-Go meeting

Walk through the document criterion by criterion and allow any discussion although for completed items you shouldn't expect much. Once you have been through the whole list, you need to populate the voting section of the document. I always like to start the voting and by so doing, lead the meeting.

I try very hard to be objective and not just say Go as I believe demonstrating a proper objective view gives confidence to other stakeholders. Going live and having a host of problems not highlighted as risks at the meeting won't be good for your reputation. Again, the trick is to work hard before the meeting to ensure you are in the best possible position to say Go although my reputation is that I always vote "Go with caveats" as there is often a sign-off or two still to be chased down!

I always like the sponsor to finish the voting and frankly this the most important vote which should prevail in 99% of meetings. The sponsor can listen to the other votes and where necessary make a judgement call.

After the Go/No-Go meeting

Send out the updated criteria / voting with the outcome from the meeting. If the outcome is Go with caveats or No Go, document and send out the actions arising from the meeting.

Conclusion

The Go / No-Go meeting is a critical milestone in your project plan. Good planning and preparation can give you the best opportunity of getting the correct decision. I commend the framework described here as an effective approach which I have used for many years now. On one project with many roll-outs I was having up to 3 such meetings a week but it worked effectively to get the right decision and equally important, obtain buy-in from key stakeholders.