Planning
Planning covers how the business analysis work will be done. The exam tests your ability to tailor a business analysis approach, plan stakeholder engagement, set governance and decision rights, and define how requirements will be elicited, documented, prioritized, approved, and changed.
Core rules
- The business analysis plan states scope, deliverables, techniques, schedule, roles, communication, and risk. It is living and revised as understanding grows.
- Stakeholder analysis is continuous: map power, interest, influence, attitude, and impact, then choose engagement tactics per group.
- Define the requirements lifecycle before elicitation: how requirements are captured, reviewed, baselined, approved, and retired.
- Set decision rules: who can approve, what counts as sign-off, how conflicts escalate, and which changes need a formal request.
- Choose prioritization and traceability approaches in planning, not after requirements arrive.
- Plan for information management: repository structure, naming, version control, access, and reuse.
Worked example
A bank is replacing loan origination. The BA plans mixed elicitation: workshops for credit policy, observation for branch processing, and a survey of 400 brokers. Stakeholder mapping shows credit risk has high power and low interest, so the BA schedules short weekly decision reviews; branch staff have high interest and low power, so they get prototypes and feedback sessions. The plan defines approved as product owner plus risk lead sign-off, sets a change threshold of 10 percent effort, and stores requirements in a tool with version history. The reasoning: technique and governance follow stakeholder risk and requirement volatility, not habit.
Traps
Writing a plan once and never revising it, using one elicitation technique for every group, leaving sign-off undefined, and treating all changes as equal.