⏱️ 6 min reading time

Choosing the Right Elicitation Technique: Why It Matters More Than You Think

There is a well-documented pattern in requirements engineering that most experienced practitioners will recognize the moment they hear it and quietly wince. Research (2014) from the Universidad Politécnica de Madrid found that when an analyst faces an elicitation challenge, they tend to reach for the technique they know best, regardless of whether it is the most appropriate one for the situation. The confident facilitator defaults to workshops. The skilled interviewer schedules a one-to-one. Not because it is the right choice, but because it is the comfortable one.

We all do it. And it costs projects more than most people realize.

This post is a deep-dive to the BABOK Elicitation and Collaboration KA, task Prepare for Elicitation.

Elicitation Is a Planned Activity

When a business analyst joins a project, their first task is orientation: understanding the problem space, identifying stakeholders, mapping who holds what knowledge, and determining how to access it. Elicitation is the mechanism through which that knowledge is surfaced, and it is one of the most consequential activities a BA performs.

Yet in practice, elicitation is often treated as an ad-hoc series of activities. Someone books a meeting, talks to a few people, maybe runs a workshop. The process feels natural, even productive. But unplanned elicitation carries serious hidden costs.

When the wrong techniques are used, or when technique selection is simply never considered, the consequences compound. Critical information may go missing, leaving requirements incomplete and inconsistent. Without structured, purposeful sessions, alignment with stakeholders breaks down. Conversations chase symptoms rather than underlying needs, leading to overlooked requirements or uncontrolled additions, a scope creep. Informal ad-hoc talks tend to duplicate effort, lack focus, and require revalidation in later planned activities, which could have been avoided entirely. When a stakeholder is approached twice about the same issue, they begin to question our professionalism, complain about time being wasted, and trust quietly erodes.

Elicitation always happens. The question is whether it happens well.

The good news is that technique selection does not need to be rigid. You make the best decision you can with the information available at the start, and you adapt as new information emerges. What matters is that the selection is conscious, not accidental.

What to Consider When Selecting a Technique

Every business analysis framework is explicit on this point: techniques should be chosen intentionally, based on multiple factors. There are several dimensions worth examining.

Your stakeholders shape the choice significantly. Large, diverse groups require a different approach than small, homogenous groups. Political dynamics matter just as much as numbers. Senior executives should be approached first or given private sessions to secure their priorities before engaging subordinates. Ignoring hierarchy leads to overridden decisions or no-shows from key players.

Informal influencers who have the power to block progress should be included even when they are not domain experts. We need to keep them onside.

Sensitive topics such as budgets or territorial disputes belong in one-to-one interviews rather than group settings, where hidden agendas surface indirectly and require cross-validation across political lines.

Pairing hostile stakeholders in joint workshops risks derailing the session entirely; separate interviews are the safer choice.

Some stakeholders hold knowledge they cannot easily articulate. They know how to do something without being able to explain it. For these individuals, observation is far more revealing than any interview will be.

Organizational culture deserves more attention than it typically receives. Some organizations are hierarchical and require a more formal approach, while other organizations are flat, and the discipline in approaching stakeholders is less rigid. Organizations may resist being observed or are uncomfortable with collaborative workshops. Trust has to be built before certain techniques become viable.

The nature of the project is equally influential. Large, complex projects typically require a combination of techniques rather than a single approach. In high-risk or uncertain contexts, early prototyping and validation sessions are essential; lower-risk projects can rely more heavily on documentation review. Novel or greenfield projects benefit from scenarios, brainstorming, and observation to surface genuinely unknown needs, while enhancement projects are better served by reverse engineering existing systems alongside targeted interviews.

Development approach matters too: Agile environments favor just-in-time, collaborative techniques such as story writing workshops and scenario analysis, while waterfall delivery requires comprehensive upfront elicitation through formal, structured sessions. Safety-critical or regulated environments always warrant deeper, more structured methods regardless of methodology.

The type of knowledge you are trying to surface should drive the decision as much as anything else. Explicit knowledge, what stakeholders can readily tell you, is well served by interviews, surveys, and workshops. Tacit, procedural knowledge, how work actually gets done as opposed to how it is supposed to get done, requires observation or ethnography. Creative or innovative requirements call for brainstorming, focus groups, or design thinking approaches.

Resource constraints shape what is feasible before you even consider what is ideal. If key stakeholders are available only for brief, infrequent windows, lengthy observation sessions or iterative prototyping cycles become impractical regardless of their value. Tight analysis timelines may rule out techniques that require significant preparation or multiple rounds of engagement. Budget limitations affect how many sessions you can run, whether travel to observe users on-site is possible, and how much analyst time can be justified. Working within these boundaries is not a compromise; it is a realistic starting point for selecting techniques you can actually deliver.

Every elicitation technique comes with its own set of strengths and limitations. Mapping those characteristics against your project context, stakeholder availability, knowledge type, risk level, resource constraints, is one of the most reliable ways to arrive at the right choice. A technique that excels in one situation may be entirely inappropriate in another, and understanding both sides of that equation is what separates a deliberate selection from a default habit.

Define the Output Before You Choose the Technique

One factor that is frequently overlooked is the anticipated output. Before selecting a technique, be explicit about what you expect to walk away with. This single discipline prevents a surprisingly common mistake: using a divergent technique, such as brainstorming, when what you actually need is a convergent result, such as a prioritized list of requirements.

Knowing your intended output shapes everything downstream: the questions you prepare, the participants you invite, the materials you bring. And comparing what you planned to produce with what you actually produced is one of the most honest ways to evaluate whether a technique was the right choice.

Consider Combining Techniques

No single technique captures the full picture. The most reliable approach is to use techniques in combination, allowing each to validate or interrogate the others.

A practical example illustrates this well. If document analysis shows a process defined one way, and stakeholder interviews reveal it is being executed differently, the instinct might be to assume someone is wrong. The right move is to go and observe. The document tells you what was intended. The interview tells you something differs. Observation shows you what is actually happening and why, surfacing the discrepancy in a way that allows you to address it properly. Three techniques, three layers of insight, one complete picture.

The Professional Choice

Selecting elicitation techniques thoughtfully is not a bureaucratic exercise. It is the difference between requirements that reflect what stakeholders actually need and requirements that reflect what an analyst happened to ask about. It is the difference between a project that stays on scope and one that drifts. It is, ultimately, a mark of professional maturity, the willingness to question your own defaults and choose the approach that serves the project, not the one that feels most familiar.