LEARN. PRACTICE. GROW.1. Select participants for the information needed
In a fictional project, the sponsor requests a new application because fund closing finishes late. Before preparing interviews, frame questions about outcomes, waiting points and decisions the project should support. Include batch operators, exception handlers, result recipients and rule approvers, identifying different shifts and geographies. A workshop full of managers may omit the only operator who knows a night-shift workaround. Link each participant to required knowledge or authority. Confirm availability, preparation material and how to collect information from absent people. The aim is not to interview the entire organization but to cover perspectives that could change understanding of the need. Record gaps so participation volume is not mistaken for information coverage.
2. Ask about events and exceptions
Instead of asking “do you agree automation fixes the delay?”, request a walkthrough of a recent normal run and a problematic run. Identify inputs, sequence, waits, manual decisions and completion criteria. Use synthetic examples or authorized, minimized data. If someone says “the file always arrives at six”, ask about timezone, business date, holiday rules and exception evidence. Do not turn the first response into a universal rule. Interviews reveal intentions and interpretations; observation and records can reveal differences between described and performed processes. Combine techniques according to the uncertainty without treating logs as complete proof: events may be missing, clocks may differ or work may occur outside the system.
3. Preserve versions of understanding
An interview note can contain three different things: what was observed, a proposed explanation and a decision still needed. Record them separately with source and scope. “The file arrived at 06:10 UTC” is an observation; “the supplier caused the delay” is a hypothesis depending on other stages; “accept until 06:15” is a rule requiring authority. Return the understanding to participants using examples and explicit questions. Confirmation that notes represent the conversation does not equal requirement approval, option funding or production acceptance. If a later correction occurs, preserve the earlier version and reason for change so consumers can identify which conclusion changed. Keep unresolved questions visible rather than silently merging conflicting accounts.
4. Work through conflict without inventing consensus
Business wants files accepted until cutoff while operations needs validation time before an external transmission. The statements may refer to different events: arrival, validation or transmission. Model the sequence and identify each party’s constraint before choosing a time. Where disagreement is real, present options, consequences and decision authority. A majority vote does not replace an approval rule or an obligation applicable to the scenario. Nor is selecting the most senior opinion enough without recording risk and scope. The analyst can facilitate and recommend while distinguishing that contribution from the authorized owner’s decision. Record residual disagreement and actions needed to make the agreement executable, including communication to teams not represented in the meeting.
5. Measure reduction of uncertainty
After three workshops, the team has many pages but still lacks a rule for repeated files. Session count does not establish analysis readiness. Maintain open questions with impact, required evidence, owner and next decision. Use acceptance examples to check whether development, operations and business interpret the rule consistently. A guided demonstration may resolve ambiguity that another presentation cannot. Reassess the approach when relevant participants are absent, assumptions change or information does not support decisions. Report to the technical manager what is confirmed, what remains hypothetical and which gaps block change. The team can then choose further investigation, limit scope or defer a decision with an understanding of the impact.
Business says “accepted until 17:00”; APS says “validated by 16:55”. Identify events and dependencies before treating the times as merely competing opinions.
Common pitfalls
Confusing attendance with coverage, leading questions with discovery, note confirmation with approval and workshop count with readiness.
Related topics: Decisions, versions and dependencies · Model, verify and validate requirements · Measure outcomes and interpret evidence
Make the path from collected information to confirmed understanding and authorized decision visible.
Reference: The Business Analysis Standard · CBAP six-knowledge-area blueprint, May 2026 handbook