In 1948, mathematician and physicist Claude Shannon introduced a concept that fundamentally changed how we understand communication: Information Entropy. In simple terms, entropy is the measure of uncertainty, randomness, or “noise” within a message. The higher the noise, the harder it is for the receiver to decode the actual signal.
In modern enterprise procurement, we are currently witnessing a massive spike in Requirement Entropy.
Organizations, frequently guided by traditional agile consultancies, are issuing Requests for Proposals (RFPs) packed with upwards of 1,500 “business-outcome focused” user stories. While the intent behind generating this mountain of documentation is to be thorough, the actual economic effect is entirely counter-productive: It drives the highest-quality vendors away.
I recently witnessed this structural failure firsthand during a major housing provider’s procurement for a core Finance system. The RFP consisted of a massive, un-distilled backlog of micro-level user stories. The result? A 75% vendor refusal rate.
This collapse didn’t happen because the project lacked budget or market appeal. It happened because the Signal-to-Noise ratio was too low for elite vendors to safely manage.
The Misunderstanding of the User Story
The root cause of this entropy is a fundamental misunderstanding of what an RFP is supposed to achieve.
An RFP does not need to capture every granular, functional permutation of how an end-user might interact with a screen. When a requirement document states something vague like, “The system shall facilitate the triaging of complex asset repairs,” it contains exactly zero actionable data for an estimator.
Software is not a collection of abstract wishes; it is a System of Logic. To price a complex implementation accurately, an elite vendor doesn’t need 1,500 fragmented user stories. They need to understand the physics of the solution:
The core architectural mechanics.
The target data models.
The hard integration boundaries and system interfaces.
Detailed user stories are a delivery tool, not a procurement tool. They belong downstream of the contract award. As long as the upfront architectural guardrails are clearly defined and owned by the client, the micro-level user stories can be safely mapped out during successive delivery sprints without risking structural drift.
The Market for Lemons: Adverse Selection in Procurement
In economics, George Akerlof’s Nobel Prize-winning theory, The Market for Lemons, explains what happens when a buyer cannot accurately distinguish between a high-quality asset and a low-quality one due to asymmetric information. Over time, the high-quality sellers exit the market entirely, leaving behind only the broken cars—the “lemons.”
A high-entropy RFP inadvertently triggers this exact economic pattern of Adverse Selection:
The Transparent Vendor: These are the partners you actually want to do business with. They want to provide an honest, predictable, fixed price. However, because the RFP hides the “hard logic” (the non-functional requirements, data migration complexities, and state transitions) behind a wall of vague stories, they cannot estimate their risk. To protect their integrity and capital, they simply decline to bid.
The Opportunistic Vendor: These vendors thrive on ambiguity. They look at a chaotic 1,500-story backlog and see a Change Request goldmine. They will happily lowball the initial bid to get through the door, fully aware that the vagueness of the requirements gives them the legal leverage to extract millions in scope re-negotiations later.
By failing to provide technical clarity upfront, organizations systematically filter out the most disciplined engineering firms in the market.
The Complexity Tax and Requirement Archaeology
When an engineering firm’s estimating team is forced to wade through 1,500 repetitive, fragmented user stories, they hit cognitive overload. Because they cannot decipher the true technical scope, they protect themselves by applying a Complexity Tax.
They aren’t pricing the code; they are pricing the uncertainty. The client ends up paying an inflated premium not because the project is uniquely difficult, but because the lack of technical definition has forced the vendor to heavily buffer their quote against the unknown.
If you dig into these massive backlogs, you quickly realize they aren’t strategic roadmaps—they are an archaeological record of historical organizational pain. They mix high-level corporate sentiment with legacy process complaints.
While capturing stakeholder sentiment is a vital part of early discovery, it is an asset that must be distilled before it hits the market. Passing raw, un-templated business sentiment to external software vendors and expecting them to magically design your architecture is an abdication of client ownership.
The Antidote: High-Density Technical Stewardship
To secure a fair price and attract the market’s best engineering talent, organizations must shift their procurement strategy from High-Volume Documentation to High-Density Architecture.
This is the core of Technical Stewardship at Recursive Software. We believe that accuracy is the highest form of advocacy for a client’s budget. We step into the design gap to architect certainty before procurement begins:
Backlog Consolidation: We condense 1,500 fragmented, sentiment-driven stories into 10 to 15 highly defined, functional Work Packages.
Upfront Architectural Guardrails: We define the Logical Data Models (LDMs) and Sequence Diagrams prior to the tender. We explicitly lay out the non-functional requirements—specifying integration mechanics like idempotency keys and dead-letter queues—so the vendor doesn’t have to guess.
Signal Restoration: We cut away the noise and expose the core technical signal, giving elite vendors the concrete structural data they need to bid with absolute confidence and aggressive pricing.
When you take ownership of the upfront design, you dictate the terms of your transformation. Stop asking vendors to guess the physics of your system through a mountain of user stories. Define the boundaries, establish the mechanics, and let the engineers build.
Recursive Software: Business Outcomes, Built on Technical Integrity.
