The Baseline That Kept Moving
A payroll modernization program has 214 approved requirements baselined six weeks ago. Since then, 47 change requests have been logged. The change control board meets weekly and has approved 31, rejected 9, and left 7 pending. The project manager has begun telling stakeholders that the pending 7 are 'effectively approved' and has instructed developers to start on them to protect the schedule. A senior business analyst notices that 12 of the 31 approved changes touch the same tax-calculation module, and that two approved changes contradict each other on rounding rules. The compliance officer has not been consulted on any change affecting tax output. Traceability links exist for only 60 percent of baselined requirements, and the requirements management tool and the test management tool are not integrated.
1. Assess the requirements life cycle management failures in this situation and recommend the corrective actions the business analyst should take first.
Read the worked answer
What is actually failing
The core failure is that the change control process has authority on paper but not in practice. The project manager's decision to treat pending items as approved and to start work on them bypasses the board entirely; that is not a schedule tactic, it is a governance breach that converts unapproved scope into sunk cost the board cannot later reject without political cost. This is the single most urgent issue.
The second failure is analytical rather than procedural. Twelve approved changes hitting one module, with two contradicting each other on rounding, signals that change requests are being assessed individually with no impact analysis across the change backlog. Approving each in isolation produced a set that is internally inconsistent. Rounding in tax calculation is not a cosmetic detail; it changes liabilities and audit outcomes.
The third failure is stakeholder coverage. The compliance officer is a mandatory stakeholder for any change affecting tax output, and their absence means approvals were made without the authority who owns the regulatory risk. A change board that approves tax logic without compliance input is producing decisions that can be reversed by auditors later.
The fourth is traceability. Sixty percent coverage means roughly 86 baselined requirements have no verified link to design or test artifacts, so impact analysis for future changes is guesswork, and the unintegrated tools guarantee links will drift.
Corrective actions, in order
- Escalate the pending-change work start immediately, in writing, to the sponsor and the board chair. Frame it as a decision the board must ratify or reverse, not as an accusation.
- Freeze the tax-calculation module pending a consolidated impact review of all 12 changes, resolving the rounding conflict explicitly.
- Reinstate compliance officer review as a mandatory gate for tax-affecting changes, and re-open the affected approvals for that review.
- Complete traceability for the 86 unlinked requirements before accepting further changes, prioritizing those feeding tax and reporting.
- Establish cross-change impact analysis as standard practice: any change request must be assessed against other open and recently approved changes, not just the baseline.
- Integrate or automate the link between requirements and test tools so traceability is maintained rather than reconstructed.
2. The sponsor asks whether the 7 pending changes should simply be approved in bulk to clear the backlog. How should the business analyst respond?
Read the worked answer
The business analyst should resist bulk approval, but not by refusing to decide. The right answer is a triage with a defensible criterion.
Bulk approval is unsafe here for a specific, evidenced reason: the pattern in this backlog shows that individual assessment is already producing conflicts. Seven items assessed as a batch, under schedule pressure, would very likely reproduce the rounding-type contradiction. The board's value is not throughput; it is the cross-check that catches interactions.
A better response is to propose a two-track disposition. First, ask the board to classify the 7 by risk: changes with no effect on tax logic, external interfaces, or regulatory reporting can be fast-tracked with a light review, because their blast radius is small. Second, changes touching tax calculation, statutory reporting, or anything the compliance officer owns must go through the full assessment including compliance sign-off, and the board should accept that these will take longer.
The business analyst should also quantify the cost of delay honestly rather than using process as a shield. If two of the seven are genuinely blocking development, the analyst can recommend conditional approval: approved in principle, with implementation gated on completion of the compliance review and the conflict check. That preserves momentum without converting unassessed scope into committed work.
Finally, the analyst should address the root cause. Forty-seven change requests in six weeks against a 214-requirement baseline is a rate that suggests either the baseline was captured at the wrong level of detail or upstream requirements were incomplete. The analyst should propose a short retrospective on why so many changes are arriving, because a faster board will not fix a baseline that keeps moving.