Three vendors quote for the same replacement system. The numbers differ by a factor of four, and not one of the three is lying. They are answering different questions, because nobody told them precisely which question to answer. That gap is not a procurement failure and it is not a negotiation failure. It is an architecture failure, and it was priced in months before anyone opened a tender.
The price is set long before the tender
By the time a quote arrives, most of the price has already been decided. It was set by how precisely the buying organisation can say what it needs, what the new system has to connect to, which data it owns, and what “done” will mean. A vendor pricing against a clear scope is pricing a known quantity. A vendor pricing against a vague one is pricing risk, and risk is expensive.
That is why, in many organisations, three honest quotes can differ fourfold. Each vendor filled the gaps in the brief with its own assumptions, then padded for the assumptions it could not verify. Nobody is being cynical. They are quoting the uncertainty they were handed.
The vendor is often the only one with the whole picture
The deeper problem is not one purchase. After a few years of buying this way, the vendor is often the only party with an accurate picture of how the landscape actually fits together. They know which interface the payroll system really uses, which nightly job nobody dares switch off, and which two services quietly depend on a field that was meant to be temporary.
That asymmetry is not a side effect of the relationship. It is the relationship. It sets the price of the next upgrade, it decides how credible a competing bid can be, and it determines what leaving would cost. None of it appears as a line item, which is exactly why it goes unmanaged.
AI made the middle cheap, which moved the leverage
For twenty years the scarce thing in software was delivery capacity. Vendors sold capacity, and buying the surrounding consultancy alongside it felt like a reasonable way to point a scarce resource at your problem.
That scarcity has thinned out. Drafting requirements, sketching an architecture, writing integration code, maintaining a regression suite, and now exploring the parts of a system nobody specified have all become faster within about two years. We use these tools daily and they are good at this work, which is the point: if they are good for us, they are equally good for your vendor, and the capacity that justified the premium is no longer scarce.
What did not get cheaper is knowing what to ask for, and knowing whether you got it. Judgement about your own landscape, your regulatory exposure, your data, and what must still be true in five years does not compress. So the leverage moved off the middle of the project and onto its two ends.
A first pass at requirements is scope, not specification
The front end is smaller than people expect, and it is the part most often skipped because it looks like it should take a year.
It does not. What a buying decision needs is scope: a current capability map, the handful of integrations that are genuinely load-bearing, the features that carry the business case as opposed to the ones that made it into the wish list, the data and its jurisdiction, and the skills your own business operations will need in order to live with the result. In our experience two weeks is enough to connect the dots, when the right people are available and in the room. That condition is the real constraint, not the method.
Scope is not the full specification and should not pretend to be. The detailed work belongs with the vendor you eventually pick, which is fine, because by then you are specifying from a known position instead of an empty one. The first pass exists to do three things: make three vendors quote the same thing, tell you which products you actually need to buy, and tell you which capabilities you will have to hold afterwards, on the business side of operations and on the technical side alike.
This is ordinary TOGAF and IREB practice run at a deliberately early, deliberately shallow depth. None of it is new. What is new is that producing and maintaining it has got cheap enough that a mid-sized organisation can hold it, where five years ago the honest answer was that only an enterprise could afford to.
The document you buy with is the document you accept against
Here is the part that makes those two ends one capability rather than two services.
The requirement you wrote in order to go to market is the requirement you later hold the delivery against. Written once, used twice. If the acceptance criteria were explicit enough to price, they are explicit enough to test, and a regression suite is the durable form of that. If they were not, then acceptance becomes a matter of opinion, and opinion at acceptance time always favours the party that has been living in the code.
That is the practical reason to resist a vague brief, more than any principle about rigour. A vague brief does not only cost you money at the start. It costs you the ability to say no at the end.
The common version of this story: software is delivered, then the requirements are reconstructed after the fact and the testing finished retroactively, because nobody had written down what to accept against. That work happens anyway, but at the worst possible moment, with no leverage, and it often ends in a change of vendor.
Acceptance belongs to the side that has to live with the result
Formal acceptance is usually signed by whoever is measured on the milestone. That is the wrong person, through no fault of their own. A project manager is accountable for a date, and the honest incentive at the end of a late project is to accept and move on.
Two other parties have to live with what gets signed, and they are routinely spoken about as if they were one. Business operations is the client: the organisation that will run the service for its own customers, carry its cost, answer for it to its regulator, and need it changed over time. Technical operations is whoever keeps the thing running afterwards: patching the CVE, restoring the backup, and producing evidence when an auditor asks. The first is always the client; the second might sit with the client, with us, or with the vendor, depending on what was contracted. Neither is usually in the room when the acceptance protocol is signed.
At acceptance we act for business operations: that is the side acceptance exists to protect, and the side that carries the result for years after the project closes. What makes that judgement worth buying is the second role: we run production systems ourselves, so we know what a shortcut in an interface, or a missing runbook, actually costs once the project team has moved on. Knowing that is not the same as being the party who has to live with it, and we are careful not to confuse the two.
In practice it is acceptance testing against the explicit requirements, run by our own test practice rather than by the supplier being judged against them. It is an uncomfortable role to hire someone into, and it is the one that pays for itself on the first refusal.
Where this goes wrong
Insourcing architecture badly is worse than not doing it. A capability map nobody updates is a liability, because people trust it. An architecture function with no authority over purchasing decisions is a documentation exercise, and the first project with a deadline will route around it.
The test is unglamorous, and it is the one worth applying before anything else. Can you hand a competing vendor a scope precise enough to quote against, without your incumbent’s help? Can you state, today, what would make you refuse the next delivery? If both answers are yes, the capability is there and your prices will show it. If either is no, that is the work, whatever the diagram on the wall suggests.
Two ends and a middle
A software project has three parts you can buy separately: deciding what is needed, building it, and judging whether what arrived is what was needed. Most organisations buy all three from the same supplier, then wonder why the third one is generous.
The middle has become the cheapest part to buy and the easiest to compare. The two ends did not get cheaper, and they are the ones that decide what the middle costs.
Own the ends. Buy the middle. Keep the person who signs the acceptance on your side of the table.
