Requirements gathering and requirements elicitation are not the same thing. The difference explains why requirements keep failing even on teams that try hard to do them well.
Requirements elicitation is one of those terms that gets used in project management training without anyone spending much time on what it actually means — or why it’s meaningfully different from requirements gathering. The difference matters. Understanding it is the key to understanding why requirements fail even when teams think they’ve done a thorough job.
Gathering vs. Eliciting: The Critical Distinction
Requirements gathering is passive. You ask stakeholders what they need. You listen. You document. It assumes that the requirements exist in stakeholder minds in articulate form, ready to be collected. Requirements elicitation is active. You create the conditions under which requirements that stakeholders don’t know they have can surface. Elicitation assumes that the most important requirements are often not immediately accessible — they need to be drawn out through structured techniques, not simply asked for.
The failures persist because gathering is not eliciting, and most organizations only do the former.
Why Stakeholders Can’t Tell You Everything You Need to Know
Expert blindness is a well-documented cognitive phenomenon: people with deep domain expertise systematically under-report the foundational knowledge that underpins their work. A senior accounts payable manager describing requirements for a new AP system will tell you about the approval workflows and reporting requirements. She won’t tell you that the system needs to handle a three-day processing lag at fiscal year-end, because that’s just how it is — everyone knows that. Except the IT team doesn’t.
The Core Elicitation Techniques
Structured interviews move through a systematic framework — every entity the system needs to know about, every process it needs to support, every rule that governs those processes. The framework prevents the natural human tendency to describe only what’s salient while omitting what feels obvious.
Scenario-based walkthroughs ask stakeholders to describe what they do in specific situations. “Walk me through what you do when a vendor submits an invoice with a purchase order number that doesn’t match your records” forces concrete thinking that abstract questions don’t.
Document and system archaeology examines existing artifacts for requirement evidence. Error logs, help desk tickets, and user workaround documentation are some of the richest sources of requirements evidence available.
Prototyping and simulation use early representations of the solution to surface requirements that stakeholders can’t articulate abstractly but can recognize immediately when they see something wrong.
Observation and shadowing watch how stakeholders actually work. The gap between how people describe their work and how they actually do it is consistently significant.
What Elicitation Training Actually Develops
Elicitation is a skill, not a technique. It’s all about knowing what questions to ask when. Knowing that scenario-based walkthroughs exist is different from being able to conduct one effectively. That skill is developed through practice, not instruction. Most project management training produces declarative knowledge. It doesn’t provide the structured practice that builds elicitation skill. That gap is a significant part of why requirements problems persist in organizations with well-trained project managers.
The Stakeholder Who Doesn’t Know What They Need
“I need a report that shows me what I see today, but faster” is a requirements statement from a stakeholder who knows they need better information but doesn’t know what better information looks like. Gathering what this stakeholder says would produce a requirement to replicate today’s report faster. Eliciting what they actually need might produce a requirement for a completely different kind of information asset.
→ Our course teaches the elicitation methodology, gives you the questions to ask at each stage of your process, and — critically — provides the structured practice that builds real capability, not just knowledge about what good elicitation looks like.
Explore the course → bridgingbusinessit.com/the-course/
