What if the problem is not where it appears?

When an organisation looks for help with a problem, the request often already contains an explanation of where it comes from. “We need to improve the invoicing process.” “We have a problem with the team.” “We are missing a tool.”

These are legitimate requests, usually built on real difficulties. But there is an important difference between identifying what is not working and understanding why it is happening. And when we accept the initial explanation without questioning it, we run the risk of developing a good solution to the wrong problem.

The problem we see may not be the problem we need to solve

Before it reaches the board or an outside partner, a difficulty has often passed through several interpretations. Each person describes what they observe from their own role, from the information they have access to and from the consequences they feel day to day. When those perspectives are gathered into a single request, part of the original complexity inevitably disappears.

That simplification is useful for starting a conversation, but it should not be confused with a finished diagnosis. The way we define the problem shapes the people we involve, the data we look for and the solutions we begin to consider.

Imagine a company whose invoicing is systematically late at the end of each month. At first sight it looks like a finance department problem. But following the process through, we find that the information needed arrives late because nobody asks for it in advance. That responsibility was never clearly assigned, and the organisation grew without revisiting how the work was distributed.

The delay shows up in invoicing, but its origin may lie in how responsibilities are defined and how teams work together. Improving only the final step may reduce the delay for a while without removing what causes it.

That is why I think it matters to distinguish the place where a problem becomes visible from the set of circumstances that gives rise to it.

When should we question the initial diagnosis?

Some situations call for a closer look. A problem that reappears after repeated fixes may indicate that we are acting on its effects. A request framed straight away as a technology solution may mean the tool was chosen before the need was understood. And when different areas describe the same difficulty in incompatible ways, we may be looking at distinct parts of a broader problem.

None of these signs proves that the initial diagnosis is wrong. But each of them deserves further questions.

It also matters to understand when the difficulty began, what changed in the organisation and what attempts at a fix have already been made. Those answers often help to tell a one-off incident from a more structural weakness.

The aim is not to stretch the diagnosis phase out indefinitely. It is to stop the urge to act from leading us to treat as true an explanation that has not yet been tested enough.

Looking at the organisation as a whole

To understand a business problem, I find it useful to look at five dimensions that influence one another: people, processes, information, technology and management.

• People: who decides, who executes, who depends on the work of others, and what knowledge exists only in individual experience.
• Processes: how the work is meant to happen and how it actually happens, including adaptations and informal workarounds.
• Information: what data exists, how it circulates, who has access to it and whether it arrives in time to support decisions.
• Technology: which tools help the work get done and which may be adding complexity without solving the original difficulty.
• Management: what priorities are set, how responsibilities are distributed, and which situations are followed up or left unanswered.

These dimensions do not work in isolation. A breakdown in how information circulates can lead a team to create an informal procedure. Over time, that procedure can come to depend on a single person. If that person leaves, the problem is no longer only about information: it now also involves operational continuity, knowledge and management.

Looking at a single dimension may be enough to identify the most obvious symptom, but it does not always reveal the relationships that keep it in place. Some of the most significant opportunities for improvement may lie in exactly those relationships.

Listening to those who know the problem from different places

A diagnosis should not be limited to the people who framed the request. It matters to talk as well with those who do the work, receive the results, depend on other teams, or have found alternative ways around difficulties.

Those at the end of a process can often identify the accumulated effects of earlier decisions. Whoever created an informal workaround knows where the intended procedure stopped meeting the need. And someone who has recently joined the organisation may question practices that everyone else already takes for granted.

These perspectives should not be treated as isolated truths. They need to be set against one another and against the available information. Conversations help to form hypotheses; data makes it possible to assess their consistency, frequency and scale. Sometimes the data reveals that a widely shared perception does not match what happens in most cases. At other times it shows that the existing indicators fail to capture a difficulty people know well.

What matters is creating the conditions to understand reality before deciding how we want to change it.

Questioning without dismissing the problem

Revisiting a diagnosis does not mean dismissing the experience of the person who asked for help. On the contrary: it is recognising that a difficulty can be real even when the initial explanation is still incomplete.

A simple way to start is to separate what we know from what we are assuming. The invoicing delay may be a fact; the idea that it stems from a lack of capacity in the finance team is a hypothesis. That hypothesis should be explored, neither accepted nor rejected automatically.

We can ask in which situations the problem occurs, whether it also appears in other areas, what changed before it began, and what evidence would lead us to revise the initial explanation. These are questions that challenge assumptions without turning the conversation into an argument about who is right.

The aim should be to reach a shared understanding of the problem: solid enough to guide the work, and open enough to be revised when new findings emerge.

Solving better starts with understanding better

Questioning the diagnosis may require more time at the start of a project. It may mean listening to people who were not on the list, revisiting assumptions, or discovering that the solution first imagined is not the most suitable one.

But that investment can prevent later changes, reduce resistance and help concentrate resources on what actually needs to change. It also makes it easier to explain the decisions taken and to assess whether the work addressed the identified cause or merely reduced its effects for a while.

This does not mean every project needs an extensive diagnosis. In many cases one more conversation, watching a process, or a simple test is enough to put a hypothesis through its paces.

Perhaps the most useful question, before we move to a solution, is this: are we solving the problem that exists, or only the one we are able to see?