Education — Failure Pattern

Why requirements fail before procurement starts

Technology projects run 45% over budget and deliver 56% less value than expected — not because vendors underdeliver, but because requirements describe what hurts rather than what is broken.

45%

Average budget overrun on large IT projects

Nearly half the money is burned on poorly defined projects

56%

Value shortfall vs. expected on large IT projects

More than half the promised benefit never materializes

10%

Project time for pre-RFP discovery

A small upfront investment that prevents both failures above

The Symptom Trap

Common

Write requirements that describe visible pain points — slow reports, missing data, clunky workflows — without investigating what actually causes them.

45% budget overrun

Correct

Interview stakeholders separately, observe real workflows, and define measurable success criteria before writing a single requirement.

Problem solved at root

Why the Trap Keeps Working

Stakeholders describe what they feel, not what causes it. The business unit reports a pain point as they experience it — like telling a doctor "my head hurts" without knowing it's dehydration, not a migraine.

Requirements volume masquerades as quality. A 45-page RFP with 187 detailed requirements looks thorough — but high word counts in unknown territory signal the writers are guessing.

Post-mortems blame the vendor, not the requirements process. It's easier to fire a supplier than to admit the organization never defined the real problem — so the same cycle repeats with a new vendor.

4 Warning Signals — Detectable Before Any Contract Is Signed

RFP scope drafted in under a week. Requirements that go from first conversation to final document in days haven't been stress-tested. Speed signals procurement is capturing what stakeholders said, not what they mean.

Long on features, short on outcomes. "System must integrate with ERP" is a feature. "PO data flows to GL within 60 seconds with zero manual re-entry" is an outcome. When feature-to-outcome ratio exceeds 5-to-1, the RFP describes symptoms.

"Modernization" vocabulary without specifics. Phrases like "digital transformation" and "best-in-class platform" signal the organization knows it wants change but hasn't measured the gap it's trying to close.

Stakeholders disagree on the problem. Interview three stakeholders separately and ask "What problem are we solving?" If answers describe different problems, requirements will describe symptoms — because there's no consensus on the root cause.

Stop the Trap — Pre-RFP Discovery

Separate stakeholder interviews first. Before writing a single requirement, ask each stakeholder individually: what is the problem? What does success look like? What have you tried? Surface disagreements before they're baked in.

Observe actual workflows, not described ones. The gap between what stakeholders say they do and what observation shows they actually do is where the real requirements live — like watching someone cook instead of reading their recipe.

Define success as before-and-after metrics. "Improve efficiency" isn't measurable. "Reduce requisition-to-PO cycle from 4.2 days to under 24 hours" is. If you can't express the delta, the problem isn't defined yet.

Risk

Post-mortems that blame the vendor miss the real cause. Ask: would a different vendor with the same requirements have produced a different result? If no — the requirements process, not the supplier, is the root cause.

Jargon Decoder

RFP Request for Proposal — a formal document asking vendors to bid on a project, like a detailed job description for a software purchase.

Symptom Trap Confusing what hurts (slow reports) with what's broken (bad data) — like replacing tires when the alignment is off.

Requirements Discovery The process of figuring out what a solution actually needs to do — asking "why" before writing "what."

Pre-RFP Discovery Investigating the real problem before writing requirements — like a doctor running tests before prescribing treatment.

Post-Mortem An after-action review analyzing why a project failed — the autopsy that should reveal the root cause, not just blame the vendor.

Root Cause The actual source of a problem — not the visible symptoms. The broken pipe, not the water on the floor.

Sources: McKinsey research on 5,000+ large IT projects; C4C Group RFP best practices; David Wright, CIM. Analysis and intelligence from Rzzro.

Rzzro

Procurement, quantified.