Single Sign-Off by Week 6 on a 14-Month Regulatory Program
You are the lead business analyst on a 14-month program to deliver consolidated risk reporting for a mid-sized bank, with a fixed regulatory submission date. Four business units - retail, corporate, treasury and wealth - each nominate a reporting coordinator, but none has a dedicated SME. Coordinators commit to four hours per week; two sit in UTC+8 while the program team works UTC-1. A previous attempt two years ago slipped nine months: scope was agreed verbally in meetings, change requests were handled by email, and no one owned the backlog. The sponsor now wants a single requirements document signed off by all four units by week 6. You have two other BAs, one of them junior, and a fortnightly governance forum. A vendor has already been selected and contracted, and its BA is pressing to begin configuration in week 10 based on the vendor's standard process model.
1. The sponsor wants one requirements document signed off by all four business units by week 6. Assess this planning decision and describe what the business analysis approach should contain to make approval achievable and meaningful.
Read the worked answer
The intent is right, the mechanism is risky. The sponsor is trying to prevent a repeat of verbal scope agreement, which is a legitimate planning concern. But a single document approved jointly by four units creates mutual blocking and hides which unit is actually ready.
Capacity check. Four coordinators at four hours a week gives roughly 16 review hours per week in total, minus their day jobs. Six weeks is about 96 hours across all four units - enough to agree scope, reporting definitions and data sources, not enough to review detailed functional specifications for four report families.
What the approach should contain:
- A requirements architecture: one shared core (glossary, data definitions, non-functional requirements, cross-unit reconciliation rules) plus unit-specific sections, so units are not waiting on each other.
- Decision rights: named approver per unit, with a delegated authority threshold, and an escalation route to the sponsor through the fortnightly forum.
- A staged approval: scope and reporting definitions by week 3, unit-level requirements weeks 5–7, consolidated baseline endorsed by the sponsor. This meets the sponsor's real need - a controlled baseline - without pretending all detail is settled by week 6.
- A defined meaning of "approved": reviewed, acceptance criteria present, source and owner recorded, open issues logged.
Flag to the sponsor that two units in UTC+8 will need asynchronous review time built in, and that a 4-hour-per-week coordinator is a reviewer, not an SME.
2. Design the elicitation and collaboration approach given four hours per week per coordinator, a nine-hour time-zone spread, and vendor pressure for a week-10 configuration start. Justify each choice.
Read the worked answer
Separate elicitation from review. These consume the same scarce coordinator hours, so the plan must minimize synchronous time and make the rest count.
Techniques and rationale:
- Document and data analysis first. Existing report packs, regulatory templates, reconciliation spreadsheets and data dictionaries tell you what is produced today. This reduces the questions you need to ask and gives you a straw man to react to.
- Short structured sessions, not workshops. 60–90 minute sessions per unit in the overlapping window (roughly 13:00–16:00 UTC), one unit per session, with a pre-read and a template completed beforehand. Four-hour weeks cannot absorb three-hour workshops.
- Asynchronous walkthroughs. Recorded screen walkthroughs of current report production, reviewed by you and confirmed in writing, let the UTC+8 coordinators contribute outside the overlap.
- Named SMEs for short bursts. Coordinators are reviewers, not the source of calculation logic. Request two named SMEs per unit for a two-week window each, and put that request to the sponsor in writing.
Handling the vendor. Treat the vendor's standard process model as a hypothesis to be tested, not a requirements baseline. Commit only to a process-confirmation milestone before week 10 and stage configuration behind validated requirements. If the vendor will not stage, escalate the schedule conflict to the sponsor now rather than at week 9.
3. Which performance measures would you use to monitor the business analysis work, and how would you respond when the vendor's BA reports at week 8 that 'requirements are 90% complete'?
Read the worked answer
Choose measures that show quality and readiness, not just activity:
- Requirements by state (drafted, reviewed, approved) per unit, shown as a burn-up.
- Coverage of the cross-unit shared core: glossary terms, calculation rules, data-source mappings.
- Percentage of requirements with a named owner, source and acceptance criteria.
- Open decisions and issues, with age and owner - the previous failure was untracked verbal scope.
- Review turnaround against the four-hour commitment; if coordinators are not reviewing, the plan is failing early and visibly.
- Post-baseline change volume by source, as a leading indicator of weak elicitation.
On '90% complete': ask for the basis. Percentage by count is misleading when the remaining 10% may be the reconciliation rules and non-functional requirements that carry most of the risk - and those likely sit across units, not inside one.
Reframe completion as a definition: a requirement is complete when it is reviewed by its owner, has acceptance criteria and traceability to a report output, and has no open decision attached. Then plot progress against that definition. If the vendor's figure counts drafted items, the true readiness may be nearer 50–60%. Put the agreed definition into the fortnightly governance pack so the metric is not renegotiated each cycle.