ERP Traceability Under Audit Finding
An ERP upgrade has 1,200 requirements across three releases. Nine months in, there are 34 open change requests and an audit finding that change control is not operating effectively. Twenty-two percent of requirements have no downstream link to design or test, test coverage is 64%, and 41 changes were approved without recorded impact analysis, 12 of them classed as emergency. The offshore test team writes test cases from design documents rather than from requirements. Release 2 build starts in six weeks. The sponsor gives you one analyst at 0.4 FTE and no tool budget; the current repositories are Excel and Jira. The audit committee meets in eight weeks. Release 1 is already in production and has had three severity-one defects traced to missed requirements.
1. Produce a prioritized six-week plan to close the traceability gaps with 0.4 FTE and no tool budget.
Read the worked answer
Do not attempt to link all 1,200 requirements. With 0.4 FTE and six weeks, a completeness-first plan will fail and will miss the audit date. Use risk-based coverage.
Define the traceability model once: business need → requirement → design → test case → change request. Establish the baseline metrics: 22% unlinked, 64% test coverage. Then prioritize:
- Tier 1: Release 2 in-scope requirements, regulatory and financial requirements, and anything implicated in the three Release 1 severity-one defects. Target 100% linked.
- Tier 2: remaining Release 2 and high-risk Release 3 items. Target 80%.
- Tier 3: low-risk Release 3 and cosmetic items. Defer with a documented rationale.
Use Jira issue links for design and test where they already exist and one Excel matrix keyed by requirement ID for the rest; no new tool needed. Assign unique IDs, deduplicate, and map design documents and test cases. Give the offshore test lead the matrix and acceptance criteria, and require new test cases to reference a requirement ID. Report coverage weekly by tier. For the 41 changes lacking impact analysis, reconstruct impact records only for the high-risk ones.
2. How would you redesign change control for the 34 open change requests before Release 2 build?
Read the worked answer
Start with triage, not a new form. Classify the 34 by risk, type, age, release, and whether they are regulatory, financial, or cosmetic. Define emergency criteria narrowly - for example, production outage, regulatory breach, or security exposure - and require retroactive impact analysis and approval within five business days. The 12 past emergency changes should be reviewed against those criteria to test whether the label was used correctly.
For each open request, perform impact analysis across requirements, design, test, data migration, training, cost, and schedule, and record it in the change log. The CCB needs decision thresholds: which changes the product owner can approve, which need the sponsor, and which need architecture or compliance review. Batch low-risk, same-area changes to reduce meeting load.
Set a Release 2 scope freeze at week 3, with post-freeze changes deferred to Release 3 unless they meet the emergency criteria. Update the baseline and the traceability matrix when a change is approved; a change that does not update traceability will recreate the audit finding. Keep an evidence log for the audit committee: request, impact, decision, approver, date, and implementation status.
3. What metrics and reporting would you give the sponsor and audit committee?
Read the worked answer
Report a small set of measures that show both coverage and control effectiveness, with baselines and trends rather than a single green/red status.
- Traceability: percentage of in-scope requirements with complete downstream links, by risk tier. Baseline 78%; target 100% for Tier 1.
- Test coverage: percentage of in-scope requirements with at least one mapped test case, by tier. Baseline 64%.
- Change control: open change requests by age and risk, percentage with documented impact analysis, and emergency changes versus criteria. Baseline: 41 without impact analysis.
- Quality outcome: defects traced to missing or misunderstood requirements, building on the three Release 1 severity-one defects.
- Scope stability: requirements added, removed, or changed against the baseline.
Include leading indicators - review completion, link closure rate, CCB cycle time - because lagging defect counts will not move before the audit. Present decisions needed, not just data: approve the risk-based coverage approach, confirm the Release 2 freeze date, and endorse the emergency-change criteria. A one-page dashboard with an appendix of exceptions is more credible than an exhaustive report, and it gives the audit committee evidence that the process is operating, not just documented.