The specification review that reviewed nothing

The meeting is scheduled for two hours. Twelve people in the room. The functional specification sits in front of each of them, three hundred pages, bound, printed double-sided. The programme manager opens by thanking the operational team for their time. The document represents months of work, he says. Today is their opportunity to review and sign off.

What the operational team is not told, because nobody needs to tell them, is that the document is already load-bearing. The vendor has been selected on the basis of a tender response that references this specification. The contract assigns price and penalty against what it contains. The programme schedule has twelve weeks of float built in, none of which can accommodate specification rework. By the time the bound copy reaches the review meeting, the document is doing structural work that cannot be undone without tearing something else down.

So when the programme manager asks for review and sign-off, he is not asking the same thing twice. Review is the invitation. Sign-off is the deliverable. The operational team will raise concerns, as they always do, and the concerns will be captured, logged, and categorised. A small number will result in typographical corrections. The rest will be deferred to a change request process that everyone in the room knows is funded for a fraction of what will actually be needed.

Why the document arrives locked

Procurement is not being cynical. A competitive tender needs a fixed document. The bidders are pricing against a defined scope, the evaluation panel is scoring against defined criteria, and the eventual contract assigns penalties against defined deliverables. None of this works if the specification keeps changing. By the time the tender is in the market, the document is legally load-bearing.

Operations works the other way around. Operational requirements are discovered, not declared. A controller looking at a wireframe asks different questions from a controller looking at a working prototype, who asks different questions again from a controller running the system against live traffic. The specification that captures what operations actually need is not a document that can be written in advance. It takes shape through iteration, and iteration needs the specification to be open, not closed.

Two processes, opposite requirements. One has a legal deadline attached. The other does not. When they collide, the legal deadline wins, and the document is locked against the wishes of the people who will have to use what's inside it.

What a locked document misses

Consider a supervisor who needs to mark a military activity area, a circle with a defined radius, on the radar display. On the previous system, they drew it. Centre-point and radius, right on the live screen, using the tools already in front of them. The replacement system draws lines and polygons. It does not draw circles. Nobody writing the specification thought to require the capability, because nobody imagined a radar display that couldn't. The old tool wasn't in the specification document, so it isn't in the system.

Every veteran controller has five of these. The quick entries, the customisations, the keystrokes that became muscle memory fifteen years ago and disappeared in the transition. None of them are edge cases. They are the class of thing a controller does without thinking, because they stopped thinking about it a long time ago. You do not surface them by asking controllers to review a written specification. You surface them by watching controllers work.

When nobody owns the gap

Go live reveals the gap. The supervisor reaches for the familiar tool and realises the capability is gone. The incident is logged. Someone must own it.

Procurement does not own it. The vendor delivered against the contract, on budget, on time. The specification has been audited against the build. Procurement's work is complete and signed off.

Operations does not own it. The people who would have written this requirement into the specification were not in the room when it was being drafted. They can say what is missing now, but the channel to have said it then is closed.

The vendor does not own it. They priced and delivered against a document they were given. Any change is a change request, and change requests are priced at rates that assume the contract is already won.

Three parties, three defensible positions, no ownership. The gap sits in the airspace between them, and the cost of closing it compounds every week it remains open.

What input that changes the system looks like

Genuine operational input is not a meeting. It is a funded programme activity that begins before the RFP goes to market and continues until the system is operational.

It looks like controllers authoring the scenarios the vendor will be asked to demonstrate, not reviewing the vendor's demonstration script. It looks like operational walkthroughs as part of vendor evaluation, not written responses scored by a panel who has never worked traffic. It looks like a named operational authority with the power to reject a specification item, not comment on it. And it looks like a budget line for specification iteration between RFP publication and contract signature, because that iteration is the work, not an interruption to the work.

None of this is free. It adds months to the procurement cycle and people to the project cost. Every programme I have seen try to skip it has paid the equivalent cost later, with interest, in change requests and deferred operational status.

Before your next system goes out to tender, ask one question about the specification that is about to leave your hands: were controllers the authors of this document, or approvers of it?

The answer tells you whether you are running a procurement programme or a transition programme in waiting.