Problem Solving

Most organisations are good at reacting to problems. Fewer are good at solving them. The Problem Solving pillar builds the discipline to find the real problem, understand why it is happening, and fix it in a way that holds.

I have watched the same problem get solved three times in the same organisation.

Not because the first two fixes failed. Because the first two fixes addressed the symptom. The third time, someone stopped long enough to ask what was actually wrong. That conversation took forty minutes. The fix took a day. The problem did not come back.

Most problem solving in operations is fast. A deviation is found. A cause is assumed. A countermeasure is applied. The number improves. The team moves on.

The problem with fast problem solving is that it is often solving the wrong problem. The cause that was assumed is not the cause that was real. The countermeasure addresses the visible symptom and leaves the mechanism untouched. Two months later the same deviation appears. The same cause is assumed. The same countermeasure is applied.

The initiative graveyard is not only filled with improvement programmes that did not hold. It is filled with problems that were never properly defined.

Pillar Intent

The Problem Solving pillar exists to build the capability to find the real problem and fix it permanently.

That means slowing down at the beginning, long enough to define the problem precisely, check whether it is a standards issue before assuming it is a root cause issue, and understand why the problem is happening before deciding what to do about it.

It means selecting solutions based on evidence, not instinct. Testing them before committing. And putting in place the three things that make a fix hold: a documented standard, a visual signal, and a leadership response when the standard is not being met.

This pillar works alongside Leadership and Process Improvement. Leadership builds the routines that catch problems early and escalate them to the right level. Process Improvement defines and standardises the work. Problem Solving removes the causes that prevent the standard from being met. Each pillar depends on the others. None of them replaces the others.

Go to the Leadership pillar →

Go to the Process Improvement pillar →

Pillar Owned Losses

The losses for not having a Problem Solving process that fixes the real problem, forever, appear as recurring defects, repeated escalations, and improvements that deliver a result and then drift back. The causes are almost always the same.

⚠️

The wrong problem is solved. The symptom is addressed. The mechanism is not. The problem returns in a different form, on a different line, in a different month. The team investigates again. The same countermeasure is applied again.

⚠️

The cause is assumed, not found. The team knows from experience what usually causes this kind of problem. They apply the usual fix. Sometimes it works. When it does not, the investigation starts again from the same assumption.

⚠️

The fix is not validated. A countermeasure is implemented. The result improves. The team moves on. Nobody checks whether the improvement was caused by the countermeasure or by something else that changed at the same time. When the result drifts again, the team does not know whether the fix failed or was never properly tested.

⚠️

The fix does not hold. The countermeasure works. The result is confirmed. Six months later the problem is back. The standard was not documented. The visual was not in place. Nobody was checking. The fix was an event, not a change.

⚠️

Problem solving capability stays with one person. The person who is good at finding root causes becomes the person who is called whenever something goes wrong. The team watches. The capability does not spread. When that person leaves, the organisation loses its ability to solve problems at depth.

These are not random failures. They are structural. They are what happens when problem solving is treated as a reaction rather than a discipline.

Pillar Owned Capabilities

The Problem Solving pillar builds capability in the people and the process needed to find and fix every loss it owns.

Process capabilities

One primary process. Six stages. Applied consistently whether the problem is a recurring defect, a planning failure, or a process that keeps drifting back.

Problem Solving (PS): The six-stage discipline for defining, understanding, investigating, fixing, and sustaining the resolution of a problem. The tools used at each stage are appropriate to the problem type and complexity, they are used when needed only and not forced into the process.

Go to the Problem Definition guide →

People capabilities

Leaders and teams at every level who can define a problem precisely, investigate it systematically, and implement a forever fix.

Frontline leaders who can write a specific, measurable problem statement, check the standard before assuming a root cause, and test a countermeasure before declaring it successful.
Department and area leaders who coach the problem-solving process rather than providing the answer, and who ensure that recurring problems are escalated with a proper problem statement.
Site and function leaders who set the expectation that problems are defined before they are solved, allocate time for structured investigation, and model the discipline themselves.

Pillar Behaviours

A recurring defect is found on the line.

Without the system: The team applies the fix that worked last time. The result improves. The investigation is closed. Three months later the same defect appears.

With the system: The team stops before applying a fix. They write a gap statement. They check whether the standard is being followed. They ask why, using a structured method if the cause is not obvious. They select a countermeasure based on evidence. They test it. They document the result.

A problem is escalated to the department leader.

Without the system: The leader asks what happened and tells the team what to do. The team does it. The problem may or may not be solved. The team has not learned how to solve it themselves.

With the system: The leader asks what the team has already tried and what they have ruled out. They coach the problem-solving process, not the answer. The team leaves the conversation knowing more about how to find the cause than they did when they arrived.

A countermeasure is implemented.

Without the system: The fix is applied. The result is watched. If the result improves, the problem is considered solved. If it does not, the investigation restarts.

With the system: The fix is tested deliberately, turned on and off to confirm it is the countermeasure, not something else, that is producing the result. The standard is documented. The visual is in place. The leadership response is defined. The fix is confirmed, not assumed.

What Good Looks Like

Frontline leader

Stops before applying a fix and writes down what the problem actually is, specifically, measurably, without assuming the cause.
Checks whether the standard is being followed before concluding that the process is broken.
Uses appropriate analysis tools (5 Whys or a Fishbone) when the cause is not immediately obvious, and knows the difference between the two.
Tests countermeasures deliberately. Does not declare a problem solved because the result improved.
Documents the fix. Assigns an owner. Confirms the standard is being followed after the countermeasure is in place.

Department or area leader

Coaches the problem-solving process, not the answer. Asks questions that develop the team's thinking rather than providing the solution.
Ensures that recurring problems are escalated with a proper problem statement, not just a description of the symptom.
Connects problem-solving findings to the team's Strategic Objectives. If a recurring problem is affecting a key measure, it belongs on the improvement plan.
Checks that fixes hold. Asks, at the next review, whether the problem has returned.

Site or function leader

Sets the expectation that problems are defined before they are solved. Does not reward fast fixes that do not hold.
Allocates time for structured problem solving. Does not treat it as something that happens in addition to the real job.
Asks in reviews: what problems are we working on this quarter? What did the investigation find? What is the standard now, and who owns it?
Models the discipline. If the leader jumps to solutions, the team will too.

Pillar Owned Processes

The Problem Solving pillar has one process: Problem Solving (PS). It is a structured discipline for defining, investigating, fixing, and sustaining the resolution of a problem.

PS is not a form to fill in. It is a way of earning the right to implement a countermeasure. Work through the stages in order. The fix at the end of Stage 6 is only reliable if the problem was properly defined in Stage 1. If the problem statement looks the same at the end as it did at the beginning, the investigation did not go deep enough.

The same six stages apply whether the problem is a recurring defect on a manufacturing line, a repeated planning failure, or a process that keeps drifting back after improvement. The tools used will differ. The logic of the sequence does not.

Stage 1 — Define the Problem

Before anything else, write down what the problem actually is.

Not what you think is causing it. Not what the fix should be. The problem. The gap between what should be happening and what is actually happening, expressed in specific, measurable terms.

A good problem statement names the process, the measure, the current value, and the target. It does not name a cause. It does not propose a solution. It describes the gap.

Everything from Stage 2 onwards is the work of closing that gap. A vague problem statement produces a vague investigation. A specific problem statement produces a specific result.

Go to the Problem Definition guide →

Stage 2 — Return to Standard

Before investigating root causes, check whether this is a standards problem.

Most problems are not caused by a broken process. They are caused by a process that is not being followed, a standard that does not exist, or a standard that exists but is unclear, unavailable, or not understood.

Three questions:

Is there a standard? If not, create the best-known current method and confirm it. Then check whether the problem persists.
Is the standard being followed? If not, find out why. Remove the barriers, missing tools, unclear steps, training gaps, access issues. Then check whether the problem persists.
Is the standard being followed and the problem still occurring? If yes, the standard is not sufficient. Proceed to Stage 3.

Skipping this stage means investigating a root cause that may not exist, while the real problem, a standard that is not being followed, goes untouched.

Go to the Process Confirmation guide →

Stage 3 — Understand Why

If the cause is not immediately obvious, use a structured method to find it.

Do not assume. Do not apply the fix that worked last time without confirming it applies here. Go to where the problem is happening. Observe it. Ask why it is happening, and keep asking until you reach a cause you can act on.

Two tools for this stage:

🛠️

5 Whys — Ask "why?" five times in sequence, each answer becoming the input to the next question. The goal is to move from the symptom to the mechanism. Use this when the problem is relatively contained and the cause chain is likely to be linear.

🛠️

Fishbone (Ishikawa) diagram — Map potential causes across six categories: Method, Machine, Material, Measurement, Environment, and People. Use this when the cause is genuinely unknown, when multiple causes may be contributing, or when the team needs a structured way to brainstorm before narrowing down. The Fishbone generates hypotheses. The 5 Whys tests them.

Both tools require going to where the work is done. A root cause analysis conducted in a meeting room, from memory, is not a root cause analysis.

Stage 4 — Select the Solution

Once the cause is confirmed, identify the possible countermeasures and choose the right one.

Do not select the first solution that comes to mind. Generate options. Then evaluate them.

Two tools for this stage:

🛠️

Impact vs. Effort grid — Plot each option on a 2×2 grid: impact on the x-axis (low to high), effort on the y-axis (low to high). The options in the high-impact, low-effort quadrant are the starting point. Options in the high-impact, high-effort quadrant may be right but need a plan. Options in the low-impact quadrant should be questioned regardless of effort.

🛠️

Multi-voting — When the team has generated a long list of options and needs to narrow it down quickly, give each person a fixed number of votes and ask them to allocate those votes to the options they believe will have the most impact. The options with the most votes are the candidates for the grid.

The selected countermeasure must directly address the confirmed root cause. A countermeasure that addresses a symptom is not a countermeasure. It is a workaround.

Stage 5 — Validate the Fix

Before declaring the problem solved, confirm that the countermeasure is what produced the improvement.

The simplest validation method is on/off testing: implement the countermeasure, observe the result, remove the countermeasure, observe the result again. If the problem returns when the countermeasure is removed and disappears when it is restored, the countermeasure is confirmed.

Not every countermeasure can be tested this way. Some changes cannot be reversed. In those cases, use a before-and-after comparison with enough data to distinguish the countermeasure's effect from normal variation.

Do not declare a problem solved because the result improved. Results improve for many reasons. Validation confirms that this countermeasure, applied to this cause, produced this result. That is the only basis for a reliable fix.

Stage 6 — Make it Stick

A fix that is not sustained is not a fix. It is a temporary improvement waiting to drift.

Three things must be in place for a countermeasure to hold. Remove any one of them and the problem will return.

✅

Standard work — The improved method is documented. The standard is specific enough that anyone doing the work knows what good looks like. It is not in someone's head. It is on the wall, in the system, or in the hands of the person doing the work.

✅

Visual management — There is a clear, visible signal that shows whether the process is running to standard. Output tracking, a process control chart, a status board. Something that makes the condition visible at a glance, without needing to ask.

✅

Leadership response — There is a defined response when the standard is not being met. Someone owns the standard. Someone checks it. When it drifts, the response is immediate and visible. Without this, the standard and the visual are decoration.

Three things must be in place. Remove any one of them and the problem will return. A standard without a visual is invisible. A visual without a leadership response is ignored. A leadership response without a standard has nothing to confirm.

Go to the Process Confirmation guide →

Go to the Leaders Standard Work guide →

The same six-stage discipline is the foundation of Breakdown Elimination, the equipment-specific process for investigating recurring component failures at the component level, using Mean Time Between Replacement (MTBR) charts, wear analysis, and Physical Mechanism (PM) Analysis to find causes that standard problem solving alone may not reach.

Go to the Breakdown Elimination guide →

Audits and Confirmations

As we review whether the Problem Solving pillar is building the right capabilities in the right audiences, there are some simple questions to ask.

✅

Is the problem statement specific and measurable? Does it name a process, a measure, a current value, and a target? Or does it describe a feeling — "the line keeps stopping," "the yield is low"? A vague problem statement is the most reliable predictor of a fix that does not hold.

✅

Was the standard checked before root cause analysis began? Did the team confirm whether the standard exists and is being followed before concluding that the process is broken? Skipping Stage 2 is the most common reason the same problem is investigated twice.

✅

Was the cause confirmed, or assumed? Did the team go to where the problem is happening and observe it? Or did they apply the fix that worked last time without confirming it applies here?

✅

Was the countermeasure selected based on evidence? Was an impact vs. effort assessment done? Or was the first solution that came to mind implemented without evaluating alternatives?

✅

Was the fix validated? Was on/off testing or a before-and-after comparison used to confirm that the countermeasure produced the improvement? Or was the result improvement taken as confirmation without testing?

✅

Are the sustainment items in place? Is there a documented standard, a visual signal, and a defined leadership response? All three. Not two of the three.

✅

Is the capability growing? Are more people able to define a problem clearly than six months ago? Are investigations being completed faster? Are fixes holding longer? Capability growth is the long-term measure of this pillar.

Where to Start

Before selecting a problem to investigate, take stock of where you are.

Ask these questions:

🔍

When a recurring problem is escalated, does the team arrive with a written problem statement, or with a description of the symptom and a proposed fix?

If the latter, start with Stage 1, Problem Definition.

Go to the Problem Definition guide →

🔍

Do your leaders check whether the standard is being followed before assuming a root cause?

If not, start with the Process Confirmation process.

Go to the Process Confirmation guide →

🔍

When a fix is implemented, is it tested before it is declared successful?

If not, start with Stage 5, Validating the Fix.

🔍

Are the fixes your team implements still holding six months later?

If not, check that you are applying the sustaining factors to your solutions and that they are part of the process owners Leaders Standard Work.

Go to the Leaders Standard Work guide →

If the answer to most of these is no, start with Phase 1, Establish. The goal is not a perfect result. It is a genuine experience of the six stages, so that the people asking others to use the method have used it themselves.

If some capability exists but it is patchy, some investigations go deep, others jump to solutions, start with Phase 2, Strengthen. The most common gap is not in the tools. It is in the problem statement. Fix that first.

If the discipline is established at the leader level but has not yet reached the people doing the work, move to Phase 3, Sustain. The goal is not to run more investigations. It is to build the conditions where the people closest to the work can define a problem clearly and raise what they find.

Phases

The Problem Solving discipline is introduced over time. Each phase builds the site or function's Problem Solving capability in two ways.

The number of people who hold the capability grows. Phase 1, Establish, builds it with the leadership team and Problem Solving Pillar team. Phase 2, Strengthen, extends it to the pilot area leaders and process owners who are closest to the work. Phase 3, Sustain, reaches all process owners and people leaders across the site or function.

The depth of capability also grows. In Phase 1, the goal is that leaders participate in a structured investigation and eventually lead one themselves, on a real problem, so they understand what it requires. The Problem Solving Pillar team lead investigations and coach others through the process. In Phase 2, the goal is to expand the number of people who can lead an investigation independently, multiplying how many problems the organisation can work on well at the same time. In Phase 3, the goal is that Problem Solving is second nature, the discipline is embedded widely enough that problems are defined, investigated, and fixed without central support.