Fixed Specs, Moving Targets: The Requirements Problem No One Wants to Admit

Every custom software project in America starts with the same ritual: weeks of discovery meetings, a thick requirements document, sign-off, and a promise that the specification represents what the business needs. Then reality intervenes. A competitor ships a feature. A regulation changes. Sales realizes customers want something different. By month four, the requirements document — the artifact everyone treated as gospel — describes software for a company that no longer exists.

If this sounds familiar, the problem isn't your discipline or your vendor. The problem is the model. Fixed-scope requirements gathering was designed for an era when markets moved in quarters, not weeks. In today's US mid-market, it's structurally mismatched with how fast the business actually changes.

Why the Waterfall Spec Fails on Its Own Terms

The promise of a fixed requirements document is predictability: lock the scope, control the budget. But the document can only lock what's known at the time of signing. Research across the industry has consistently shown that a large share of features built from fixed specs are rarely or never used — not because they were built badly, but because the need evaporated before the code shipped.

The failure mode is compounding. Long discovery phases delay the start of development. Long development cycles widen the gap between the spec and the market. And a wide gap means more rework, more change orders, and more friction between the business and the build team. The document meant to reduce risk becomes the largest source of it.

The Alternative: Continuous Discovery in Three Layers

Moving past the fixed spec doesn't mean abandoning rigor. It means redistributing it across the project's lifetime instead of concentrating it at the front. We recommend three layers:

1. Iterative discovery. Replace the one-time requirements phase with short, recurring discovery cycles — two to four weeks — where business stakeholders and engineers review real usage data and re-rank priorities. Requirements become a living backlog, not a contract exhibit.

2. Modular architecture. Design the system in loosely coupled modules with clear boundaries, so a change to pricing logic doesn't ripple through the entire codebase. Modularity is what makes cheap change technically possible; discovery is what makes it business possible.

3. Evolving contracts. If you work with an outside development partner, structure agreements around capacity and outcomes rather than a frozen feature list. Time-and-materials arrangements with quarterly re-scoping — paired with clear acceptance criteria per iteration — keep incentives aligned with a changing business.

Case Study: Cutting Wasted Development in Half

Consider a hypothetical but representative example: a 300-employee logistics software firm based in Columbus, Ohio. In 2022, the company commissioned a customer portal using a classic waterfall spec — 214 documented requirements, an eight-month build, a fixed price.

The result was predictable. The portal shipped in month nine, but by then the company had pivoted its onboarding process twice, and roughly 40% of the built features no longer matched how customers actually worked. Usage data showed that nearly a third of the development spend had produced functionality nobody touched.

For the next initiative — an internal dispatch dashboard — the company changed approach. Instead of a mega-spec, it ran two-week discovery-and-build cycles. Each cycle ended with a demo to the dispatch supervisors who would actually use the tool, and the backlog was re-ranked based on their feedback. The architecture was split into modules: route assignment, driver messaging, and exception reporting, each independently changeable.

The outcome: the dashboard reached usable form in eleven weeks instead of the projected seven months, and post-launch analysis showed that wasted development — features built but never adopted — fell by more than half compared with the portal project. Total spend was comparable. The difference wasn't cheaper engineering; it was engineering aimed at a moving target that was tracked in real time.

How to Start Without Blowing Up Your Roadmap

You don't need to reorganize the entire technology function tomorrow. Three practical first steps:

• Cap discovery phases at four weeks, and require that every requirement be tagged with the evidence that justifies it.
• Mandate modular design reviews for any build expected to live longer than a year, asking specifically: which parts of this will most likely change?
• Rewrite your next vendor contract around iterative delivery with re-scoping checkpoints, even if the overall budget is fixed.

The requirements document isn't evil — it's just a snapshot. Treat it as one frame in a film rather than the whole picture, and your software will finally keep pace with the business it was built to serve.