Vague Specifications: The Most ExpensiveDocument in IT

IEEE Spectrum's well-known review of software failures lists "badly defined system requirements" among the most common reasons projects fail (Charette, IEEE Spectrum, 2005). Two decades later, the pattern has not changed.

Ask the survivors what went wrong, and a common answer is not "bad technology" or "wrong team." It is "nobody knew what we were actually building."

Vague specifications do not feel like a crisis when you write them. They feel like normal business. But they are the most expensive form of project paralysis: rework, scope creep, vendor finger-pointing and months of unbudgeted integration work. Here is what they cost and how to prevent them.

Key Takeaways

• Poor requirements are a leading driver of rework and cost overruns.
• Badly defined requirements are a recognized root cause of software project failure.
• Well-documented failures, such as Sainsbury's US $526 million supply-chain write-off, show what is at stake.
• Vague specs breed scope creep: teams redefine requirements as they build, creating endless rework cycles.
• Clear functional and non-functional requirements remove one of the most common sources of delay.

The Hidden Cost of Unclear Specifications

When specifications are vague, the real cost is not visible in the project plan. It hides in rework.

A specification says “the system must be fast” instead of “product catalog queries must return in under 200ms with 10 million SKUs.” The development team builds something. Testing reveals performance does not meet unstated expectations. Everything gets rebuilt. Eight weeks of work become twelve. The vendor blames the client for moving goalposts. The client blames the vendor for not asking clarifying questions.

Meanwhile, your project sits in rework purgatory.

This is not a small friction cost. Defects that start in the requirements are among the most expensive to fix, because they surface late and touch every layer built on top of them.

Why Enterprises Keep Writing Bad Specifications

Vague specifications are rarely malice or incompetence. They are the default when you have:

Competing stakeholder views. The CMO wants “fast checkout.” The CRO wants “conversion optimized.” The CFO wants “cost effective.” Nobody translates these into measurable requirements. The spec stays high-level. The vendor interprets it their way. Six months later, everyone is frustrated.

Unclear technical terminology. Business teams and IT speak different dialects. “Real-time reporting” means sub-second updates to a data analyst. It means “refreshed daily” to a CFO. The spec says “real-time”. The build does not match expectations. Rework.

In e-commerce project management for a French florist chain, specifications had to be precise enough for developers and clear enough for business teams at the same time.

No defined success criteria. Acceptance testing becomes negotiation. Did the system perform? Depends on who you ask. A vague spec has no answer. You cannot fail a test if nobody specified what success looks like.

These are not rare edge cases. They are the structural default in most IT programs.

Real-World Cost Impact: Two Well-Documented Failures

Some of the largest software failures on record show what is at stake when requirements and reality drift apart. Both cases below come from IEEE Spectrum's review of software failures:

Sainsbury's supply chain system (UK, 2004): the retailer wrote off its US $526 million investment in an automated supply-chain management system after merchandise got stuck in depots and warehouses and extra staff had to stock shelves by hand.

FAA air traffic control upgrade (US, 1981 to 1994): the effort to replace the air traffic control system became riddled with problems. More than $2.6 billion had been spent when the agency abandoned it in 1994.

Notice the pattern? These were not bad teams. They were capable organizations that underestimated how much clarity a large system needs before it is built.

The Specification and Scope Creep Death Spiral

Vague specifications do not just create rework. They create uncontrolled rework.

Here is how it works:

Phase 1: Unclear specs written. Teams move into design and build. Nobody is quite sure what “flexible” means or what “enterprise-grade reporting” includes, but you move forward.

Phase 2: Interpretation diverges. Developers build one thing. Stakeholders see it and say “that is not what we meant.” Because the spec was vague, both sides are technically right.

Phase 3: Scope creep begins. To satisfy stakeholders, the vendor and IT team add features that were never in the plan. Budget gets consumed. Timeline slips.

Phase 4: Uncontrolled rework. Since the original spec was vague, there is no agreed definition of done. Rework continues indefinitely. The project becomes a cost center rather than a delivery.

Breaking this cycle requires clear specifications before build begins. Not waterfall dogmatism: clarity.

How to Write Specifications That Actually Work

Clear specifications do not require 500-page documents. They require discipline.

Define functional requirements with measurable criteria. Not “the system must scale.” Say “the system must handle 50,000 concurrent users with response times under 500ms at 99.5% uptime.” Measurable. Testable. Non-negotiable.

Define non-functional requirements explicitly. Performance targets, security standards, compliance scope, availability requirements, integration points, data retention policies. Write them down. Get stakeholder sign-off before build begins.

On a luxury fashion house's move to composable commerce, security specifications were written alongside the functional stories, as described in the headless commerce case study.

Use defined technical terminology. If you say “real-time,” define it. Sub-second? Minute-level? If you say “enterprise-grade,” what does that mean? High availability? Compliance with SOC 2? Spell it out. No acronyms without definition.

Document acceptance criteria. How will you know the system succeeds? Write test cases. Define edge cases. Get IT, business stakeholders and vendors to review and sign off before work begins.

Assign a specification owner. Someone is accountable for keeping specs clear and current. Not a committee. One person. They are the tiebreaker when stakeholders disagree on what “fast” means.

On a Fluent Commerce OMS project for a flash-sale retailer, with four to six partners involved at once, that role sat with the product owner who held the backlog.

Side by side, the difference between vague and clear wording looks like this:

Clear specifications remove one of the most common sources of delay. Teams stop arguing about what was meant and start testing against what was agreed.

Scope creep during build is often blamed on “bad project management.” The real culprit is incomplete specifications. You cannot manage scope if the original definition was never clear. Clear specs come first.Worth knowing

Conclusion

Vague specifications feel like a minor documentation problem. They are not. They are a cost control failure, one that can consume millions in unplanned rework, delay critical initiatives by months and fracture relationships between business and IT.

The organizations that avoid this trap do one thing differently: they invest in specification clarity before the build begins. Measurable criteria. Defined terminology. Signed stakeholder alignment. Acceptance tests written before development starts.

It costs time up front. It saves far more in rework prevention.

If your current project already shows scope creep or rework, the issue is probably your specifications, not your team. For PIM programs specifically, see how to brief a PIM vendor and why PIM projects fail.

Need help auditing where requirements broke down? Book a discovery call.