Three Traceability Anomalies at Month Nine

Triage by exposure, not by size.

1. The 22 changes with no CCB minutes - first. This is not a documentation gap; it is an unknown scope and cost position. Each item has been built or planned without an approved decision record, so the baseline no longer describes the product, effort may be unbudgeted, and in an ERP rollout it is an audit exposure. Start by reconstituting what each change is, who requested it, and what it cost - then present for retrospective ratification or rejection at the next CCB. Do not retroactively write minutes that imply a decision that was never made; document that the change bypassed control and record the ratification date.

2. The 91 untraced requirements - second, because UAT is running. You cannot currently demonstrate coverage for 15% of the baseline, and untested requirements become production defects. Triage fast: are they covered by tests linked to a parent requirement, or genuinely untested? Escalate the genuinely untested to the test lead this week.

3. The 37 orphan test cases - third, but not ignored. These are either undocumented scope (gold-plating or a missed requirement) or mislabeled links. Chasing them is cheap if done in bulk by reviewing the tests against design documents.

Also snapshot the traceability matrix now so the investigation does not lose its evidence base while work continues.

Treat it as a change request regardless of who agreed to what, and regardless of the director's seniority. A hallway conversation with the sponsor's deputy is not an approved requirement - the program has a CCB for exactly this, and the fact that this pattern already produced 22 unapproved changes is the reason to hold the line politely.

Do the work rather than the refusal:

• Log the three reports as a change request with the director as requester and the hallway conversation noted as an informal input, not as authorization.
• Perform impact analysis now: effort estimate, data sources, whether the ERP standard reporting layer can deliver them, effect on UAT scope and the go-live date, and traceability to business objectives.
• Ask the director one question that resolves most cases: does this need to be in the current release, or in the first post-go-live increment? Reports are frequently satisfied by the standard reporting package or a later release.
• Bring the assessment to the CCB in eleven days - that is within a normal decision cycle, so the elapsed time is not a reason to bypass control.

Escalation caveat: if the reports are genuinely tied to a regulatory or audit obligation, say so explicitly in the impact analysis and let the CCB fast-track it. The BA's job is to make the decision cheap and informed, not to be a gatekeeper for its own sake.

Read the pattern as a control failure, not a testing problem. Defects tracing to requirements marked "deferred" at month six mean the deferral decision never reached the people building and testing. Three plausible causes, and they have different fixes:

1. Deferral not propagated. The baseline was updated at the requirements level but not communicated to development or test. Fix: reconcile the deferred list against the build and test plans, and confirm with dev and test leads which deferred items are actually in the build.
2. Stale links. The defect is correctly logged, but the traceability link points to a superseded requirement version. Fix: check versioning on those 27 links before concluding anything - otherwise you will raise a false alarm with the CCB.
3. Unilateral deferral. Someone deferred requirements without CCB authority, and the build proceeded anyway. Fix: this belongs in the same governance conversation as the 22 unminuted changes.

Communicate with the data, not the complaint: bring the CCB the 27 defects, their requirement IDs, deferral dates, and who recorded each deferral. That converts an 18% statistic into a specific list of decisions to ratify or reverse.

Then repair the mechanism: every deferral decision should generate a traceability status change visible to dev and test, and the deferral register should be reviewed at each CCB. Without that, this recurs at go-live when deferred scope appears as missing functionality.