What if the problem is not where it appears?

Almost every request that reaches us arrives already solved. Not finished, of course, but carrying a theory about the cause inside it. “We need to improve the invoicing process.” “We have a team problem.” “We are missing a tool.”

That theory is useful, and it is also the first thing to examine. A well-framed request is usually the end of a line of reasoning someone has already done, and the work that follows never turns out better than that reasoning.

Why does a request already carry the diagnosis inside it?

Because nobody asks for help raw. Between sensing that something is wrong and being able to explain it to an outsider, an organisation does a great deal of interpreting: it gathers what several people saw, drops what it cannot explain and turns the rest into a sentence that can be said in a board meeting without sounding confused.

That work is legitimate, but it has a cost. The sentence that survives is the easiest one to say, not necessarily the truest. And from the moment it exists, it decides everything else: who comes to the meeting, which data gets asked for, which solutions get put on the table.

So accepting that sentence without examining it is not trusting the client. It is inheriting someone else’s diagnosis and becoming responsible for it.

Where does a problem appear, and where is it born?

A problem shows itself where it is visible, and that rarely coincides with where it begins. Think of invoicing that slips at every month end. It slips because the information it depends on arrives late. It arrives late because nobody asks for it in time. Nobody asks because that responsibility was never assigned. And it was never assigned because, three years ago, the organisation grew faster than its own design.

Each step in this chain is invisible from the step above it. Whoever deals with the delay sees an invoicing problem and, from where they stand, they are right. Only someone looking at the whole chain sees that the origin has nothing to do with invoices.

That is why fixing the symptom usually settles the matter for a quarter. Then the problem comes back somewhere else, and by then with less patience from whoever is paying.

Which signs suggest that a request’s diagnosis may be wrong?

Four signs tend to turn up together: the problem was fixed once before and came back, the solution being asked for is a tool, each department describes the problem differently, and nobody can say when it started. None of them proves the diagnosis is wrong, but any one of them justifies a second look.

A problem that returns after being fixed is the strongest sign: if the fix worked and the effect came back, the cause was left intact. A request that arrives already shaped as a tool skips a step, because it picks the answer before the question has been defined. When finance talks about delays, operations talks about being short-staffed and the sales team talks about difficult clients, they are probably all describing different parts of the same thing. And when nobody can date the beginning, the problem is usually older and more structural than the request suggests.

Which dimensions have to be examined to find the cause of a problem?

Five, and at the same time: people, processes, information, technology and management. There is no test that locates the cause. There is the discipline of looking at all of them at once, instead of walking through them one at a time and concluding too quickly.

• People: who decides, who executes and who knows what was never written down.
• Processes: the distance between what was designed and what actually happens.
• Information: what exists, what circulates and what arrives in time to change anything.
• Technology: what actually solves, and what merely adds a layer on top of the problem.
• Management: what gets measured, what gets prioritised and what is simply left to happen.

None of these dimensions fails on its own. An information gap becomes a process problem the moment somebody invents a workaround for it. That workaround becomes a people problem when the only person who knows how to use it leaves the company. And that departure becomes a management problem when it turns out nobody was measuring any of it.

Diagnoses made from a single dimension almost always get the effect right and the cause wrong. Not for lack of rigour, but for lack of field of vision.

Who has to be spoken to for a good diagnosis?

With more people than the ones who made the request, and above all with those at the ends of the chain: whoever receives the work late, whoever gets it done through workarounds and whoever arrived recently. Whoever asks for help describes the problem from the place where they feel it; the other voices show where it travels before it gets there.

People who work through workarounds know exactly where the designed process fails, because that failure is what forces them to improvise. People who arrived recently still find odd what everyone else has stopped seeing. And people at the end of the chain feel the accumulated effect of everything that happened before.

Data comes in here as counter-evidence, not as a starting point. It shows what happens, how often and at what volume, but it rarely explains why. The conversations give you the hypotheses; the numbers tell you which ones hold up.

How do you question a client’s request without breaking trust?

Three ways rarely offend anyone: separating what was observed from what was concluded, looking for the same cause somewhere else, and asking what would have to be true for the hypothesis to be wrong. None of them is a polite way of disagreeing. They are the only way not to spend six months executing the wrong thing perfectly.

The first is the simplest: “the delay is a fact, the cause is a hypothesis” is a sentence almost nobody contests. The second puts the explanation to the test, because if it is right the same effect should show up wherever the conditions repeat; if it does not, something is missing. The third makes it possible to challenge the hypothesis without pointing a finger at anyone.

The goal is not to be right against the client. It is to arrive, together, at a description of the problem that both can defend.

Where this problem usually shows up

What changes in a project when the diagnosis is questioned from the start?

At first it looks like a change for the worse: the first presentation takes longer to arrive and there is always someone asking when the actual work starts. The gains come later.

The plan no longer needs revising in month two, because it does not rest on a hypothesis that has since collapsed. The people who could have stopped the project helped define the problem, and no longer have reason to stop it. And when the result arrives, you can explain why it arrived, which is the difference between a project that can be repeated and one that owes itself to luck.

The question costs one uncomfortable conversation at the start. It usually saves several later.