Planning the Business Analysis Work
Planning the business analysis work
Planning answers four questions: what approach, who is involved, how requirements will be managed, and how decisions will be made. Know the components of a business analysis plan and a requirements management plan: BA approach (predictive versus adaptive/change-driven), elicitation plan, stakeholder analysis and engagement plan, communication plan, governance and decision rights, requirements attributes and traceability approach, prioritization scheme, approval and sign-off process, change control, tool selection, estimation, and measures of BA performance.
Stakeholder tools worth naming: power/interest grid, salience model, onion model, and RACI for decision roles. Risk planning covers elicitation risk, stakeholder availability, and requirements volatility.
Traps. Choosing an approach out of habit rather than from uncertainty, regulatory exposure, and stakeholder dispersion. Producing a project schedule and calling it a BA plan - the BA plan governs analysis work and information flow, not just tasks and resources. Omitting how requirements will be approved and changed, which is exactly where many stems land. Planning elicitation once and never revisiting it when the situation shifts.
Rule of thumb: the more volatile, uncertain, or regulated the environment, the more explicit and documented the plan must be; a co-located, low-risk team can plan lightly and iterate.
Worked example: a bank replacing a payments platform under a regulator's audit. Iterative delivery is attractive for speed, but the plan must still specify formal baselines, named approvers, a change control board, and a traceability repository, because auditability - not preference - drives formality.