Work it through: Something Keeps Going Wrong
Four frameworks for the problem that has been "fixed" three times: draw the boundaries of the process so everyone is talking about the same thing, lay out every plausible cause before anyone defends a favourite, follow the likeliest down to the cause underneath, then test the fix on a small scale and make it stick.
Seven steps, in the order the playbook gives them. Your work stays in this browser until you save it to a file.
Your ducks
Start with what the people believe, what the paperwork says and what actually happens. The issues where your ducks disagree are the ones to carry into the homework.
You have not filled in the ducks sheet yet.
The homework
What has to be found before any of the four frameworks is worth running. Put a name and a date against each one, and tick it when you have it in your hands.
The ducks
For SIPOC
For Fishbone Diagram
For Five Whys
For PDCA Cycle
Step 1 of 4: SIPOC
One page, five columns: who supplies the process, what goes in, the handful of steps, what comes out, who it is for. Draw it before anyone discusses the problem, because the first discovery is usually that the people in the room had different processes in their heads, and the second is that the problem lives at a boundary nobody owned. Keep it to four to seven steps; the detail comes later, and only where the causes point.
Watch forThe map drawn by one person and presented. It has to be built by the people who run each step, or it documents the manager's belief about the process rather than the process.
0 of 5 steps filled · 0 of 4 inputs in hand
What comes out, and how to read it
A single-page, validated map of the process at high altitude: its boundaries, its four to seven steps, what it consumes and from whom, what it produces and for whom, with customer requirements attached. It becomes the scope section of the improvement charter.
- Read it as a boundary document first. Anything outside the start and end events is out of scope until the team deliberately decides otherwise.
- Read across rows for trouble: an input with no acceptance check, a supplier nobody manages, an output with no named customer. The blank cells are the findings.
- Read the customer column against the output column to locate measurement. Where a requirement meets an output is where the project's baseline metrics belong.
Step 2 of 4: Fishbone Diagram
Now get every plausible cause out of people's heads and onto one organised diagram, by category, before anyone defends a favourite. The point is breadth. The cause that has been fixed three times is on there, and so are the ones nobody raised because they sat in somebody else's department. The diagram turns a room full of opinions into a list of hypotheses, which is the first moment the problem can actually be worked on.
Watch forStopping at the diagram. A fishbone full of unverified causes is a drawing of an argument; the next step is to go and check which of them is true.
0 of 6 steps filled · 0 of 4 inputs in hand
What comes out, and how to read it
A single shared picture of every plausible cause of a defined problem, organised by category and drilled to sub-causes, with a shortlist of candidate root causes marked for verification against data.
- The canonical form is the fish skeleton, the effect at the head and category branches as ribs; the hub layout shown here is a category view of the same structure, with the effect at the centre and the six Ms around it.
- Read the diagram as a map of hypotheses, never as findings. Density on a branch shows where the team's attention is, and possibly its bias, rather than where the truth is.
- Bones that stop at a single word ('training', 'the machine') are unfinished; a well-drilled branch reads as a causal chain you could go and check.
- An empty branch is information: either the category truly contributes nothing, or nobody in the room knows that part of the process. Find out which.
Step 3 of 4: Five Whys
Take the likeliest causes and follow each one down. Why did that happen; and why that; and why that, each answer verified before the next why, until you reach the cause where a fix would hold. The discipline is in the verifying. An unverified why is a guess with confidence, and five of them in a row is how teams arrive at a root cause that is entirely fictional. Three honest whys beat five quick ones.
Watch forA chain that ends at a person. "Because she made a mistake" is never the root; the root is whatever made that mistake possible, and usually easy.
0 of 6 steps filled · 0 of 4 inputs in hand
What comes out, and how to read it
A verified causal chain from symptom to root cause, a countermeasure aimed at the deepest changeable link, and a check for recurrence. The chain itself, written down, is also a teaching document about how the process really works.
- Judge the chain by its last link. If the final answer is a person, the analysis stopped early; if it is a missing or unmaintained standard, it probably reached the right depth.
- The count is a guide. Some chains resolve honestly in three whys and some need seven; what matters is that each link is verified and the chain moves from symptom through process to system.
- One chain is one pathway. If the problem plausibly has several contributing causes, expect to run several chains and prioritise between the roots, rather than pretending the first chain found the only truth.
Step 4 of 4: PDCA Cycle
Treat the fix as a test. Say what you expect to happen, change one thing on a small scale, check the result against what you predicted, and only then make it the standard way of working. The check is the step that was missing from the last three fixes; each of those was planned and done and never measured, which is why nobody noticed when it quietly stopped working. If the problem is big enough and the data is there, this is where DMAIC earns its five phases; for most problems, one honest cycle is enough.
Watch forRunning the cycle during an emergency. Contain first, improve once the process is stable enough to study.
0 of 6 steps filled · 0 of 4 inputs in hand
What comes out, and how to read it
A tested change with evidence of its effect: baseline, prediction, measured result and the decision taken. Over successive cycles, a rising standard captured in standard work and a team that treats changes as experiments rather than edicts.
- Judge a cycle by its check stage. If the write-up contains a baseline, a prediction and an explained gap, the cycle was real; if it jumps from action to conclusion, it was an initiative wearing PDCA's clothes.
- Failed cycles that produce learning are successes of the method. A team whose cycles never fail is either not measuring or not experimenting.
- Look at the chain, not the link. One completed cycle proves little; the trajectory across several cycles is where the improvement, and the evidence of an improvement culture, actually shows.
The review date
Set the date you will come back and ask whether it worked. Put it in your diary; this site will not remind you.
Your work stays in this browser until you save it. The file is yours; load it here on any machine.