How to find the real cause of poor operational performance.

When performance slips, explanations arrive quickly. The team needs training. The system is slow. Customers are more demanding. Someone suggests a new dashboard, which at least gives everybody something colourful to disagree about.

Any of those explanations might contain some truth. The expensive mistake is treating one as established before investigating it.

For business owners and operational leaders, the aim is to decide what deserves attention before committing people, money or technology. DeaconOps’s starting point is to examine how the result is being produced, including the conditions people are working within.

1. Why the obvious explanation may be wrong

A restaurant receives complaints about slow service. The waiting staff are visible, so they receive instructions to move faster. Meanwhile, every order needs approval from the same busy chef.

The people carrying the plates were never in charge of the queue.

Operational symptoms often appear somewhere different from their cause. Missed deadlines may reflect incomplete inputs, delayed decisions or conflicting priorities upstream. The person who closes the case inherits those conditions without necessarily being able to change them.

I’d distinguish the point where the problem becomes visible from the conditions that make it likely. That is an investigation question, not a presumption that individuals never make mistakes. Starting with blame narrows the evidence before you have collected it.

2. Define the performance problem before choosing a solution

“The operation needs to be more efficient” is rather like telling a mechanic that the car needs to be better. It communicates dissatisfaction without locating much.

What is happening, to whom, and compared with what expectation?

A useful problem statement identifies the outcome, the affected work, the period and the scale. For example: completed applications are taking longer, particularly those requiring specialist approval. That is more investigable than “the team is slow”.

Separate the desired result from a preferred intervention. Buying a system is a possible response; it is not the problem statement. Agree definitions for completion, delay and error so that teams are examining the same thing.

Without that agreement, a meeting can contain several accurate reports about different problems.

3. Separate demand, capacity, capability and process

An overflowing washing basket could mean more laundry, a broken machine or someone repeatedly washing the same towels. Purchasing another basket offers limited analytical value.

Workloads also grow for different reasons, and they need different responses.

Demand concerns what arrives and why. Capacity concerns the usable resources available. Capability concerns whether the necessary skills, information and tools exist. Process concerns how those resources turn requests into outcomes.

These categories interact. Experienced people may have enough theoretical capacity but lose it correcting poor inputs. A change in case complexity can reduce completions without any decline in effort.

I’d compare the mix of incoming work, the skills it requires, actual available time and where that time goes. A headcount total alone cannot settle whether there is a capacity shortage.

4. Follow actual work through the business

The process document says a request moves neatly from A to B. The actual request visits a shared inbox, two spreadsheets and someone called Sarah, who knows which spreadsheet is current.

Both versions deserve attention. Only one explains today’s experience.

Take a sample of completed, delayed and returned items and reconstruct their journey. Look for decisions, waiting, corrections, transfers and unofficial workarounds. Include routine cases as well as the memorable disasters.

This is process discovery through observation. It can reveal differences between the prescribed method and the adaptations necessary to get work done.

Those adaptations are evidence. Removing a workaround before understanding what it protects can expose the business to the original problem again. Ask what made it necessary and whether that condition still exists.

5. Compare the reports with the experience of the teams

The dashboard says work is allocated within a day. The team says some requests wait a week. Before deciding who is wrong, check when the clock starts.

A measure beginning after allocation can be perfectly accurate while excluding the delay everybody is discussing.

Operational data needs context: definitions, timestamps, missing records, changed categories and the point at which work enters the measurement. Staff experience can reveal blind spots, while records can test whether a familiar frustration is widespread.

I’d reconcile both views using actual examples. Neither a persuasive anecdote nor an attractive chart should settle the diagnosis alone.

The goal is a shared explanation of the operation, including where the available evidence remains incomplete.

6. Test explanations rather than collecting opinions

Asking “why?” is useful. Asking it five times does not turn the last answer into scientific proof.

If the chain ends with “people need to care more”, you may have reached a management opinion rather than a root cause.

The Five Whys and cause-and-effect diagrams help organise investigation. Their limitation is that a plausible chain can be mistaken for an evidenced one, particularly where several conditions interact.

State a hypothesis and ask what you would expect to observe if it were true. If missing documents cause delays, are affected cases slower than comparable complete cases? Were the documents absent before the delay began?

Check alternatives and contradictory examples. A convincing explanation should account for the pattern, not simply fit one unfortunate case.

7. Distinguish a persistent system problem from an unusual event

One difficult Monday should not automatically trigger a new operating model. Equally, six difficult months should not be dismissed as another unusual Monday.

Patterns over time help separate those situations.

W. Edwards Deming’s treatment of variation distinguishes persistent causes inherent in a process from identifiable unusual circumstances. The distinction matters because a stable but inadequate process needs a different response from an isolated disruption.

Review trends with sufficient context, including volume, case mix, staffing and changes in method. Avoid reacting to every movement as though it represents a new cause.

A poor result still matters. Understanding its pattern helps decide whether to investigate a specific event, redesign part of the process or do both.

8. Decide what to address first

A diagnosis can produce a long list. So can an afternoon spent walking around with a clipboard. The useful part is deciding what depends on what.

Fixing every issue at once can overwhelm the same people who are already struggling.

Prioritise according to customer impact, operational risk, the constraint on completion and the feasibility of the intervention. Distinguish containment needed now from changes that remove recurring causes.

Recommendations should explain the evidence, expected mechanism, dependencies and how success will be checked. Where confidence is limited, a small test may be more appropriate than a full rollout.

DeaconOps’s Operational Diagnostic provides this structured investigation and a practical report with prioritised recommendations and a sequenced action plan. If the cause is disputed or crosses departments, start a conversation about the symptoms.

Questions about diagnosing poor performance

Does poor performance always mean the process is broken?

No. Demand changes, skills gaps, resource shortages and individual errors can contribute. Investigate the evidence before deciding which explanation applies.

What if we do not have reliable operational data?

Use the records available, observe actual work and identify the gaps. Any conclusions should reflect the strength and limitations of that evidence.

How is this different from a performance management meeting?

A diagnostic examines how the operation produces its outcomes across teams, systems and decisions. A performance management meeting may focus on a particular person or team. They can inform one another but serve different purposes.

---

About the author

Dean Cain is the founder of DeaconOps, with more than 15 years’ experience across operational delivery, leadership and regulated environments. Read about the DeaconOps approach.