The Requirements Meeting Everyone Skips
The upfront conversation that saves you from building the wrong thing beautifully.
A public agency brought us in last year to figure out why a system that did everything right still failed. Delivered on time, clean build, users trained. Within a quarter the old spreadsheets were back, living quietly in the places where shadow IT lives.
The requirements document was forty pages of accurate detail. Every field, every approval step, every report format. Nowhere, in forty pages, did it say what the process was for.
Transcription is not analysis
Most requirements gathering is stenography. An analyst sits with the team, writes down what they do, formats it nicely, and sends it back for sign-off. The team approves it, because of course they do. It's a description of their own habits.
The result is a document that is completely accurate and nearly useless. It captures the process as it exists, including the steps that exist only because a manager who retired in 2015 wanted a copy of everything.
Interrogation is different work. Interrogation asks why the form needs three signatures. It asks what happens if step four gets skipped, and when someone says "nothing, actually," it writes that down too. The best analysts we've hired are politely relentless. The politeness gets them into the room; the relentlessness earns the fee.
The meeting nobody schedules
Before anyone writes requirement one, hold the meeting where you ask what this process is for. What outcome, for whom, measured how. Get the process owner, somebody downstream who consumes the output, and somebody senior enough to change the process rather than just describe it.
The cheapest fix in software is the question someone asks before the build starts.
It's an uncomfortable hour. Half the room hasn't thought about the question since onboarding, and the other half will disagree with each other about the answer. That disagreement is exactly the information you need before you build anything.
A permitting team we sat with discovered, mid-meeting, that the three-week review cycle everyone wanted automated existed to catch a class of error the upstream system had eliminated years earlier. The right requirement wasn't "automate the review." It was "stop doing the review." Twenty minutes of questions deleted three weeks of cycle time, and no code shipped at all.
That's the pattern we see over and over. The biggest wins in these projects are rarely built. They're found, usually in the first two meetings, by someone willing to ask a question that sounds slightly rude.
Three questions to steal
If you want a cheap version of this discipline, take three questions into your next kickoff. What does this process produce? Who consumes it, and what do they do with it? What would break if it stopped tomorrow?
When nobody in the room can answer the third one, you haven't found a gap in the requirements. You've found a process that may not need to exist, and you found it before paying to modernize it.
The agency's system, by the way, did get rebuilt. Smaller the second time. Half the screens, a third of the reports, and the spreadsheets finally retired. The difference wasn't better developers. It was a better first meeting.
Scenarios in ERA notes are illustrative composites drawn from two decades of prior work, not ERA client engagements.