The Problem May Live Somewhere Else

The Problem May Live Somewhere Else

The place where a problem becomes visible is often not the place where it began.

An organisation chart is not a causal model, yet organisations frequently use it as one. Equipment fails and maintenance receives the action. A project runs late and project management is asked for recovery. Margin falls and sales or procurement must explain it. This is administratively sensible, because somebody has to own the response, but ownership and origin are not the same thing.

Complex systems distribute causes over time. A maintenance failure can begin with a design decision taken before the maintenance team existed. A procurement issue can originate in a specification so restrictive that competition was removed before procurement was involved. An operational difficulty can follow from a project decision made to protect schedule. By the time the consequence appears, the people responsible for the original trade-off may have moved on, and the problem attaches itself to whoever stands closest to it now.

Expertise reinforces the effect. Specialists are trained to solve the problems presented to them, and their competence makes them effective once a problem has been assigned. It also makes the assignment itself harder to see. A problem labelled as maintenance quickly acquires maintenance data, maintenance language and maintenance solutions, and the more work follows, the more obvious the label looks.

Technical failure analysis offers the contrast. A damaged bearing is rarely accepted as its own explanation; the investigation moves back through lubrication, alignment, loading, installation and operating conditions until the sequence makes sense. The visible failure is treated as evidence, not as explanation. Organisations seldom apply the same discipline to non-technical problems. They stop at the department boundary, as though causes respected it.

A better investigation follows the work rather than the reporting line. What conditions had to exist for this problem to appear? Which earlier decisions created them, and what information was available at the time? Which trade-offs were deliberate and which emerged by accident? Where did one function hand an assumption to another without either realising it? The resulting map usually looks very different from the formal process diagram.

The distinction also protects people from unfair accountability. A team repeatedly blamed for conditions it did not create learns to defend itself rather than reveal problems early, while upstream decision-makers whose choices are never connected to downstream consequences have no reason to change them. Accountability that follows influence as well as ownership avoids both. Local responsibility remains: maintenance must still respond to failure and operations must still control the process in front of it. But restoring performance and learning from the system are different tasks, and only the second reduces the chance of recreating the same condition elsewhere.

The practical habit is easy to describe and harder to maintain. When a problem arrives in a department, ask what had to happen before it could arrive there. Sometimes the answer confirms that the department owns both symptom and cause. When it does not, the organisation has learned something more valuable than a fix: the problem is travelling through the structure, and asking one function to manage it ever more efficiently will not stop it from arriving again.