Mid-Build Regulation: Change Control Under Pressure
Nine weeks into a 20-week build of a field service app, a regulator publishes a new rule: photographic evidence for every completed safety inspection, retained for seven years. The build is 55% complete. The requirements baseline was signed off in week 4 and has changed three times since, each change approved by email from the operations director. Your traceability matrix holds 78 requirements, but 21 have no linked test case and 9 have no identified source stakeholder. The steering committee meets in five days, and the project manager wants to 'fold it into existing scope' to protect the go-live date.
1. What process failures do these symptoms reveal, and why is folding the change in the riskiest option?
Read the worked answer
Three failures are visible:
- Uncontrolled change. Three post-baseline changes approved by email from one director means no impact analysis, no cost or date assessment, and no audit trail. Email is not a change record.
- Stale traceability. 21 requirements with no test case means untested scope; 9 with no source stakeholder means requirements nobody owns and nobody can validate. A matrix that exists but is not maintained is worse than none, because it creates false confidence.
- No change gate. If changes bypass the board once, they will bypass it again, and the baseline stops meaning anything.
Folding the regulation into existing scope is the highest-risk option available. It is a legal requirement with seven-year retention implications: photo capture, storage, access control, purge policy, and likely a data residency question. None of that is in the current design. Absorbing it silently means unestimated effort against a fixed date - and if it slips, the failure is a compliance breach rather than a late project, which is a far worse outcome for everyone, including the project manager.
2. What do you take to the steering committee in five days?
Read the worked answer
A pack that converts an unmanaged surprise into a governed decision:
- Impact assessment of the regulation: effort estimate and range, confidence level, dependencies (storage, retention and purge, audit, access control).
- Options with consequences, not a single recommendation: extend the date by X weeks; hold the date and descope named items worth at least the estimate; phase it - manual photo capture into the existing file store at go-live, automated retention in release 2, with a documented interim control.
- A formally raised change request: requester, regulatory driver, rationale, decision owner.
- A traceability clean-up plan: assign owners to the nine orphan requirements, link or retire the 21 untested ones before the baseline is re-issued.
- A re-baseline plus a CCB mandate: all future changes through the board, email approvals explicitly rejected.
Ask the committee to choose an option and name an owner, and record both in the decision log. The deliverable is not the estimate - it is a decision with a name on it.