A Carried-Over BA Approach That Cannot Fit the Calendar
Northwind's regulatory reporting program has a fixed compliance deadline nine months out: six business units across three countries, fourteen SMEs, and an external vendor building the calculation engine. The BA approach template carried over from a prior project mandates full-dress use cases for every requirement, 100% sign-off by all SMEs, and weekly two-hour workshops. Three SMEs sit nine time zones away. All SMEs are unavailable for five business days each month during financial close. Historical approval turnaround averages eleven days. The BA effort budget is 400 hours. The vendor has asked for requirements frozen by month two so it can begin configuration.
1. Test the mandated approach for feasibility before adopting it. What does the arithmetic tell you, and what do you change?
Read the worked answer
Feasibility arithmetic first: fourteen SMEs × 2 hours × 4 weeks = 112 hours of workshop time per month, before preparation, documentation, or review. Against a total BA budget of 400 hours across nine months (~44 hours/month), the mandated approach consumes more than twice the entire budget in workshops alone. It is not a matter of discipline; it is arithmetically impossible.
Apply tailoring with rationale, documented in the BA plan:
- Replace plenary workshops with targeted sessions. Group SMEs by domain so each requirement is elicited from the 3–4 people who own it, not all fourteen. Record sessions and circulate asynchronously for those in distant time zones.
- Schedule around close. Publish a calendar with the five unavailable days per month blocked and set elicitation windows in the remaining weeks. Do not attempt to negotiate SME availability during close; it will fail and damage credibility.
- Select models by requirement type. Calculation and eligibility logic are better captured as decision tables and a rule catalog than as full-dress use cases; use cases are justified only for the interactive workflows where actor–system dialogue matters. This is tailoring to content, not cutting corners.
- Split sign-off. See the approval question below.
Record the tailoring rationale (constraint → change → risk accepted) so the deviation is governed rather than looking like the BA skipped steps.
2. Given an eleven-day average approval turnaround and non-overlapping availability, how should you define "approved" so the plan is achievable without weakening control?
Read the worked answer
Diagnose before redesigning. Eleven days average means approvals are serialized through fourteen people. The fix is not a shorter deadline; it is fewer, accountable approvers per artifact.
Define approval by decision rights, not headcount:
- Build an approval matrix at requirement-domain level. Each domain has one accountable approver plus named reviewers. Reviewers have a fixed review window (e.g., 3 business days) and silence is not consent - but a missed window escalates to the accountable approver, who decides.
- Tier by risk. Regulatory-mandated requirements get full accountable-approver sign-off and compliance review. Low-risk display and reporting requirements use delegated approval. This concentrates the scarce approval cycles where the audit exposure is.
- Publish a decision SLA and an escalation path with the program manager, agreed in the plan, so slippage is visible as a schedule risk rather than absorbed silently by the BA.
- Batch approvals into defined review cycles (e.g., biweekly) so approvers plan for them instead of being asked ad hoc.
Key point: "100% sign-off by all SMEs" is a control that produces delay without producing accountability - no single person is answerable. The risk-based matrix is stricter in substance and executable in the calendar.
3. The vendor demands all requirements frozen by month two. How do you respond, and how does that shape the planning artifacts?
Read the worked answer
Recognize what the freeze request actually is: a vendor risk-management position against rework, not a statement about what the business can know by month two. With three countries and a regulatory deadline, some rules will not be settled by month two - the compliance rules in particular may depend on pending interpretation.
Respond with staged baselining rather than a single freeze:
- Freeze now (month 2): the calculation engine's interfaces, data contracts, and the rule catalog for rules already confirmed - this is what the vendor genuinely needs to start configuration.
- Baseline progressively: remaining rules move to a prioritized backlog with planned baseline dates in months 3–5, each with a defined impact-analysis path.
- Contract the change path: agree with the vendor and program manager what a post-freeze change costs (estimate, review, approval turnaround) so both sides have a predictable process.
Planning artifacts this affects: the BA plan needs a baselining schedule per requirement domain, not one milestone; the change control section must specify the impact-analysis turnaround the vendor can rely on; and the requirements management plan must state how the backlog is prioritized when the deadline compresses.
Escalate one thing: if the vendor's freeze is unconditional and the regulatory rules are unresolved, that is a program-level risk to raise with the sponsor, not something the BA absorbs.