Playbook
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.
There is a particular kind of problem that every business has at least one of. It has been fixed. It has been fixed several times. Each fix was sensible, each one worked for a fortnight, and each time it came back somebody was blamed, which fixed nothing but felt like progress. The pattern underneath is always the same. The fix went on the symptom, because the symptom is what you can see, and nobody stopped to ask what was producing it. The sequence here is built to stop you fixing the symptom a fourth time. It starts by agreeing what the process actually is, which sounds too obvious to need a step until you watch three people describe the same process three ways. Then it widens: every plausible cause, from everyone, before anyone argues. Then it narrows: the likely causes followed down, one honest why at a time, to the point where a fix would hold. And it ends by treating the fix as an experiment rather than an announcement, because the last three were announcements.
Operations & process
SIPOC
For agreeing the boundaries of a process on one page, suppliers, inputs, steps, outputs and customers, before anyone argues about the detail. Leave it alone when you already need the detail, the times, the queues, the rework; use value-stream mapping. Instead Value Stream Mapping, which has the times, the queues and the rework that SIPOC leaves out.
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.
Operations & process
Fishbone Diagram
For getting every plausible cause of a problem out of people's heads and onto one organised diagram, ready to test. Leave it alone when the cause is known; drawing a skeleton round a solved problem is decoration. Instead PDCA, to fix the cause you already know and check the fix held.
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.
Operations & process
Five Whys
For getting from a symptom to the cause underneath it by asking why of each verified answer, until you reach a fix that will hold. Leave it alone when the failure has several interacting causes; it forces a single path. Instead A Fishbone Diagram, which holds several interacting causes at once.
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.
Operations & process
PDCA Cycle
For testing a change on a small scale, checking the result against what you predicted, and keeping what works before going round again. Leave it alone when you are in an emergency; contain it first, improve it later. Instead Contain it first. An outage or a safety incident needs stopping, not studying; come back to PDCA when it is stable.
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.
In the end
You should end with a process everyone describes the same way, a full map of plausible causes with the verified ones marked, a root that is a condition rather than a culprit, and a fix that was tested against a prediction before it became the rule. The test of whether it worked is dull by design: in three months, nobody mentions the problem, because it has not come back. That is what a real fix looks like. It makes no noise at all.