On Monday morning, the BA calendar looked harmless from far away: three interviews, one workshop, one backlog refinement, and a review with operations. Up close, it told a different story. The same problem had five versions, each shaped by a different stakeholder's daily pressure.
That is why BA planning is not admin work. It is the way a team decides where to spend attention, whose reality must be understood, and what evidence is needed before requirements become expensive.
Source note: This series is based on a local Markdown guide about Lean Business Analysis, which synthesizes ideas from Emrah Yayici, PMI, and Business Analysis For Dummies. I am treating it as working material, not as a replacement for the original books.
Planning BA Means Planning Attention
A project plan tells the team how delivery work may unfold. A BA plan tells the team how understanding will unfold. The two are connected, but they are not the same. A delivery plan can say "build onboarding flow in Sprint 3." A BA plan asks who understands onboarding today, which assumptions are still weak, what decisions depend on those assumptions, and when the team must know enough to move.
The material frames BA planning around practical questions: how requirements will be elicited, analyzed, documented, prioritized, verified, validated, traced, and changed. In a small team, this may fit in one page. In a regulated or multi-vendor environment, it may need more ceremony. The point is proportionality.
One simple planning artifact is a BA working plan:
| Question | Planning answer |
|---|---|
| What do we need to learn? | Current process, pain points, decision rules, data ownership, nonfunctional constraints |
| Who can teach us? | Users, managers, operations, support, compliance, engineering, downstream teams |
| How will we learn? | Observation, interviews, workshops, document analysis, prototype review |
| When is enough enough? | When major risks are named, options are comparable, and the next delivery slice is clear |
Stakeholders Are Not Just Names on a List
A stakeholder register is useful only if it captures more than contact details. A good BA wants to understand attitude, influence, expertise, availability, location, complexity, decision rights, and the kind of evidence each stakeholder trusts.
For example, in a claims-processing project, the head of operations may care about throughput, frontline agents may care about fewer screens and less rework, compliance may care about auditability, finance may care about leakage, and engineering may care about integration limits. If the BA treats these as one generic group called "business users," the requirements will look tidy and fail quietly.
A RACI matrix can help, but it should not become decoration. Use it to clarify who is responsible for giving input, who approves business rules, who must be consulted on trade-offs, and who only needs updates. The hidden value is not the table itself. The value is the awkward conversation it forces before the project is under pressure.
Predictive and Adaptive Work Need Different BA Rhythms
Lean BA does not require every project to be Agile. Some work needs more upfront analysis because the cost of change is high, the process is regulated, or many external parties must coordinate. Other work benefits from short learning cycles because the solution is uncertain and user feedback matters more than early completeness.
| Context | BA rhythm | Common artifact |
|---|---|---|
| Predictive project | More upfront elicitation and baseline approval | BRD, requirements package, traceability matrix |
| Adaptive product work | Progressive elaboration before each slice | User stories, examples, prototypes, acceptance criteria |
| Hybrid program | Stable business outcomes, adaptive solution detail | Roadmap, capability map, evolving backlog |
The mistake is pretending one rhythm fits all. A team building a banking regulatory report may need clearer traceability and approval than a team testing a new onboarding experiment. But both teams still need the same discipline: understand enough, decide honestly, and keep learning visible.
Elicitation Is Not Taking Orders
The file makes a useful distinction between gathering and eliciting. Gathering sounds like requirements already exist somewhere and the BA only needs to collect them. Elicitation assumes the truth is distributed, partial, sometimes contradictory, and often tacit.
Good elicitation therefore starts before the interview. The BA decides the objective, target stakeholders, sequence, questions, artifacts to review, and output format. A workshop without a clear decision can generate noise. An interview without context can become a complaint session. A survey sent too early can freeze shallow assumptions into numbers.
Question design matters. Open questions uncover context: "Walk me through the last time this failed." Closed questions confirm facts: "Does every refund above 500 dollars require manager approval?" Context-free questions reduce solution bias: "What would make this process unacceptable even if the screen were faster?" Careful why questions expose causes, but careless why questions can make people defend themselves.
Choose Techniques by What You Need to Learn
No elicitation technique is automatically mature. The technique should match the uncertainty.
- Use document analysis when existing policies, contracts, reports, or procedures shape the work.
- Use observation when people cannot easily explain what they do because the work is habitual.
- Use interviews when you need depth, nuance, or sensitive context.
- Use workshops when decisions cross roles and the disagreement must be surfaced together.
- Use surveys when you need breadth after the topic is already clear enough.
- Use prototypes when people need to react to something visible before they can explain what is missing.
- Use interface analysis when data crosses system boundaries and assumptions hide in handoffs.
A practical example: if a warehouse team asks for "fewer clicks," observation may reveal that the bigger problem is not click count but walking distance, scanner latency, and exception handling. A prototype alone would miss that. If compliance asks for "full audit trail," document analysis and rule workshops may matter more than user interviews.
A Small Operating Rhythm
For many teams, a lightweight BA cadence is enough:
- Map stakeholders and name the decisions they own.
- Run the smallest elicitation that can reduce the next risk.
- Turn findings into models, examples, or stories quickly.
- Review with the people who will use, approve, build, test, and operate the change.
- Keep assumptions visible until they are proven or deliberately accepted.
Planning does not remove uncertainty. It helps the team meet uncertainty in a better order.