The Go/No-Go Call: Making a Release Decision Defensible

Every go/no-go decision is made under uncertainty. You will never have complete information, and a meeting that waits for it never reaches a decision. The analyst’s job is not to eliminate the uncertainty, it is to make it explicit and priced, so the people signing know exactly what they are accepting.

The failure mode of these meetings is well known to anyone who has sat through a few. A status deck is presented, testing is reported as ninety-five percent complete, everyone looks around, nobody wants to be the person who stops a release with a committed date, and the decision defaults to go. Two weeks later the postmortem finds that three people had reservations and none of them said so in a form anyone could act on.

The fix is not courage. It is evidence, assembled beforehand, in units the business understands. The deliverable templates for that evidence are in Real-World BA Deliverables.

What is the decision actually asserting?

A go says four things at once, and saying them out loud reframes the meeting usefully.

We believe the system does what the business needs, well enough. We know what is still broken and we accept those consequences. We can operate it on Monday morning, including the exception cases. And if we are wrong, we know what we will do about it.

Notice that only the first is about testing. Most release failures I have watched were not caused by an undiscovered defect. They were caused by a support team that had never seen the new screens, a runbook that described the old process, a downstream report that stopped arriving, or a rollback plan that turned out to take eleven hours.

Evidence, not opinion

This is the single change that improves these meetings most, and it is entirely within an analyst’s control.

Opinion	Evidence
”Testing is complete"	"142 of 146 scenarios executed. The 4 outstanding are all in the recall flow, which is not used until phase 2."
"There are a few minor defects"	"Three open. One affects the limit rejection message, roughly 40 contact centre calls a day, workaround is a scripted response. Two are cosmetic."
"Performance looks fine"	"Peak file of 4,200 payments processed in 6 minutes against a 15 minute window. We have not tested above 10,000."
"Operations are ready"	"Runbook v3 walked through with both shifts on Tuesday. Two of nine staff have not been trained and are on leave until the 14th."
"We can roll back"	"Rollback rehearsed in SIT, took 40 minutes. Not rehearsed with production data volumes.”

Every row on the right supports a decision. Every row on the left requires the reader to guess, and under time pressure people guess optimistically.

The right-hand column also has a property worth noticing: it makes disagreement cheap. Nobody has to challenge a colleague’s judgement to say “eleven thousand is our year-end volume and we have not tested it”. The number does the work, and the conversation stays technical rather than becoming personal.

The seven readiness dimensions

Functional testing is one of seven. Teams that check only the first are surprised by the other six, in my experience roughly as often as by defects.

1. Functional coverage. Which business processes are proven, not what percentage of test cases passed. Percentages hide shape: ninety-five percent complete means nothing if the missing five percent is the entire returns flow. Map coverage to processes, which is what the traceability matrix is for.

2. Open defects with impact. Each one with business consequence, workaround, and owner, exactly as produced by triage. If this list is being assembled the day before, the deferrals were not decisions.

3. Non-functional behaviour. Volume, response time, the batch window, the month-end peak. The classic failure is a system tested at average volume and released before a seasonal peak, and the non-functional requirements are where the target numbers should already be written down.

4. Operational readiness. Runbooks updated, support trained, monitoring and alerting in place, the exception queues staffed. This is the dimension analysts most often assume somebody else owns, and it is the one that generates the most day-one pain.

5. Rollback. Covered below. It gets its own section because it is the one most often waved through.

6. Data migration and reconciliation. Where data has moved, has it been counted, reconciled, and checked for the awkward records rather than the clean ones. Reconciled means proven equal, not “looks about right”.

7. Downstream consumers and communications. Everyone who reads the data, and everyone who needs to know the release is happening. On a payments migration this is the blast radius list, and each consumer is either confirmed ready or explicitly accepted as a risk.

The rollback question

Ask it directly, before go-live, in the meeting: how do we undo this, and how long does it take?

Three answers are acceptable, and they are all specific: we restore from backup and it takes N hours, we deploy the previous version and it takes N minutes, we switch traffic back and it takes N minutes. Anything vaguer than that means there is no rollback plan, only a rollback intention.

Then ask the second question, which is the one people forget: has it been rehearsed, and at what scale? A rollback tested in a small environment tells you the mechanism works, not how long it takes with production data volumes. That gap is where an intended forty-minute recovery becomes a six-hour outage.

And then the third, which matters most in payments and in anything that moves money or sends messages: what cannot be undone? Restoring a database does not unsend a payment. It does not recall a message delivered to a scheme, unsend a customer notification, or reverse a settlement. Those actions are one-way, and a release that performs them crosses a threshold after which rollback is a partial remedy at best. Knowing where that threshold sits in the cutover sequence changes the decision from “we can always go back” to “we can go back until 09:40, after which we are committed”, and stating it in those terms is one of the most valuable sentences an analyst contributes to the meeting.

What does a real conditional go look like?

Conditional go is the most abused outcome in delivery, because it lets a room avoid a decision while feeling like it made one.

A real conditional go has conditions that a named person can verify unambiguously before the release executes:

Go, conditional on:

1. Defect PAY-4471 fix deployed and verified in SIT by 16:00 Friday. Owner: dev lead. Verification: QA re-test, result in the ticket.
2. Remaining two operations staff trained on the repair queue. Owner: ops manager. Verification: signed attendance.
3. Volume test at 10,000 payments completed with the batch finishing inside the window. Owner: performance lead. Verification: test report circulated.

If any condition is unmet at 17:00 Friday, the release does not proceed and the decision returns to this group.

A fake one reads: “Go, subject to monitoring closely over the weekend and the team being on standby.” Neither of those is checkable, neither has an owner, and neither would stop the release, so the sentence is decoration on an unconditional go.

The last line of the real version matters as much as the conditions. Without a stated consequence for an unmet condition, the default at 17:00 on a Friday with a committed date is to proceed anyway.

Who signs, and what are they signing?

Named business and technology owners, not the project manager, and not the delivery team alone. The delivery team is the least well placed group to make this call, having spent months investing in the outcome.

The business owner is accepting the operational and customer impact, including the deferred defects and the manual workarounds their people will run. The technology owner is accepting the stability and support consequences. Both should be able to state, in their own words, the top three risks they are accepting. If they cannot, they have not been given the evidence in a usable form, which is your problem to fix before the meeting rather than theirs to overcome during it.

Your own role is narrower and specific: translate technical status into business consequence, and make residual risk explicit. You are not the decision maker. You are the person who ensures the decision is informed, which includes saying the uncomfortable thing out loud when it is true. An analyst who says nothing worries them when three things do has not been diplomatic, they have withheld the input they were in the room to provide.

The five questions worth asking in every one

Whatever the format, these five surface most of what goes wrong.

“What have we not tested?” Far more useful than what has been tested, and much quicker to answer honestly.

“What are we assuming will be fine?” Every release rests on assumptions nobody has verified. Naming three of them takes two minutes and occasionally stops a release.

“Who finds out first if this goes wrong, and how?” If the answer is a customer, monitoring is not ready. The answer should be an alert and a named team.

“What happens on the first working day at peak?” Releases are often deployed at a quiet moment and meet reality on Monday at nine. Walk through that hour specifically.

“What is the one thing most likely to bite us?” Ask each person individually, going round the room. People who will not volunteer a concern in open discussion will answer a direct question, and the answers are usually consistent, which is itself the finding.

The takeaway

A go decision is made under uncertainty, so make the uncertainty explicit and priced rather than trying to eliminate it. Replace opinion with evidence: not testing is complete but which scenarios remain and where, not a few minor defects but the specific impact and workaround of each.

Check all seven readiness dimensions, because functional coverage is one of them and operational readiness, rollback, data migration, non-functional behaviour, downstream consumers, and communications fail releases just as often. Ask how the rollback works, how long it takes, whether it has been rehearsed at scale, and above all what cannot be undone, because in payments the point of no return is a real moment in the cutover sequence and everyone should know when it passes.

Make conditional go conditions verifiable by a named person with a stated consequence if unmet. Then ask the five questions, including the one asked round the room individually, because the concern nobody volunteers in open discussion is usually the one worth hearing.

Start with Real-World BA Deliverables for the readiness and sign-off templates, and Break Into Banking for the cutover realities specific to payments, or take the full library in The Complete Tech BA Bundle.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Release Management, Delivery, Risk, Go-Live