Why Requirements Gathering Fails in Consulting
Avery Brooks
April 21, 2026
A consulting firm wins a digital transformation engagement. They commit to redesigning the customer onboarding process for a mid-market SaaS company. Two weeks into the project, the discovery interviews reveal that the "customer onboarding process" doesn't actually exist as a unified workflow—each account manager owns their own version, and they're wildly different.
The team scrambles. Requirements suddenly shift. The solution that was supposed to take eight weeks now needs a complete redesign. Budget overruns. The client is frustrated. The consulting team blames scope creep.
Here's the real problem: requirements gathering didn't fail because of scope. It failed because the consulting firm committed to solving a problem it didn't yet fully understand.
This is endemic in professional services. According to Source Research, only 32% of clients rated their consulting engagements positively in 2025—down from 44% in 2021. The pattern repeats: teams rush past discovery, lock in timelines and budgets, then discover the actual problem is messier than the sales conversation suggested.
The cost is steep. Deloitte research shows one in five consulting projects fail to deploy, and nearly half overrun budgets or miss deadlines. The root cause nearly always traces back to requirements gathering: it was too fast, too shallow, or misaligned with how work actually happens.
A client calls with a problem. "We need to streamline customer onboarding." The salesperson scopes the engagement on a one-hour call. They ask "How many steps are in your current process?" and hear "About six." A solution architecture takes shape: we'll redesign those six steps into three. Project scope: 10 weeks, $150K.
Then delivery starts. Interviewing the actual team reveals: there are six documented steps, but the real process is 18 steps because people handle exceptions, workarounds, and context-specific decisions that the documentation doesn't mention. One account manager's "onboarding" takes three days; another's takes two weeks.
The problem the firm said they'd solve is not the problem the firm was actually hired to solve. But the contract locks in the original scope.
Requirements sound simple until you start gathering them. A CFO wants to cut onboarding costs. The Head of Customer Success wants to improve onboarding speed. The Support team wants more handoff clarity. These aren't necessarily aligned.
When discovery doesn't systematically surface these different priorities, the consulting team builds for one stakeholder and surprises the others. Adoption stalls. Conflict emerges.
Modern requirements gathering demands evidence: What does each stakeholder care about? Why? What's the actual cost of the current state? But most consulting discovery runs on interviews with whoever's available, often the person who scheduled the meeting (usually IT or operations), not the people whose workflows will actually change.
When discovery relies on individual style rather than structured methodology, two engagement teams working on similar problems produce completely different requirements. One team documents a 50-page requirements specification. Another produces a one-pager and calls it done.
The inconsistency isn't just inefficient. It's a quality risk. A junior consultant's first discovery interview will miss edge cases that a senior will catch. A team working under time pressure will skip validation steps. The result: some projects start with clear requirements; others start with ambiguity.
Without a standard discovery methodology, quality varies with whoever happens to be assigned.
Manual discovery doesn't scale. A single in-person workshop with 10 stakeholders costs eight hours of consulting time (plus prep, synthesis, and follow-up). If you need to interview 50 people across multiple sites, you're looking at weeks of travel and 200+ hours of billable time—most of it classified as discovery, much of it unbilled or considered overhead.
Consulting firms can't afford to do thorough discovery at scale. So they either (a) interview fewer people than they should, (b) accept unstructured discovery quality, or (c) run workshops that capture broad input but miss individual workflows and exceptions.
This constraint forces a choice: do discovery quickly or do it thoroughly. You can rarely do both at the scale consulting engagements demand.
Structured, evidence-based requirements gathering separates requirements elicitation from requirements documentation. It systematizes discovery so quality is consistent regardless of who's running the interview.
What it is: A repeatable framework where discovery interviews follow a clear structure, capture evidence from multiple stakeholders, surface areas of disagreement explicitly, and produce a validated requirements document that reflects both what stakeholders want and what operators actually need.
What it is NOT: A one-off problem diagnosis call or a stakeholder workshop where the loudest voice wins. It's also not a document written by consultants in a room, then reviewed by clients. It's collaborative from the start.
When it applies: Every consulting engagement where misunderstood requirements drive rework or adoption failures. In transformation work, this is always. In narrower technical projects, it's whenever multiple teams will be affected.
Requirements gathering moves through four distinct phases:
Step 1: Stakeholder Mapping and Prioritization Identify everyone whose workflow will change and anyone who can block adoption. For each stakeholder, understand: What's their current pain? What does success look like to them? Where do their priorities conflict with others?
Don't interview everyone in the same way. A CFO cares about cost and timeline. A frontline operator cares about how the change affects their daily work. A CIO cares about system integration. Structure interviews around what each stakeholder uniquely cares about.
Step 2: Evidence Capture from Operations Interview the people who actually do the work. Ask for concrete examples: "Walk me through the last time you..." This grounds the conversation in lived experience, not idealized process. Capture exceptions: "What happens when X breaks?" These edge cases are where most implementations fail.
Async interviews (video questionnaires, recorded walkthroughs) capture more operator voices at lower cost than in-person workshops. You get depth from fewer hours of consultant time.
Step 3: Alignment Surfacing Compare what you heard across stakeholders. Where do priorities align? Where do they conflict? Where do stakeholders have different mental models of the same process?
Document these tensions explicitly. Don't try to smooth them away in the requirements. If the CFO wants to cut cost and the Head of Customer Success wants to improve speed, and those goals are in tension, that's a strategic decision the client needs to make. Your job is to surface it.
Step 4: Evidence-Linked Requirements Documentation Write the requirements document such that each requirement is traceable back to evidence. Not "We will reduce onboarding time by 50%" but "Operations reported that current onboarding takes 18 steps and three weeks. Our design reduces this to 8 steps and five days, based on the workflows we documented in interviews with Jane, Marcus, and the support team."
That evidence link makes validation easier and rework faster.
Week 1: Discovery Planning and Stakeholder Mapping Define the scope of the engagement precisely. Map all stakeholders and their priorities. Prepare interview guides. Identify which interviews will be in-person (usually C-level) and which can be async (frontline operators). Schedule interviews.
Week 2: Evidence Capture Conduct stakeholder interviews. Use structured interview guides to ensure consistency. For operators, ask for specific examples. For executives, focus on business outcomes and constraints. Record when possible; transcripts are easier to reference during synthesis.
Week 3: Exception Mapping and Alignment Surfacing Analyze interview recordings or notes. Build a map of the current workflow with all branches and exceptions. Create a comparison matrix: what does each stakeholder want? Where do they agree? Where do they conflict?
Schedule brief follow-up conversations to clarify areas of ambiguity. If one operator described a step differently than another, ask both to explain. You're not looking for consensus; you're looking for truth.
Week 4: Requirements Documentation and Validation Draft the requirements document, maintaining evidence links. Instead of abstract statements, ground each requirement in what you heard. Share this draft with stakeholders. Ask them to flag what's wrong, what's missing, and what's unclear.
Plan for one round of edits. Most errors will surface immediately; implement fixes and you're done.
This timeline assumes moderate complexity. Larger engagements may need more time. But the structure remains the same: map, capture, surface conflicts, document with evidence.
The key differentiation: evidence-linked requirements force precision. You can't write "improve the onboarding process" and move on. You have to explain what "improve" means, whose perspective you're using, and what evidence supports the change.
This makes requirements reviews faster and rework easier. When a stakeholder says the requirements are wrong, you can ask what evidence contradicts them. Usually this resolves quickly.
Evidence-based discovery surfaces misalignment and ambiguity early, when the cost of fixing it is lowest. If a CFO's cost goal and a customer success leader's speed goal are incompatible, you want to know that in week two, not week eight.
Once requirements are clear and validated, solution design moves faster. Architects can build to validated requirements instead of against a vague problem statement that keeps changing.
Teams adopt solutions when they recognize themselves in the requirements. If discovery actually interviewed the people who will use the solution, they see their workflows reflected. That ownership drives adoption.
Scope doesn't creep when requirements are clear. Change requests are visible. Budget overruns become rare because the team isn't discovering the real problem mid-delivery.
Research from Deloitte shows that engagements with systematic requirements gathering deliver on time and budget 70% more often than engagements without it.
Platforms like ClearWork compress the discovery and evidence-capture phase by automating the interview process. Instead of scheduling 40 individual interviews across multiple sites, operations teams answer structured questions asynchronously. The platform surfaces patterns, exceptions, and areas of disagreement automatically.
This maintains the rigor and depth of manual discovery while dramatically reducing the time and cost of evidence capture. Consulting firms can do more thorough, evidence-based discovery at the scale their engagements demand—without requiring weeks of consultant travel.
Learn more about how automated discovery supports consulting delivery.
Not if you structure it right. Manual, unstructured discovery is slow. Structured discovery with async interviews, systematic note-taking, and clear synthesis is faster than workshops and slower delivery later. The choice isn't between thorough discovery and quick delivery; it's between discovery now and rework later.
Stop when: (1) you can map the current workflow with all exceptions, (2) you've heard from every stakeholder type affected, (3) you've surfaced areas where stakeholders conflict, and (4) you can justify every requirement with evidence. If you're still hearing completely new information in interviews, you haven't reached everyone yet.
That's the point of evidence-based discovery. Document what each stakeholder wants and why. Make the conflict explicit. Then the client decides. That decision is theirs to make; your job is to make sure it's an informed decision.
Partially. You can do preliminary design thinking during discovery to test ideas with stakeholders. But lock requirements before you lock design. Too many engagements get halfway through solution design before discovering the actual requirements.
Scope creep happens when requirements are vague. Clear, evidence-based requirements make scope transparent. Change requests become visible. The client sees the cost of scope changes early and can make informed decisions.
Requirements gathering fails in consulting when teams rush to diagnosis without fully understanding the problem. The cost is steep: projects overrun budgets, miss timelines, and struggle with adoption.The modern approach is systematic: map stakeholders, capture evidence from operators, surface areas of disagreement explicitly, and document requirements such that each one is traceable back to evidence. This approach takes roughly the same time as quick, shallow discovery but produces requirements that actually reflect how work happens. The bottleneck in consulting is rarely the execution. It's the clarity of what needs to be executed. Evidence-based discovery removes that bottleneck.