Go-Live in Three Weeks with 31% Defect Escape
A regulator-facing payments programme is three weeks from go-live. Six delivery teams share a release train. Current state: 4 open severity-1 defects, 37 open severity-2 defects, and a defect escape rate of 31% - roughly one in three defects is found in the test environment after the team has declared the feature done. The architecture review board has a six-week queue, and three architecture exceptions required for go-live are still undecided. The business sponsor states that slipping the date will trigger contractual penalties. The rollback plan exists on paper and has never been executed. Two of the 37 severity-2 defects affect the audit trail for transaction amendments.
1. Recommend go or no-go, with the specific conditions attached to your recommendation.
Read the worked answer
Recommend a conditional go, with the conditions written down and owned, and be explicit that some of them are hard stops.
Hard stops - no go without them. All 4 severity-1 defects closed and verified. The two audit-trail defects fixed, because a regulator-facing system that cannot evidence amendments is not releasable regardless of date. The three architecture exceptions decided, not deferred - shipping on an undecided exception means the risk is accepted by nobody. A rollback that has actually been executed once in a production-like environment.
The escape rate is the real signal. 31% means roughly a third of what you believe is fixed may not be, and the unknown population is invisible at three weeks. That argues for a narrowed release: limited transaction volume, a restricted customer cohort, or feature flags on the newest modules, with hypercare staffing and daily defect triage for a defined period.
Triage the remaining 35 severity-2 defects into three buckets: breaks correctness, has a workaround, cosmetic. Only the first bucket blocks. Publish the list so the sponsor owns the deferrals.
Do not let the penalty clause alone drive the decision - price the penalty against a failed release.
2. The architecture review board's six-week queue is now blocking delivery. How would you redesign governance so decisions arrive in time without bypassing review?
Read the worked answer
A six-week queue is not governance, it is a bottleneck that teams route around - which is how you end up with three undecided exceptions blocking a release.
Tier the reviews. Most changes follow known patterns. Pre-approve a set of reference architectures and a short checklist, and let a single embedded architect sign those off in days. Reserve the full board for genuine exceptions, cross-domain impact, and anything touching security or regulatory posture. That alone might remove 70% of the queue.
Give decisions a service level. Publish a turnaround commitment by tier, with an escalation path that fires automatically when it is breached. The board must be accountable for its own latency, not only for the quality of its decisions.
Decide in public. Publish architecture decision records with the rationale, so teams stop re-asking settled questions and new joiners can self-serve.
Clear the current backlog separately. Triage the queue in one session: approve, reject, or send back for information. Half of a six-week queue is usually waiting on information, not on deliberation.
None of this weakens review; it aims the board's scarce attention at the decisions that actually need it.
3. The sponsor offers to defer all technical debt remediation to a post-go-live phase to protect the date. Respond.
Read the worked answer
Accept the deferral of remediation, and refuse the deferral of visibility.
A post-go-live phase with no date, no owner, and no capacity is where debt goes to become permanent. So the condition of deferring is that each deferred item is logged with its interest rate stated in business terms - how much slower delivery becomes, which failure mode it enables, what it costs to operate - and that a fixed percentage of the release train's capacity is reserved for it from the first sprint after go-live, not from an unnamed future phase.
The 31% escape rate is a strong hint that some of the 'new' work is really debt: thin test coverage, brittle environments, manual release steps. Deferring those and expecting defect rates to fall is contradictory.
Separate the argument too. Some items are debt (cost of change rising) and some are defects-in-waiting (correctness risk). The audit-trail issues are not debt and cannot be traded against the date at all.
Finally, make the trade visible to the sponsor in writing: this date is being bought with these specific future costs, and here is who owns them.