The UAT Countdown: What to Do When You’re a Few Days from Go-Live and the Bugs Won’t Quit
A survival guide for that very specific flavor of panic every project manager knows
There’s a particular feeling that lives in the final week of User Acceptance Testing. The go-live date is circled in red. The steering committee is expecting a green light. And your defect log just lit up with three blocking issues that absolutely, definitely, one hundred percent were not there yesterday.
Welcome to the UAT countdown — the phase where optimism goes to get stress-tested.
If you’ve managed projects in banking for more than a year, you’ve been here. The good news? This situation, however uncomfortable, is manageable. Not by working a miracle over the weekend, but by making a few clear-headed decisions under pressure. Here’s how.
First: Breathe. Blocking ≠ Catastrophe
The word “blocking” triggers an instinctive alarm. But before you cancel your evening plans and summon the whole team to a war room, pause and ask one question: blocking for whom, and for what?
Not every defect labeled “blocking” actually blocks go-live. Some block a specific edge case. Some block a feature that isn’t part of the first release. Some are blocking only because a tester couldn’t find the workaround that operations has been using happily for years.
The panic isn’t caused by the bugs. It’s caused by undifferentiated bugs — a list where a data-corruption issue sits next to a misaligned button, both stamped “critical.” Your first job isn’t to fix anything. It’s to sort.
Step 1: Triage Like an ER Doctor
When everything is urgent, nothing is. So bring order to the chaos with a ruthless, honest triage. Every open defect gets sorted into one of four buckets:
- True blockers — issues that break a core process, corrupt data, breach compliance, or create real client/financial harm. These must be resolved before go-live. No debate
- Serious but workaround-able — the function is impaired, but a documented manual workaround exists that operations can live with temporarily
- Cosmetic / low-impact — annoying, visible, but harmless. The kind of thing that can wait for the first post-launch patch
- Not-actually-a-bug — misunderstandings, incorrect test data, or expected behavior that the tester didn’t recognize
You’ll often find that a terrifying list of “12 blockers” is really 3 true blockers, 5 workaround-able, 3 cosmetic, and 1 that isn’t a bug at all. That reframing alone changes the entire conversation with your sponsor.
Step 2: Separate “Can We Fix It?” from “Must We Fix It?”
For each true blocker, two independent questions:
Can we realistically fix and re-test it in the time we have? Be honest. A fix that lands the night before go-live with no regression testing isn’t a fix — it’s a new risk wearing a fix’s clothes.
Must it be fixed before go-live, or can it be fixed after? This is the question that separates seasoned PMs from anxious ones. Not everything critical has to be solved on day zero. Some things can go live with a controlled workaround and a committed fix date.
The intersection of these two questions gives you your real action plan — and, crucially, your negotiating position for the go/no-go meeting.
Step 3: The Power of the Workaround
A well-documented, agreed workaround can turn a blocker into a manageable known issue. The formula:
- Describe the defect and its impact in plain language
- Define the manual workaround, step by step
- Name the owner who will execute it and the volume they can handle
- Set the expiry date — the committed deadline for the permanent fix
Get operations and the business owner to sign off on it. A workaround nobody agreed to is a landmine. A workaround everyone signed is a bridge.
Step 4: Reframe Go-Live — It Was Never Binary
The most liberating realization in this whole scenario: go-live is not a light switch. You’re not choosing between “perfect launch” and “cancel everything.” You have options in between:
- Phased rollout — launch for a limited user group, region, or product first. Contain the blast radius
- Soft launch / pilot — go live with a controlled cohort while monitoring closely before scaling
- Feature toggle — ship the release but keep the problematic feature switched off until its fix lands
- Go-live with known issues — launch fully, with a signed, transparent list of open defects and their remediation plan
Each of these lets you honor the deadline and the risk. The PM’s job isn’t to force a binary choice — it’s to put the real options on the table.
Step 5: The Go/No-Go Meeting — Facts, Not Feelings
When you walk into that final decision meeting, leave the anxiety at the door and bring the evidence. A one-page picture:
- The triaged defect list — what’s a true blocker, what’s not
- For each true blocker: fixable in time? Workaround available? Fix committed for when?
- The recommended launch approach (full, phased, toggle…)
- The residual risk, stated honestly, and who accepts it
Then say the sentence that turns a panicking room into a deciding one:
“Here are the three real blockers. Two have signed workarounds with fixes committed by [date]. One must be resolved before launch — here’s the plan and the deadline. My recommendation is a phased go-live on [date], with the remaining fix in the first patch. I need the business owner to accept the residual risk.”
That’s not the voice of someone who lost control. That’s the voice of someone running the situation instead of being run by it.
The One Line That Should Never Be Crossed
A word of seriousness in an otherwise light piece: in banking, there’s a category of blocker that is never negotiable — anything touching compliance, data integrity, client money, or regulatory obligation. No deadline justifies going live with those open. If that’s your blocker, the answer is a calm, well-argued no-go, and a replan. Protecting the bank is always the higher-priority deliverable.
Final Thought
The UAT countdown will always feel dramatic. Deadlines and defects are natural enemies, and they tend to peak at exactly the same moment. But the panic is almost never justified by the facts — it’s justified by the fog.
Your job as a PM isn’t to eliminate every bug before go-live. That’s neither possible nor the point. Your job is to clear the fog: sort the real from the noise, separate the fixable from the deferrable, put honest options on the table, and make sure the person accepting the risk actually understands what they’re accepting.
Do that, and “we have blocking issues days before go-live” stops being a crisis. It becomes just another Tuesday — one you know exactly how to handle.