Requirements Elicitation: Why Asking What People Want Is Not Enough
Requirements collected by asking people what they want produce a system that automates the part of the job they can describe. What they can describe is the part they do consciously, which on most jobs is a fraction of it, and rarely the expensive fraction.
The gap is nobody's carelessness. Somebody who has done a job for eleven years has compiled most of it into habit, and habit is not available for description. Elicitation is the work of getting at the parts that have gone quiet, and analysis is working out which of what you collected is actually a requirement.
What people say, and what is true
Three gaps open predictably, and they are worth expecting rather than discovering.
People describe solutions. A request for a report with twelve named columns is an answer to a question nobody asked. Those twelve columns exist because somebody built a workaround in 2018 and has maintained it since, and the need underneath may be better met another way or may have gone away entirely. The move is to ask what decision the report supports, then who takes that decision and how often.
People describe the current process. Asked what they need, people describe what they do, because that is the only version available to them. This is useful information wearing the wrong label, and it turns into a requirement to rebuild the existing process with newer technology. Separating what has to be true from how it currently happens is the analyst's job and nobody else's.
People leave out the exceptions. The standard case is describable because it is the one everybody rehearses. The exceptions, a sample arriving without its paperwork, a customer whose account predates the current structure, an order that has to be split between two suppliers, are handled automatically by whoever has been there longest, and they are missing from every description of the job. On a great many systems the exceptions are most of the work.
Techniques that get past it
Section 2.2.2 of the PMBOK® Guide Eighth Edition carries eliciting and analysing requirements as one piece of work, and four techniques do most of the eliciting.
Watch the work happen. An hour standing beside somebody doing the job yields more than three hours of interview, because what has gone into habit is visible even when it is not sayable. Watch and write, and ask about something only after it has happened in front of you.
Look at what the work produces. Spreadsheets, handwritten notes, whiteboards, labels stuck to monitors and the contents of a shared drive are requirements documents written by the people who need the system. A workaround is a requirement somebody has already specified and built.
Ask for the last three real cases. Not a typical case, which is an average nobody has ever encountered, but the last three that actually happened, with their paperwork. Real cases arrive with their exceptions attached.
Show something. A sketch, a screen mock-up or a paper prototype gets a reaction that no description will, because people are far better at criticising a concrete thing than at specifying an abstract one. Anything wrong in the sketch gets corrected within a minute.
The analysis half
Eliciting produces a pile of statements from people with different jobs, and analysis turns that pile into something a team can build against. Three moves do most of it.
Reconcile the contradictions rather than averaging them. Two people describing the same process differently is information: usually they are describing two variants that both exist, and either the system handles both or somebody decides which one survives. Averaging them produces a process nobody follows.
Separate need from preference. Both are worth knowing, and they behave differently under pressure. A need that goes unmet makes the system unusable. A preference that goes unmet makes it unpopular, which is a real cost and a different one. Recording which is which on the first pass saves the argument in month six.
Trace every requirement to something. Where a requirement cannot be connected to a stated outcome, a regulation, a contract or a named decision, either the connection has not been written down or the requirement is somebody's preference in a suit. Both are worth finding out during elicitation, not at acceptance.
The samples that arrived without paperwork
A life sciences company was replacing the sample tracking used across its laboratories. The request from the lab was specific and confidently stated: barcode scanning at every bench, and a dashboard showing sample status by study.
Two mornings of watching produced a different picture. Samples arrived in batches from clinical sites with a printed manifest, and roughly one in five came with something missing from the accompanying request: a collection time, a consent reference, an investigator signature. Those went into a tray beside the receiving bench and were resolved by one senior technician, who knew which sites to ring and which of their coordinators would answer. It took her between two and three hours a day, and she had not mentioned any of it, because to her it was not a task. It was what receiving involved.
Barcode scanning at the bench would have automated a step that took eleven seconds and was causing nobody any trouble. The requirement that mattered sat upstream, at the point of collection: a request that could not be submitted incomplete, and a route by which the receiving lab could query one without ringing round. The dashboard still got built, because study managers genuinely needed it, and it was built against a different set of statuses once somebody understood what the exceptions were.
Those two mornings turned up one more thing, which protected the project later. The technician's method of deciding which incomplete samples could proceed and which had to be held was entirely undocumented, and it was a decision with a regulatory dimension to it. Writing it down was in nobody's plan and became one of the more valuable outputs of the work.
For a PMP® candidate, the reading that helps is that a stated requirement is a starting point and not an instruction. A stakeholder asking for a specific feature is raising the question of what need sits behind it, and building what was asked for without establishing that is a reliable way to deliver exactly what was requested and satisfy nobody. Behind a stated requirement there is usually a decision or an exception, and that is what to look for. Practising where the stated want and the real need point in different directions is one of the more useful things a structured PMP exam preparation course does.
Give the first half-day of any requirements work to watching somebody do the job, and ask for the last three real cases with their paperwork. The two together take a morning and both change what gets built. Then put one line under each requirement afterwards saying what it is for. The ones where that line cannot be written are the ones to go back and ask about.
Interested in going further?
The requirement that damages a project is usually the one nobody thought to mention, because it went into habit years ago. Omega's PMP® Exam Preparation works through situations where the stated requirement and the real need are not the same thing.
Eliciting and analysing requirements sits inside the Scope Performance Domain of the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A102: The PMBOK 8 Scope Performance Domain: What It Really Covers
A103: Requirements vs Scope: Why the Difference Matters
A104: Acceptance Criteria: The Small Detail That Prevents Big Arguments
A105: Scope Baseline Explained
A106: Product Backlog vs Project Scope
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
