Stop reporting defect counts
The paper that fails at a steering group is the one that says there are 3 severity-one and 27 severity-two defects outstanding against exit criteria of zero and five. Nobody in that room can act on it. Severity is an internal triage label, the definitions vary by project and are frequently disputed, and a count invites the response that has sunk a thousand cutovers: can we downgrade some of them.
What the room can act on is business consequence with a volume attached. Rewrite every open item as who is affected, how often, and what they cannot do. "Severity one, batch reconciliation fails" becomes "the daily reconciliation between the ledger and the settlement file fails when a file contains a credit note, which happened on 14 of the last 20 working days, so finance cannot close the day without manual intervention taking about two hours".
That sentence is worth more than the entire defect register, because it tells the steering group the frequency, the workaround, and the cost of the workaround. And it forecloses the downgrade conversation, because you can renegotiate a severity label but you cannot renegotiate 14 days in 20.
Put a volume against the workaround
The decision usually turns on whether the manual workaround is survivable, and that is arithmetic anybody can check if you state the inputs.
Suppose the defect is that one payment type does not post automatically. The business processes 4,000 payments a day, and this type is 6 per cent of them, so 240 a day need manual posting. Each takes about 4 minutes, which is 960 minutes, or 16 hours of work a day. The team that would absorb it has 3 people. That is not a workaround, it is a second job, and the honest conclusion is that this defect blocks go-live regardless of what its severity label says.
Change one input and the answer flips. If the payment type is 0.5 per cent, that is 20 a day at 4 minutes, or 80 minutes across three people, which is genuinely absorbable for the three weeks a fix would take. Same defect, same severity, opposite recommendation. Working the numbers in front of the steering group is what converts an argument about labels into a decision, and it is the single most useful thing a business analyst does in the final fortnight.
Two cautions belong with the arithmetic. Manual workarounds have error rates, so a process that requires 240 manual postings a day will produce wrong postings, and someone has to find and correct them. And workarounds decay: a team told to do something manually for three weeks will do it for two, and then quietly stop, which is how a known gap becomes an unknown data quality problem six months later. Say both out loud.
Construct the third option
Go and no-go is a false pair, and offering only those two is what pushes a steering group towards go. There is nearly always a partial cutover available, and building it is your job rather than the programme manager's.
The shapes worth knowing are a scope reduction, where the failing capability stays on the old system while everything else moves; a population reduction, where you migrate one region, one product line or a set of low-risk accounts first; a parallel run, where both systems process and you reconcile daily until confidence is established; and a date shift that keeps the announcement but moves the internal cutover behind it. Each has a real cost — a parallel run doubles the operational load and needs the reconciliation built, a population reduction needs the data split — and quoting that cost is what makes the option credible rather than a way of avoiding the question.
Present three options with their exposure and their cost, then make a recommendation. A paper that lays out options without a recommendation reads as an attempt to avoid being the person who said it, and everyone in the room recognises that. Recommend, and state what would change your mind: if the reconciliation defect is fixed and regression-tested by Wednesday the 6th and the 20-day failure rate goes to zero over five days of retesting, the recommendation becomes a full cutover on the original date.
What this failure looks like in the wild
In April 2018, TSB cut its customers over to a new core banking platform before the migration was ready, and the resulting failures left customers with unreliable access to their accounts for months afterwards. It is the case to reach for here, and the useful reading of it is not that migrations are risky. It is that the date behaved as though it were fixed while the exit criteria behaved as though they were negotiable, and once that asymmetry exists in a programme the outcome follows mechanically: every week of slippage is absorbed by relaxing a criterion, because the criteria are the only thing anyone is allowed to move.
The practical lesson for a business analyst is that exit criteria have to be agreed while nobody is under pressure, written in terms that cannot be reinterpreted, and owned by someone who does not also own the date. If the person accountable for delivering on the 14th is also the person who decides whether UAT has passed, the criteria are decorative. Saying this in an interview, and saying that you would rather set fewer criteria that are genuinely non-negotiable than twenty that will all be waived, is what a senior interviewer is listening for.
The rollback nobody has run
Every cutover paper contains a rollback plan and most of them are fiction. The plan says the old system will be restored from backup and the day's transactions replayed. Nobody has tried it, nobody knows how long it takes, and nobody has established whether transactions written into the new system during the first hours can be reversed into the old one at all — which, for anything that has already sent a payment, told a customer a balance or issued a document to a third party, they frequently cannot.
So the question to ask before the steering group asks it is whether the rollback has been rehearsed end to end, what the last point of no return is, and who decides to invoke it. A rollback with a stated deadline — the decision must be taken by 06:00 on the Monday, after which we are committed — turns an unbounded risk into a bounded one, and it is often the thing that makes a go decision defensible rather than optimistic.
The trailing failure worth naming is what happens after a successful cutover with known gaps. The workarounds are in place, the programme celebrates and disbands, and the defects that were accepted as temporary have no owner, no date and no budget. Hand them over as named items with owners before the programme closes, or they become permanent within a month.
Give the steering group business consequence with volumes, three options rather than two, and an explicit recommendation with its reversal condition. Exit criteria that can be relaxed under date pressure are not criteria, and the date will always win an argument you have not already settled.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).