Orders keep missing their delivery deadlines. The team stays late, adds another check and eventually asks a colleague for help. Things improve for a few days, but the delays return. Each measure addresses something visible, yet no one knows why the problem keeps happening. How do you work out what needs to change when several explanations seem plausible?
With complex problems, the main challenge may not be a lack of ideas. It is often harder to distinguish an observed outcome from an assumed cause, test your explanation and avoid creating new difficulties with the fix. This way of thinking can be applied to work processes, household responsibilities and personal habits.
A symptom does not tell you what caused the problem
If customers complain about slow service, the complaints are an observable sign. The cause might be unclear instructions, a wait for approval, incorrect information or a combination of obstacles. Simply working faster may not remove any of them.
It helps to distinguish three levels. A symptom is what is happening and causing difficulty. A possible cause is an explanation that still needs to be tested. A contributing condition is something that makes the problem worse or allows it to occur, such as a heavy workload over a short period. These levels can overlap, but they are not interchangeable.
There may not be one hidden root cause. Sometimes a problem occurs only when two manageable circumstances coincide: late changes to an order and the absence of the person who usually processes them. So do not look for a single person to blame or insist on one definitive answer.
Define the problem precisely first
A general statement such as “the whole system isn’t working” tends to lead to general fixes. A more precise description helps you work out where to look and what improvement would actually mean. Before discussing solutions, write down what happened, where and when it happened, and under what conditions.
These four questions can help:
- What exactly is going wrong? For example, orders are leaving after the agreed deadline, rather than simply “we have too much work.”
- When does it happen? Only with urgent requests, at the end of the week or on ordinary days too?
- Who and what are affected? Customers, another team, costs, quality or people’s personal time?
- When does the problem not happen? Exceptions may reveal a condition you would miss if you looked only at problem cases.
If you do not have reliable data, say so. Instead of claiming “it always happens in the afternoon,” note that “so far, it seems to happen more often in the afternoon.” The difference between a finding and an impression affects what you should do next.
Map the sequence of events and look for connections
Write down the steps in order: receiving a request, checking the information, getting approval, doing the work and handing it over. At each step, identify who is waiting for whom and what information is needed to move forward.
Be careful not to mistake a sequence for proof of cause. If delays started after a software change, that does not automatically mean the new application caused them. Approval rules or workload may have changed at the same time. Timing is a clue, not proof of causation.
If the problem keeps recurring, look at feedback loops too. A delay may lead to urgent calls, which interrupt work and create further delays. In that case, simply pressing people to work faster will not help; you also need to break the cycle that is sustaining the problem.
Develop several explanations you can test
The first explanation can be tempting, especially when it fits your experience. But experience alone does not establish what is happening this time. Before choosing a fix, come up with at least two or three hypotheses.
For recurring delays, possible explanations might include:
- Tasks arrive late: Most of the time is lost before processing even begins.
- Information is incomplete: Staff have to return to the same order repeatedly.
- One step is overloaded: Other parts of the process have capacity but are waiting for the same approval.
- The plan does not account for exceptions: Routine operations work, but several urgent requests at once disrupt them.
A good hypothesis is more than a plausible story. It also answers the question: What should we observe if this explanation is correct? For incomplete information, for example, you should be able to find repeated requests for missing details. If approval is overloaded, you should see long waits at one point in the process.
Choose a test that could change your mind
Not every effort to collect information helps you decide. A long list of data points can create an impression of rigour without showing which of several possible causes is more likely. First identify the uncertainty that matters most to your choice of action. Then look for the smallest safe test that can reduce it.
The right way to test an explanation depends on the situation. You could follow a few specific cases from beginning to end, observe where a task gets held up, compare problem-free days with difficult ones or temporarily change one rule. If you change staffing, deadlines and forms all at once, it will be hard to tell what made a difference.
Before trying a change, agree on what would count as improvement and what side effects you need to watch for. It is not enough for one task to be completed faster. The number of corrections might rise, quality might fall or the wait might simply shift to another colleague. A short-term success does not necessarily mean the problem is solved.
In situations where a mistake could harm people’s safety, health, finances or rights, do not run untested experiments just to get a quick answer. It is more appropriate to follow an approved process, seek expert assessment or begin with information that will not put operations at risk.
A worked example of recurring shipment delays
Consider a hypothetical situation at a small company. Shipments go out late several times a week. The manager assumes packing takes too long and proposes adding another person to the afternoon shift. A colleague believes the problem starts with the orders. Both explanations are possible, but for now they are only assumptions.
The team decides to review a selection of late and on-time shipments. For each one, they record when the order was received, when its information was complete, when packing began and when it was handed to the carrier. Instead of asking who worked too slowly, they look for the point where the process stalled.
| Observation | Possible explanation | What to check |
|---|---|---|
| Packing starts late | Goods or information are not ready | When the order was actually ready |
| Some shipments have to be packed again | Instructions change during the work | How many changes are made, and when |
| There are no delays on ordinary days | A combination of exceptions is causing difficulty | The difference between ordinary and demanding days |
| Packing is finished on time, but collection is late | The obstacle occurs during handover | How long the shipment waits between packing and collection |
In this hypothetical example, the team finds that shipments often wait for missing information. The company therefore tries checking required fields when an order is received. It also monitors whether this creates a new delay.
If delays decrease, that supports the hypothesis, but it does not prove that every cause has been identified. If delays continue, the team needs to test another explanation. Even a disproven idea can prevent the expense of making the wrong fix.
Fixing one step can make another worse
In complex tasks, different parts affect one another. Shortening the approval process might speed up handover, but it could also remove a check that catches important errors. Adding a verification form might reduce missing information while delaying straightforward cases that do not need another check.
Before making a change, ask: Who will have to work differently? Where will the time or effort shift? What happens when there is an exception? Which improvement will be visible immediately, and which effects might appear later?
When to act, gather more information or ask for advice
You can try a limited measure when the change is small and easy to reverse. For an expensive or difficult-to-reverse intervention, it is wiser to test the key assumptions first.
- Make a small change: when you can safely reverse it and have a clear way to assess its effect.
- Find out more: when the possible causes differ and each would require a completely different solution.
- Ask for another perspective: when the problem is beyond your experience or the decision affects people whose needs you do not fully understand.
- Stop improvising: when an unsuccessful attempt could cause serious or irreversible harm.
It is also important to acknowledge when you do not yet have an answer. “We know where the problem shows up, but we don’t know why yet” is more accurate than a confident explanation without supporting evidence. That kind of honesty makes collaboration easier: others can contribute useful information instead of feeling they have to defend their own views.
What a problem can teach you about your own thinking
Personal growth in problem-solving is not just about learning a new method. It also helps to notice your own habits: do you look for a definitive fix too soon, rely on the first familiar pattern you see, try to investigate every last detail or wait for someone more experienced to decide? None of these approaches is automatically wrong; the situation matters.
After resolving a problem, briefly note three things: which explanation you thought was most likely, what supported or weakened it, and what you would check sooner next time. The notes do not need to be detailed. Their purpose is to help you distinguish a decision made for good reasons from one that happened to turn out well.
An unfavourable result does not always mean the whole process was flawed. Even a reasonable decision can go badly when information is incomplete. Conversely, one-off success does not justify untested assumptions. Assess the quality of your reasoning separately from the outcome.
When a problem that seemed “solved” returns, write down exactly what is recurring, two possible causes and what observation could distinguish between them. Then decide on the next fix.
