The Fixed Deadline and the Missing SME
You are the business analyst on a regulatory reporting change at a mid-sized insurer. The compliance deadline is fixed at 14 weeks and the sponsor is the CFO. IT has committed six developers for the first eight weeks only. Two weeks ago you issued a business analysis approach built around weekly 90-minute requirements workshops with 11 named stakeholders. Attendance has averaged four. The operations SME, the only person who understands the 30 exception codes the report must handle, has declined every session, saying her team is in peak season until week 9. The project manager has begun escalating your slowness and wants developers to start building screens from the draft requirements. Nothing is baselined. The steering committee meets in five days.
1. What should you revise in the business analysis approach and stakeholder engagement plan, and on what evidence?
Read the worked answer
The approach is a living plan, not a contract. The evidence is concrete: 4 of 11 stakeholders attending, the only source for 30 exception codes unavailable until week 9, developer capacity starting in week 8, and nothing baselined. Those are invalidated planning assumptions, so the right move is to revise the plan and document why, not to defend the original design.
Revisions to make:
- Elicitation technique mix. Stop depending on one channel. Use document analysis of the exception-code specification immediately, observe exception handling at the desk, and book a structured 60-minute interview with the SME in week 9. In the meantime send her a short, numbered question list for asynchronous written response.
- Stakeholder engagement approach. Re-run the stakeholder analysis on influence, interest and availability. The SME is high influence, high interest, low availability, so her engagement approach becomes scheduled written review plus a named delegate from her team, not a recurring meeting.
- Information management. Keep every requirement explicitly marked draft and versioned. Do not let draft artefacts acquire the appearance of approval.
- Governance. Bring a documented decision request to the week-5 steering committee rather than absorbing the gap silently.
Record the rationale so the change reads as a managed replan, not drift.
2. The project manager wants developers to start building screens. How should you respond, and through what governance?
Read the worked answer
Separate the real risk (idle developers against a hard date) from the proposed response (build from unbaselined drafts). You can support the first without accepting the second.
- Identify the low-regret subset. Some requirements are stable regardless of the open questions: report layout, headers, the five exception codes already understood. Release that subset as an explicitly provisional baseline with a named change route and a time box.
- Keep the rest draft. Do not relabel drafts as approved to relieve schedule pressure; that transfers risk from the schedule to compliance.
- Put the trade-off to the steering committee as options with consequences:
- Start on the stable subset now and accept rework risk on the remainder.
- Wait for SME input in week 9 and accept schedule compression.
- Fund a temporary backfill so the SME's team can release her earlier.
- Record the decision, its owner and its acceptance of risk. Risk acceptance belongs with the sponsor and steering committee, not with the BA or the project manager acting alone. That is what the business analysis governance plan is for.
3. Which performance measures would tell you whether the revised approach is working?
Read the worked answer
Choose measures tied to the specific risks in this plan rather than generic productivity counts:
- Stakeholder response rate and turnaround on written reviews, by stakeholder, tracked weekly.
- Percentage of requirements with an identified source and owner (target trending to 100% before provisional baseline).
- Number of requirements changed after provisional baseline, which tests whether the low-regret subset was genuinely low-regret.
- Age of open questions, flagging anything blocking a developer.
- Exception-code coverage: codes specified and validated out of 30. This is the single measure that most directly tracks the compliance risk.
- Rework traced back to requirements, in defects or rework hours.
Review these at each steering committee and be prepared to change technique again if response rates stay low. Measuring the plan and then ignoring the results is the failure the exam is testing against.