Eighteen Changes and a Tax Rule
You are the business analyst on a nine-month payroll replacement. At month four, 120 requirements were baselined. In the last six weeks the change control log has recorded 18 requests, most from one region. Your traceability matrix links requirements only to test cases, not to business objectives, design components or data. A new tax rule takes effect next quarter and will affect the calculation of several allowance types. The project manager wants every open change deferred to phase 2 to protect the go-live date, arguing that a manual workaround will cover the tax rule. The sponsor has not been involved in any change decision.
1. How do you assess the impact of the tax rule change?
Read the worked answer
Run a structured change assessment rather than answering from the seat of your pants.
- Find what is affected through traceability and domain knowledge: allowance calculation requirements, tax reporting outputs, interfaces to finance, stored data, test cases, parallel-run scripts, training material.
- Classify the change. It is regulatory with an externally fixed date, unlike the other 17 requests. That classification changes the decision owner and the options available.
- Estimate impact on effort, schedule, data migration and testing, and state confidence in the estimate (the affected allowances may not all be known until the tax guidance is read carefully).
- Assess the proposed workaround honestly. A manual calculation carries error risk, audit findings, possible penalties, and an ongoing operational cost that the project budget does not show.
- Present the analysis, not just a verdict. Impact analysis feeds a decision; the BA's job is to make the consequences visible and traceable, then route it through change control.
2. Where does the traceability matrix fall short, and what relationships would you add?
Read the worked answer
A matrix that links requirements only to test cases answers one question: has this been built and tested? It cannot answer why the requirement exists, what else a change touches, or what is safe to drop. For this project the missing links matter directly, because the tax rule requires finding everything downstream of the allowance requirements.
Add, in priority order:
- Requirement to business objective or goal. This supports scope and priority decisions and exposes requirements with no rationale.
- Requirement to design component, so a change can be costed in build effort.
- Requirement to dependent requirement, which is how ripple effects appear.
- Requirement to source stakeholder, which supports confirmation and later change negotiation.
Do not build a full matrix across all 120 requirements by reflex. Prioritise the high-change, high-risk subset: the tax-related requirements and the ones behind the 18 requests. Keep attributes current: status, priority, owner, source, version.
3. The project manager wants all changes deferred to phase 2. How do you respond?
Read the worked answer
Deferral is a business risk decision, not a scheduling decision, and the sponsor has been absent from it. Your response:
- Separate the population. The tax rule cannot be treated like the other 17 requests. Present it as a distinct decision with options and consequences:
- implement in phase 1 and accept schedule or scope impact;
- manual workaround with documented error, audit and cost risk;
- partial automation of the highest-volume allowance types.
- Analyse the 18-request cluster before adopting a blanket policy. A concentration from one region can mean a legitimate local process variant, a missed stakeholder group, or a broken elicitation channel. A blanket deferral hides the cause and creates a phase 2 that is really a second phase 1.
- Escalate to the sponsor with the options, the risk each carries, and a recommended route, and record the decision in the change log with owner and date.
Saying no to every change is not change control; it is change avoidance.