You come across them regularly: requirements specifications that scream for attention. Not because they are fantastic requirements specifications. Quite the opposite. They scream for attention because they are a risk. They are numbered, neatly formatted and seemingly complete, but they contain requirements that can be read in two ways, that nobody quite knows how to verify, or that rely on assumptions that are written down nowhere.
Usually this only becomes visible at the wrong moment: during an audit, a verification or a discussion with the client. That is rarely due to carelessness on the part of whoever wrote the specification. Such a document is produced under time pressure, with multiple authors, and often with hundreds or thousands of lines. A sentence that is clear to the writer is not always clear to the reader, or to a colleague a few months later.
Infrastructure first. Flyvbjerg, Holm and Buhl studied 258 transport infrastructure projects (rail, bridges, tunnels and roads) in twenty countries, together worth about US$90 billion. In roughly nine out of ten projects, costs ended up above the estimate, by 28 percent on average. They also found that each additional year between the decision to build and the start of operations went together with about 4.6 percentage points of extra cost escalation on average. Their advice: solve problems in the preparation phase, before they come back as delay during execution. That study does not measure the quality of requirements, by the way. It shows what delay costs, not what a single unclear requirement costs.
For the cost of discovering problems late, the best-known research comes from software. In 2001, Boehm and Basili brought together empirical data: a problem that is only found and fixed after delivery is often roughly a hundred times as expensive as when it was caught in the requirements or design phase. For small, non-critical projects, that factor is closer to five. They also estimated that on software projects of that time, 40 to 50 percent of the effort went into avoidable rework. They name hastily specified requirements and a design that only handles the nominal case as two major sources of that. Those are software figures, and a construction project is not a software project, so you should not translate the factor of one hundred one-to-one. The direction is recognisable, though: the later an error comes to light, the more expensive it is.
Anyone who reads many requirements specifications sees the same kinds of problems again and again:
On their own, such things seem small. With a hundred requirements it is an annoyance. But many requirements specifications consist of hundreds or thousands of lines, written by multiple authors and changed over multiple revisions. Then it adds up, and it becomes more expensive the later it is discovered.
A tool like RQA (Requirements Quality Analyser) is often seen as a check after the fact on an existing requirements specification. That is possible, and sometimes it is exactly what is needed. But it is at least as useful during the formulation itself, for example in the customer requirements specification (KES) process or the stakeholder requirements specification process. Then you remove a vague term, an unverifiable formulation or a requirement that asks two things at once before it ends up in the requirements specification. That is the moment when repair is cheapest.
RQA checks requirements against the INCOSE rules for writing requirements. You upload your requirements in Excel and each requirement gets a score from 1 to 5, an explanation of which rules are affected and an improvement suggestion. That suggestion starts as a draft: you accept it or adjust it. RQA also checks the set for contradictory and duplicate requirements. Anyone on the other side of the table, for example a bidder who receives a requirements specification, can run the same analysis as executor. You then also get, per requirement, the risk, the assumption and concrete questions you can put to the client.
Recently I had a KES session with a construction team in which we used RQA. The client was enthusiastic about it, but also had a reservation: if everyone soon uses AI tools like this, won’t you end up with the same elaborations and the same bids everywhere?
For AI tools for tenders, I agree with him. If different bidders use the same tooling, you will at some point end up with the same EMVI (most economically advantageous tender) measures.
RQA is different, and that is precisely the nice and human thing about it. RQA assesses how a requirement is written, not whether it is the right requirement. What you ask for and how much room you leave remains up to the client. Do you want to specify requirements down to the level of detail, or do you define the room to manoeuvre yourself and leave the opportunities to the contractors? That is where the room for innovation and the knowledge to arrive at good solutions lies. That is why RQA lets you set the strictness, switch rules on or off and choose a light check, because requirements sometimes deliberately leave room for the solution.
RQA does not come up with the solutions itself. They come from people with expertise. I hope it stays that way, although I do not rule out that AI will play a larger role in it over time. What you can do with RQA afterwards is formulate those solutions sharply as new requirements.
Here you can read more about how RQA works, or contact us for an explanation tailored to your situation.
Sources