340 Baselined Requirements, One Regulatory Change, and No Change Board

Assess the change on four dimensions, and treat the traceability gap as part of the impact rather than as later cleanup.

1. What the change touches Retention of declined applications affects the data model and storage, archival and retrieval for customer queries, decline notification letters, regulatory reporting and test data management. Trace forward from the regulatory obligation to design and test; trace backward from affected screens and batch jobs to originating requirements, to establish whether a requirement was missed or the need is genuinely new.

2. Sources of impact data The solution architect, the test manager's case map, records and compliance, the vendor's estimate, and the affected business process owners. Do not estimate alone - your role is to make the impact explicit and owned.

3. The untraced requirements are the real risk The 41 unlinked requirements (12% of 340) may contain the declined-application storage rules. Before any decision, run a targeted, risk-based recovery: ask original owners to identify design elements for those 41, prioritising anything touching regulated data, financial calculation or audit. Full retrospective traceability of 340 items is not affordable in seven months; risk-based recovery is.

4. Content of the impact statement Requirements added and modified, affected processes and roles, test impact (new and regression cases), cost and schedule against the seven-month go-live and the regulatory effective date, risk of non-implementation (regulatory breach), and options (implement fully now, phase it, or apply an interim manual control).

5. Recommendation Approve the retention rule as mandatory scope with its own approval record, re-baseline the affected requirement set, and state explicitly that the regulator's effective date - not the go-live date - drives priority.

The email approvals are a governance defect that has already produced three unevaluated changes. Fix the process before deciding the request, otherwise the decision will not hold.

Minimum viable governance

• A change control board with named members and clear decision rights: sponsor (value and priority), solution architect (feasibility), test manager (quality impact), business owner (fit for purpose), and you presenting the assessment. Weekly, 30 minutes, with quorum defined.
• One change request format capturing description, reason, affected requirements and traceability links, impact on scope, schedule, cost, risk and quality, options, and recommendation.
• A decision log with status and rationale. Email threads are not an audit trail, and the regulator will treat this system as in scope.
• Delegation thresholds so the board is not a bottleneck: low-impact changes (wording, minor fields) delegated to the business owner; anything affecting regulated data, interfaces or the release date goes to the board.

Handle the three retro-fitted changes Register them retrospectively, assess impact now, and have the board ratify or reverse each. Where reversal is impractical, record it as accepted debt with a named risk owner.

Then the bureau-refresh request Present a real impact statement rather than an estimate alone. Six weeks and $400k against a seven-month go-live probably means a date move or a scope trade. Give the board three options - implement fully now, phase to a later release, or defer with a documented workaround - with the consequence of each, and let the sponsor choose with the trade-offs visible.

Prioritisation discipline is what makes the decision defensible; both items cannot be 'must have'.

1. Agree the basis before scoring Value, risk including regulatory exposure, cost, and dependency, weighted and agreed with the sponsor in advance. Without an agreed basis, every discussion becomes advocacy.

2. Classify on that basis

• Data-retention rule: mandatory, regulatory. The regulator's effective date sets the timing; it is not traded against feature value.
• Bureau refresh: high business value, but deferrable if the nightly refresh meets the service standard. Test the claim - what decision latency do underwriters and customers actually need?

3. Sequence rather than simply choose Options: defer to a dated later release; reduce scope (refresh on resubmission only); or accept the six-week slip and move go-live, which is a sponsor decision recorded with its rationale.

4. Rebuild traceability economically

• Trace requirement to test case for high-risk requirements only - regulatory, calculation, integration - and skip fine-grained links for cosmetic items.
• Have test cases derive from requirement identifiers going forward, so coverage becomes a by-product of test design rather than a separate exercise.
• Publish a weekly coverage report: requirements without a test case become visible and get fixed.
• Close the 12% gap by risk, not by completeness for its own sake.

5. Baseline hygiene Re-baseline the affected set after each approved change, retain the prior baseline for audit, and record approver, date and version. Test planning then keys off a stable, versioned baseline instead of moving prose.