The go/no-go decision: how to prepare it and who decides

What the go/no-go decides

A go/no-go is the moment the business says: this version of the CRM may go to production, on this date. Or it says: not yet. It is not a formality at the end of the test. It is the reason the test was done.

A good go/no-go has three parts:

• Facts. What was tested, what passed, what is still open. Taken from the test results, not from memory.
• A judgement. The owners of the processes say whether they can do their work with this version, and on what conditions.
• A decision. The steering committee weighs the facts and the judgements against the go-live date, and decides.

Most go/no-go meetings that go wrong lack the first part. People argue about how bad an issue is, or whether a process was tested at all, because nobody has the figures. The rest of this guide is about making sure the facts are there before the meeting starts.

Exit criteria: agree them before the first test day

Exit criteria say when the test is good enough to go live. Agree them with the steering committee before the first test day. At the end, emotions run high and dates are close. That is the wrong time to decide what counts.

Criteria that work for most CRM go-lives:

• No Critical issue is open.
• Every Must test case has passed.
• Every open High issue has a workaround or a date for the fix that the business accepts.
• Every test case in scope has a result.
• The owner of each process has signed off.

Agree what the words mean

Criteria only work when everyone uses the same scale. Write down what each severity means, and share it with testers and the steering committee alike:

Do the same for priority. A test case marked Must covers what has to work on day one, such as creating a quote or routing a case. If a Must test case fails, the go-live is at risk. See Writing test cases business testers understand for how to set priorities.

Write down what is not tested

Every UAT leaves something out: a country that goes live later, a report that is not ready, an integration tested only in the system test. Put it on paper before the test. Then nobody at the go/no-go can say they assumed it was covered.

Who decides

Two groups of people take part, with different roles.

The owners of the processes sign off

For each process or group in the test, one person from the business signs off: the sales director for lead to cash, the head of customer service for case management, the finance lead for invoicing. They know what their teams need, and they will live with the result. Their sign-off says: my people can do their work with this version.

Name them at the start of the project, not in the last week. A process owner who first sees the test in the go/no-go meeting will either sign without reading, or ask for another week.

The steering committee decides

The steering committee takes the decision for the whole go-live. It usually has the sponsor from the business, the project manager, a lead from IT and, with an implementation partner, someone from the partner. It weighs things a single process owner cannot see: a contract with the old CRM that ends, a training plan, a migration weekend, other projects on the same date.

The test lead prepares, but does not decide

The test lead brings the facts and an advice. The test lead does not sign off for the business and does not take the decision. Keeping these roles apart is what makes the decision stand when something goes wrong after go-live.

The report: what goes in it

The go/no-go report is for people who were not in the test. Keep it short: one page, with the details behind it for those who want them.

• An advice. Go, go with conditions, or no-go, with the reasons in one or two lines.
• Scope. Which processes and user stories were in the test, and what was not tested.
• What was tested. The environment, the release and the build. A result belongs to one version of the system.
• The figures. Test cases passed, failed, blocked and not finished.
• Per group or process. The same figures, with the sign-off of each group.
• Per priority. How many Must, Should and Could test cases passed, and which Must test cases have not.
• Issues by severity. How many are open, ready for retest and closed, with the open Critical and High issues by name.
• The sign-offs. Who signed, when, with what decision and which conditions.
• Known risks. The workarounds the business will use in the first weeks, and who supports them.

Send the report a day before the meeting. People who read it at home ask better questions.

In UAT StudioThe Go/no-go report on the dashboard holds the indication (GO, GO with conditions or NO-GO, with the reasons), the figures, progress per day, the results per group, per epic and per priority, the issues by severity, the open Critical and High issues by name, and every sign-off of the round. The indication follows fixed rules and is advice: the steering committee decides. Share it as a PDF or download it as slides for the steering committee deck.

What to do with open issues

There are always open issues at the end of a UAT. The question is not whether there are any, but whether each one has a decision. Go through them before the meeting, with the business and the development team, as in the daily triage.

Reclassify with care

In the last days there is pressure to move a Critical issue to High. Sometimes that is right: a workaround turns up, or the process turns out to be rare. Do it openly, in the triage, with the process owner, and write down why. Never do it quietly to make the figures look better. That is how a go-live fails in its first week.

Wishes are not defects

Testers find things they would like to be different. If the system works as designed, it is a change request: it goes to the backlog, not into this release, and it does not count against the go-live.

In UAT StudioThe triage gives each issue a severity, a priority, an assignee and a decision: Fix, Reject or Change request. With the AI test design module, Summarize with AI on the Issues tab writes a short overview of the open issues for the go/no-go meeting: grouped by theme, with what blocks go-live. Without it, Summarize with your own AI gives a prompt to paste into your company's AI.

A conditional go

Many CRM go-lives get a go with conditions. The system is good enough, provided that something is done before or right after go-live. That is a fair decision, as long as the conditions are real.

A good condition is:

• Concrete. The discount approval for orders above 50,000 is fixed and retested, not the approvals work.
• Owned. One person is responsible for it, by name.
• Dated. Before go-live, or a date in the first weeks after it.
• Checked. Someone confirms it was done, and the steering committee hears about it.

Watch the number of conditions. Two or three are normal. Fifteen mean the test is not finished. A conditional go is not a way to avoid a no-go.

Go-live in parts

Sometimes one process is not ready and the rest is. You can then go live without that process, or with one country or team later. Decide it explicitly, write down the new date for the part that waits, and plan its own UAT round and sign-off.

Sign-off per group

Ask for a sign-off per process or group, not one signature for everything. A sales director cannot judge case management, and should not have to. Each owner chooses one of three answers:

• Accepted: my people can do their work with this version.
• Accepted with conditions: provided that the conditions are done. Write each one down, with who does it and by when.
• Rejected: not good enough to go live. Ask what would change the answer.

Collect the sign-offs before the meeting, so the steering committee decides on the full picture. A sign-off belongs to one version: when a new build or a new round of tests follows, sign off again.

In UAT StudioThe Sign-off card on the dashboard has a row for the whole project and one for every group, with Accepted, Accepted with conditions or Rejected. The date, the time and the number of open Critical issues are recorded. By default, nobody can accept while a Critical issue is open; with No sign-off while Must test cases have not passed ticked, accepting also waits until every Must test case has passed. Rejecting is always possible. A sign-off belongs to the current round.

Running the go/no-go meeting

Plan the meeting when you plan the test days, with the date in the calendar of the steering committee. Keep an hour. A typical order:

1. The test lead shows the report: scope, figures, open issues, sign-offs. Ten minutes, with the figures on the screen.
2. Each process owner says in a sentence or two why they signed as they did, and what their conditions are.
3. Questions about the open Critical and High issues: is there a fix, a workaround, a date?
4. Questions outside the test: training, data migration, support in the first weeks, the plan to roll back.
5. The decision: go, go with conditions, or no-go. Read it out loud, with the conditions, owners and dates.

If the decision is no-go, end with a plan: what has to change, a new test round, and a date for the next go/no-go. A no-go with a plan is a normal project decision. A no-go without one feels like a failure.

The decision log

Write the decision down on the same day. Months later, after an incident or during an audit, someone will ask who decided to go live with that open issue. The answer should take a minute to find.

A decision log holds, for every go/no-go:

• The date, and who was in the meeting.
• The decision: go, go with conditions, or no-go.
• Every condition, with its owner, its date and, later, when it was done.
• The open issues the business accepted, with the reason.
• The report the decision was based on, as it was at that moment.

Keep it with the project documents, and follow up the conditions in the first weeks after go-live, until each one is done.

In UAT StudioSave snapshot on the go/no-go report keeps the report as it was when the decision was made; it does not change any more, and Show opens it again later. Every sign-off stays in the history, also the ones that were replaced or withdrawn. For an auditor, admins download the Evidence pack: the report, the test cases, results and issues, the history of every issue, every sign-off and the audit log, with a checksum of every file.

Free to use

The exit criteria, the sign-off and the report are also in the UAT checklist for a CRM go-live, as a free Excel file. For the whole test, see the guides for a Salesforce UAT and a Dynamics 365 UAT.