LEARN. PRACTICE. GROW.Start with the question that needs an answer
Before scheduling a meeting, state which decision elicitation should inform. In a fictional funds-instruction service, “modernize the portal” is a proposed solution; understanding why some requests move to the next day is a problem to investigate. Define initial scope, relevant events, who experiences the impact and missing information. A useful session objective is clarifying where time is lost between receipt, checking and submission, including exceptions. Avoid starting with a closed feature list that forces participants to justify a predetermined solution. Elicitation can confirm a hypothesis, challenge it or reveal that the question was framed incorrectly. Record this uncertainty in the plan instead of hiding it from participants and decision makers.
Represent work and conditions, not just titles
A list of directors does not automatically represent those who operate, support, receive or retire the service. Map perspectives across the life cycle and conditions under which work changes. Day and night operations may use different teams, access and procedures. A supplier may understand the interface but not the client process after a rejection. Security and FinOps can introduce constraints that emerge only when discussing data, volumes and retention. The participant matrix should connect each perspective to relevant questions and conditions. Do not measure representation through attendance counts: ten people from one function do not replace a missing critical perspective. Revisit the matrix as scope and knowledge evolve, recording which assumptions still lack direct input.
Choose techniques for the information needed
Observation helps reveal tacit steps, waiting and workarounds absent from written procedures, but one execution does not represent every day. Interviews support exploration of reasoning, examples and topics difficult to discuss in groups. Workshops help compare perspectives and make prepared decisions; they should not presume agreement from absent people. Documents and logs can provide context when their version, scope and limitations are understood. A questionnaire reaches more people, but vague or biased questions merely multiply hard-to-interpret responses. Combine techniques when the decision needs different kinds of evidence. Plan authorization, protection of observed data and a way to confirm interpretations with people who understand the work. Select a method for its information value rather than its familiarity.
Prepare neutral questions and room for disagreement
“Automation will solve the delays, correct?” invites confirmation of a solution. “Describe the last request that moved to the next day: what happened at each stage?” supports discovery of causes and exceptions. Use open questions to explore and specific questions to confirm terms, boundaries and conditions. Ask for examples contradicting the usual rule, not just successful cases. In groups with strong hierarchy, prior individual input and contribution rounds can reveal concerns that would otherwise remain unspoken. Do not promise anonymity unless the process provides it. For international teams, share context and terms beforehand, allow asynchronous confirmation and check translated meaning. Fluency or speed of response does not determine a need’s importance.
Prepare the workshop and identify missing input
Read the six exercise notes below before consulting the sample analysis. N1 discusses accepting requests until 17:00; N2 describes an internal practice at 16:45. We do not yet know whether accept means the same event, or the calendar and external commitment involved. N3 proposes complete payloads to address missing correlation; N4 reports a classification constraint. N5 represents a night-shift assumption and N6 identifies missing cost data. Plan three elicitation actions, explaining participants, technique and expected information. A strong response exposes gaps without inventing an approved requirement. These fictional notes did not come from actual interviews. The provided analysis is one reasoned possibility rather than proof of consensus among real participants.
Workshop: notes and tasks
A fictional organization prepares a change to a funds-instruction service. The six notes were authored for this exercise, not collected from actual people or systems. External deadline, calendar, volumes and decision makers still need confirmation. N1 | Business owner | Instruction intake on a normal business day We need to accept requests until 17:00. I want to understand why some reach the next day’s processing. N2 | Day operator | Manual preparation before partner submission I usually stop accepting changes at 16:45 to finish checks. I do not know whether fifteen minutes are always needed. N3 | Support analyst | Diagnosing a rejection We need to store the complete payload because today we cannot relate the rejection to the original request. N4 | Security specialist | Operational logs accessed by support The internal classification in this example does not permit sensitive content in those logs. We have not yet defined the fields needed for diagnosis. N5 | Day coordinator | Answering on behalf of the night shift The night shift should be able to use the same procedure. I have not yet spoken to the team receiving the service at 22:00. N6 | FinOps | Observability and retention cost We need volume and retention estimates before comparing logging options. We have not received that information. T1: Classify N1–N6 as a statement, proposed solution, reported constraint, assumption or gap. What validation is missing in each case? T2: Propose three priority elicitation actions and explain who should participate and what each technique can reveal.
Workshop: sample analysis
T1: N1 and N2 are statements requiring context and clarification of accept. N3 proposes a solution to the correlation need. N4 reports a constraint whose source and scope need confirmation with the competent function. N5 is an assumption without night-shift participation. N6 identifies missing information. No note is, by itself, an approved requirement. T2: Observe an authorized, realistic intake-to-processing handoff and interview the operator about exceptions. Obtain the night-shift perspective at a suitable time or asynchronously followed by confirmation. Bring support, security and FinOps together after preparing rejection examples and necessary fields. The combination supports observation, a missing context and option comparison under constraints; there is no universal order independent of risk and availability. The sample analysis is one reasoned possible response. It establishes neither consensus, complete representation, facilitation effectiveness nor actual stakeholder approval. Times and constraints are fictional.
Instead of interviewing only the day manager, plan authorized processing observation and specific elicitation with the night shift. Confirm steps and exceptions before turning observed practice into a future rule.
Common pitfalls
Choosing participants only by hierarchy; confusing attendance with coverage; treating one observation as universal proof; leading toward a solution; interpreting silence as agreement.
Related topics: Stakeholder identification · Solution scope · Analysis planning
An elicitation plan explains the decision to inform, missing perspectives and why each technique fits. Keep limitations explicit.
Reference: PMI-PBA Examination Content Outline · Five-domain ECO / verified 2026-10-01