The need a company states and the need it has are rarely the same thing, and almost every supplier around the table is paid to serve the first one. Not out of malice. Because the stated need is specified, budgeted and billable, while the real one is a conversation nobody invoices. The result is an organisation that buys a correct answer to the wrong question, pays for it in full, and concludes from the failure that it should buy more.

A stated need is a translation, and translations lose things

A chief executive does not observe a technical problem. He observes a consequence. Month-end takes too long. Two salespeople left and the third is complaining. A customer escalated for the second time this quarter. Something in the machine is producing an outcome he can feel.

Between that observation and the moment it becomes a request, there is a translation step. It takes about four seconds and it is invisible. The consequence gets matched against a pattern, the pattern gets matched against a remedy, and the remedy gets spoken out loud. We need a new ERP. We need to migrate off this platform. We need a CTO.

The translation is not stupid. It is experience doing its job. A leader who stopped to diagnose every irritation would never decide anything, and most of the time the shortcut lands close enough to be useful. The trouble is what happens to the shortcut once it has been said in a room.

The moment a need is stated, it stops being a hypothesis and becomes the subject. Meetings are scheduled about it. Budget lines are opened under its name. Suppliers are asked to quote against it. Within two weeks, nobody is discussing the consequence any more. Everybody is discussing the remedy, its options, its timeline and its vendor shortlist.

The original observation is now an unexamined premise carried inside a procurement process.

Software people gave this a name long before management did. The XY problem: someone asks for help with X, the solution they have already chosen, instead of describing Y, the thing they actually need to achieve. The person helping spends an afternoon making X work, and X was never going to solve Y. The pattern is old, well documented, and it scales perfectly from a support forum to a seven-figure programme.

Expertise markets are built on a gap the buyer cannot close

There is a category of goods where the buyer cannot judge what he needs before the purchase, and often cannot judge what he received after it. Economists call them credence goods. The canonical examples are doctors, mechanics and computer specialists, which is a list worth reading twice if you buy technology advice for a living.

Uwe Dulleck and Rudolf Kerschbamer laid out the mechanics in the Journal of Economic Literature in 2006. When the expert also diagnoses, three things can go wrong that the customer cannot detect: he can be treated for something he did not have, he can be charged for work that was not performed, and he can be under-treated on the thing he did have. All three survive a perfectly polite transaction. All three are compatible with an expert who is technically excellent.

Notice what the model assumes. It does not assume fraud. It assumes that the person who tells you what you need is the same person who gets paid for providing it. That single overlap is enough to produce the outcome, with or without bad intent, in a market full of competent professionals.

Corporate technology buying is that structure with better slides. The vendor scopes the requirement. The integrator validates the architecture. The recruiter defines the profile. Each of them is the most qualified voice in the room on their own subject, and each of them is describing a need whose fulfilment they will invoice.

The formal name for the rest of it is the principal-agent problem: the agent acts on the principal’s behalf, the two sets of interests do not fully overlap, and the principal lacks the information to monitor the gap. Nothing exotic. It is the default condition of every advisory relationship, and it is managed by structure, not by character.

Procurement rigour starts one step too late

Most organisations that buy badly are not sloppy. They are rigorous, one step downstream of where it matters.

Look at how a decision of this kind is actually handled in a serious company. A requirement document is written and reviewed. Three suppliers are consulted rather than one. Responses are scored against weighted criteria. Legal reviews the contract. A steering committee is set up with named sponsors and a reporting cadence. Every single one of those controls is a good control, and together they produce an audit trail that would survive any inspection.

Not one of them examines whether the requirement is the right requirement.

The controls start at the requirement and work forward. They test whether the chosen supplier can deliver what was asked, whether the price is competitive, whether the risk is covered, whether the programme is on track. They are all comparative. They assume the object of comparison is correct, because by the time the process begins, the object has already been fixed by a sentence somebody said in a meeting weeks earlier.

This is why the failure is so hard to see from inside. The organisation experiences itself as disciplined the entire way through, and it is right. The discipline simply begins on the wrong side of the only decision that could not be reversed later.

There is a practical consequence worth stating plainly. The cheapest possible intervention on a programme of this type is an hour spent before the requirement is written, and the most expensive is the same hour spent after go-live. The value of the question decays to almost nothing the moment budget is committed, because from then on the question threatens sunk cost and personal credibility rather than a hypothetical.

Nobody’s process schedules that hour, and nobody’s invoice contains it.

Nobody at the table is positioned to disagree with you

Take an actual decision and list the participants.

The software publisher wants the licences. The integrator wants the deployment. The recruitment firm wants the placement. The services company wants the days. Internal IT has a professional opinion and also a career, and the two are not always separable. The executive committee has already approved a direction and does not enjoy reopening it. The consultant who framed the programme has his name on the framing.

Now cross out everybody who loses nothing by telling the chief executive his stated need is wrong.

The list is usually empty. Not because these people are dishonest, but because none of them occupies a position from which the sentence can be said without cost. Asking a supplier to challenge the brief is asking him to argue himself out of a signed order, in front of a client who may well read the objection as a lack of competence.

So the chief executive gets consensus. Ten qualified professionals agreed with the plan. He reads that as confirmation. What he is hearing is ten commercial processes that all begin with his yes.

A case: the close that stayed at three weeks

A manufacturing group, around six hundred people, three production sites, two of them acquired within the previous decade. The finance director had a concrete and unarguable problem: the monthly close took three weeks. Figures for month N landed on the executive committee’s desk near the end of month N+1, by which point they were commentary rather than management information. Decisions were being taken on a picture of the past.

The stated need was formed quickly and it sounded right. The ERP is old, it dates from before the acquisitions, it does not consolidate the sites properly. We need to replace it.

Everybody agreed. The incumbent publisher agreed, and had a modern suite. Two integrators agreed, and both quoted. The auditor agreed in passing, because a modern ERP is never a bad idea. The IT manager agreed, partly because he had wanted to replace that system for four years. The executive committee agreed because three weeks is obviously too long and here was a plan to fix it.

The programme ran fourteen months. By any delivery standard it was a success. Scope held. The overrun was under ten per cent. Data migration was clean, training was done properly, the integrator’s team was good and the finance team did not revolt. The go-live weekend was uneventful, which in that business is the highest available compliment.

The first close on the new system took three weeks and two days.

The second took three weeks. The third took three weeks. A year later, it was still three weeks.

The three weeks had never been in the software. They were in the inputs. The two acquired sites booked their supplier invoices on their own local rhythm, one weekly, one when the plant manager got around to it, because that had been the practice before the acquisition and no one had ever changed it. Stock counts at the third site were entered by a single person who also ran the warehouse, and she entered them when the warehouse allowed her to, which was after the twelfth of the month. Intercompany transfers were reconciled by hand in a spreadsheet by one controller, and the spreadsheet had grown a set of rules that existed nowhere else.

The close did not start when the month ended. It started when the last of those three things arrived, and that date was structurally around the fifteenth. Everything after it was fast. Everything before it was outside the system entirely.

A new ERP could not move that date. No ERP can. The constraint was an operating agreement between four sites that had never been written down, let alone renegotiated.

What it cost is worth itemising, because only one line of it appears in any accounting system.

The programme itself, licences plus integration plus internal time, was the visible number and the smallest problem. Fourteen months of the finance team’s attention was the second line: during that period the group did not touch its pricing structure, did not rebuild its cost accounting, and postponed a site consolidation study that had been scheduled. The third line was political. The finance director had spent his personal credit inside the executive committee to get the programme approved, and after delivery the figures still arrived at the end of month N+1. He was now the person whose big project had not worked. Two years later he was no longer with the group.

The fourth line is the one that makes the pattern self-sustaining. Since the close was still three weeks after a successful ERP implementation, the conclusion drawn internally was that the problem must be deeper. A consolidation tool was evaluated. A business intelligence layer was proposed on top of the new system. A finance transformation programme was sketched. Each of these was a reasonable proposal, sold by capable people, aimed at the same wrong target, and each one now had a better argument than the last because it came from suppliers who knew the house.

The entire sequence could have been stopped by one person, in one afternoon, before anything was signed, by asking what was actually happening between the last day of the month and the day the first consolidated figure appeared. That afternoon was not on anybody’s invoice, so it did not happen.

A wrong diagnosis does not cancel, it compounds

The dangerous property of the wrong diagnosis is not the first bill. It is that a clean delivery of the wrong thing produces evidence for buying more of it.

When a project fails visibly, an organisation stops and asks why. When a project succeeds visibly and the underlying problem persists, the organisation does not question the diagnosis, because the diagnosis was never on trial. It questions the dose. Phase two. An additional module. A bigger team. More of the same remedy, argued now by people with real knowledge of the environment, which makes them more persuasive than they were the first time.

The company is now on a trajectory that moves steadily away from its actual subject, at constant speed, with everybody’s agreement, and with a paper trail that looks like good governance the whole way.

Theodore Levitt made the point about companies defining themselves by their product instead of the need they serve. The buying side has the same disease. A business that defines its problem as the absence of a tool will keep buying tools. Christensen and his co-authors put the same idea on the customer’s side of the table: people hire a product to do a job, and the job is not the product. If you never articulate the job, you will be sold the product, correctly, at full price, forever.

Telling the truth here has a price and it is paid by the wrong person

The mechanism only breaks if somebody says the stated need is wrong. That sentence is expensive to say.

The person saying it gives up the mission in front of him. He accepts being read as difficult, or as unable to deliver. He offers, for free, the most valuable thing he has in the exchange, which is the diagnosis. And he does it at the exact moment he has the least credibility to do it, because he has not worked with the company yet.

There is no altruism in any of this. It is a position. Either you are structured so that you can afford to say no, or you are not, and if you are not, your opinion on the client’s real need is worth precisely nothing, whatever your competence. That is the uncomfortable part. Independence is the scarce input here. Competence is available everywhere, at market rate.

Which is why the test a chief executive should apply is not about expertise. It is simpler than that.

Ask what happens to the adviser if the answer is no

Before signing anything, there is one question worth an hour of anybody’s time. Not put to the supplier. Put to yourself, about each person advising you.

If the honest answer to my problem is that I should do nothing, or something small, or something entirely different from what I have described, what does this person lose by telling me?

Where the answer is nothing, listen carefully. Where the answer is the mandate itself, discount accordingly. That is arithmetic about positions rather than cynicism about people, and it is the only part of this whole structure the buyer actually controls.

The garage that puts your car on the lift before answering is not more virtuous than the one that changes your brakes on request. It is arranged differently. You cannot inspect virtue. You can inspect arrangements.

Sources

FAQ

What is the XY problem, and how does it apply to corporate technology purchases?

The XY problem is when someone asks for help with X, the solution they’ve already chosen, instead of describing Y, the actual thing they need to achieve. In companies, a consequence (month-end takes three weeks) gets translated in seconds into a remedy (we need a new ERP), and within two weeks nobody is discussing the consequence anymore — only the remedy’s vendor shortlist. The pattern scales from a support forum to a seven-figure programme, and every control in a rigorous procurement process starts one step after the only decision that mattered: whether the stated requirement was the right one.

Why can't the suppliers and advisors in the room be trusted to say your stated need is wrong?

Because credence goods economics (formalized by Dulleck and Kerschbamer in 2006, using doctors and mechanics as the canonical examples) shows that when the same party diagnoses and profits from treatment, three failure modes become undetectable by the buyer, with or without bad intent. In a real buying decision, the vendor wants the licences, the integrator wants the deployment, the recruiter wants the placement — cross out everyone who loses nothing by telling you your stated need is wrong, and the list is usually empty. The question to ask isn’t about anyone’s competence; it’s what each adviser loses if the honest answer is ‘do nothing, or something else entirely.’