A Regulatory Change Request at Week 30 With Incomplete Traceability

Do not rely on the matrix as the only route. With 60% coverage and orphaned links, the matrix will under-report impact. Reconstruct dependencies from other artefacts.

Sources to use in parallel:

• The data model and interface specifications: search for customer, ownership, party and onboarding entities to find the three interfaces and any others.
• The rules catalogue: beneficial owner thresholds, verification and exemptions are business rules, not just a field.
• Screen and form designs, downstream reports and extracts that display onboarding data.
• Test cases: the frozen 60% will show which scenarios touch onboarding data and will need review.
• Named owners for each interface, interviewed directly.

Impact dimensions to assess:

• Regulatory: what the rule actually requires, the threshold definition, verification evidence, and whether partial delivery satisfies the obligation.
• Business process: who collects and verifies the data, and what happens to in-flight applications at go-live.
• Data: existing customer records - migration, backfill, quality.
• Technology: three interfaces, validation logic, error handling.
• Testing: frozen cases, regression scope, and the week-34 start.
• Operating model: training, procedures, audit evidence.

Quantify person-days and identify the critical path. Note explicitly that 45 person-days is about two person-months, not a small change.

Reframe the question. The board is not deciding whether the change is small; it is deciding how to meet a regulatory obligation without unacceptable release risk. Present options with impact, risk and who owns the trade-off.

Options:

1. Include fully in release 1, descoping agreed release-1 scope. Most compliant, but the descoped items need sponsor sign-off and may carry their own commitments.
2. Include fully and move the test start or go-live. Highest confidence, but regulatory date is fixed, so this may not be available.
3. Partial delivery: field and validation in release 1, verification workflow and backfill in release 2, with a manual control in the interim. Viable only if the regulator accepts the interim control - confirm, do not assume.
4. Defer to release 2. Five months late against the effective date; likely non-compliant unless the effective date is later than stated or there is a transition period.

Recommendation: option 1 or 3, depending on the confirmation from Compliance about what the rule requires and on whether a descope candidate exists. State the conditions plainly, name the critical path (interface changes and test re-freeze), and ask the sponsor to accept the specific descope if that is the chosen route. Record the decision, rationale and residual risk in the change record. Do not return an answer of "small" - 45 person-days across three interfaces at week 30 is a schedule event.

Immediate actions:

• Recover the spreadsheet, check it into the repository, and record its provenance as unverified until checked.
• Import the links, but mark them as unconfirmed. Do not present a restored matrix as trustworthy.
• Prioritise back-filling for release-1 requirements, regulatory requirements and the three affected interfaces - not all 312.
• Back-fill using test cases and interface specifications, which often reveal links that were never recorded.
• Assign an owner to every requirement, including the previously orphaned ones.

Do this in parallel with the change assessment; do not block the change board on a 100% matrix.

Prevention:

• Define done for a requirement to include owner, source, rationale, priority and at least one trace link.
• Make the repository the single source of truth; ban offline spreadsheets for traceability, or require them to be imported weekly.
• Add traceability coverage to the weekly status pack, so gaps surface early.
• Include a knowledge-transfer and handover obligation in contractor exits, and keep a named internal owner for every artefact.
• Check traceability at each baseline and before test freeze as an exit criterion.