A Go-Live Date That Cannot Hold
A solution is three weeks from go-live. Testing status: the happy path has been demonstrated end to end twice in the test environment; the exception paths have been walked through manually but not executed as automated tests; the business object has been tested only against a test instance of the target application, which differs from production in two known ways (a different login flow and an extra confirmation dialog). The business has committed to a regulatory deadline and states that a two-week delay is not acceptable. The test environment has one-fifth of production's data volume, and the largest batch in scope is 9,000 records. Two of the five process areas have no named business owner available for sign-off.
1. Assess the readiness of this solution and identify the specific risks that must be resolved or explicitly accepted before go-live.
Read the worked answer
Readiness assessment. The evidence supports 'the happy path works in a small, unrepresentative environment'. It does not support a production go-live. Three gaps are material:
- Environment divergence. The production login flow and the extra confirmation dialog are untested against the object. These are on the critical path of every transaction, so a defect here is not a corner case - it stops the run. This must be tested against a production-like instance before go-live; it is the single highest-priority item.
- Volume. One-fifth of production data with a 9,000-record batch means the performance and stability characteristics at scale are unknown. A process that completes in test may time out, exhaust memory, or hit application throttling in production.
- Exception handling. Manual walkthroughs prove the logic was considered, not that it works. Automated exception tests are how you find out that the retry loop has an off-by-one or that the exception queue write fails under load.
Additional governance risk. Two process areas have no business owner for sign-off. Without an accountable acceptor, nobody can formally accept the residual risk, and the regulatory deadline does not change that - it makes it worse, because an unsigned solution has no defence if it fails.
What must be resolved, not accepted. Production-like object testing and at least a smoke-level volume test are non-negotiable. The rest can be accepted with eyes open.
2. The sponsor insists the date cannot move. Propose a delivery approach that protects the regulatory commitment without pretending the risks are gone.
Read the worked answer
Reframe the question. The sponsor is protecting a regulatory obligation, not a preference for speed. The job is to find the smallest scope that satisfies the obligation safely, not to argue about the date.
Proposed approach.
- Phased scope. Go live with the process areas that have named business owners and tested paths. Defer the two unowned areas. A regulatory deadline usually attaches to specific obligations; confirm which of the five areas actually carry them and prioritise those.
- Front-load the environment fix. Spend the first week testing the object against a production-like instance, including the login flow and confirmation dialog, and running a reduced-volume batch (say 2,000 records) to get a performance signal. This is the cheapest way to retire the biggest risk.
- Automate the exception tests for the in-scope areas only. Manual walkthroughs are not evidence; a small automated suite covering the top failure modes is achievable in two weeks if scope is narrowed.
- Run in parallel with manual processing for the first cycle, with a reconciliation check comparing automated and manual outputs. This is the real safety net for a compressed timeline.
- Document residual risk explicitly. Record what was not tested, who accepted it, and the rollback plan. The two unowned areas should be formally deferred in writing, with the sponsor as acceptor.
What I would refuse. I would not sign off a solution where the object has never run against production-like login and dialogs, and I would not let 'the date cannot move' substitute for a named acceptor of the residual risk.