Hansei: how to reflect on a solution that failed

Hansei is the lean practice of honest self-reflection: looking back at what happened and asking how a process, or your own part in it, could be better. It is most useful at the moment most people want to move on, right after a solution has failed. This guide explains what hansei means, gives you five questions to reflect on a failed fix, and walks through one example from start to finish.

What hansei means

The Lean Enterprise Institute defines hansei as "the continuous improvement practice of looking back and thinking about how a process or personal shortcoming can be improved", and notes that it is the Japanese term for self-reflection (Lean Enterprise Institute, Hansei).

The same page says that in the Toyota Production System, reflection meetings are typically held at key milestones and at the end of a project, to identify problems, develop countermeasures and share the improvements so mistakes are not repeated. It describes hansei as part of organizational learning alongside kaizen, the practice of small continuous improvements, and standardized work.

Two parts of that definition matter for a failed fix. First, hansei looks at the process and at your own part. Second, it ends in a countermeasure, a next step, not just a feeling about what went wrong.

Why a failed solution is worth reflecting on

A fix you try is a guess about what is causing the problem. The Lean Enterprise Institute puts it this way: a plan is "a theory" of what will address the problem's cause, and putting it in place is "a learning process" (Lean Enterprise Institute, Problem Solving).

So when a fix fails, the theory was wrong somewhere. That is information. If you skip the reflection and jump to the next idea, you keep the wrong theory and are likely to pick another fix built on it. Hansei is the pause that asks which part of the theory broke.

It also fits the plan, do, check, act cycle. The Lean Enterprise Institute says hansei is sometimes compared to the "check" step, where you evaluate the results, and act means to "standardize and stabilize the change or begin the cycle again, depending on the results" (Lean Enterprise Institute, PDCA). A failed fix sends you round the cycle again, and hansei makes the next round smarter. Our PDCA example shows the full cycle on an everyday problem.

Five hansei questions for a fix that failed

Write the answers down. A reflection you only think through is gone by next week.

1. What did I expect? Name the guess the fix was testing, in one sentence.
2. What actually happened? Facts you can check, with numbers where you have them.
3. Where is the gap? Was the guess wrong, was the fix not done as planned, or did something else change?
4. What was my part? Name it plainly, without blame. This is the "personal shortcoming" half of hansei, and the part most reflections skip.
5. What will I try next? One countermeasure, built on what the first four answers taught you.

Then keep the failed fix in your records with its outcome. Do not delete it to make the record look tidy.

A hansei example: the late weekly report

Here is a made-up work problem, reflected on with the five questions.

The failed fix stays on the record, and the reflection explains the next attempt.

The problem. Our weekly report goes out after the Friday noon deadline on 3 of the last 4 weeks. It should go out by noon every Friday.

The fix that failed. Send everyone a reminder on Thursday. It was tried for 2 weeks, and the report was late both weeks.

The reflection.

1. Expected: people were forgetting to write their sections.
2. Happened: every section was in by Thursday both weeks. The report waited on Friday morning for sign-off.
3. Gap: the guess was wrong. Nobody was forgetting; the delay was the sign-off.
4. My part: I am the one who signs it off, and I had booked Friday mornings for meetings.
5. Next: sign off on Thursday afternoon instead.

The result. The report went out on time 3 weeks out of 3. The working fix needs one thing to keep working: a Thursday 3 pm slot kept free.

Notice what the reminder fix taught. Without it, the sign-off delay might never have shown up, because the first guess (people forget) sounded reasonable. The failure pointed straight at the real cause. If you want a method for digging further into a cause, our 5 whys example walks through one.

Common mistakes with hansei

• Turning it into blame. Naming your part is not the same as punishing yourself or anyone else. The aim is a better next attempt.
• Only blaming the process. The opposite mistake. If every reflection ends with "the system was bad", you miss the part you can change today.
• No countermeasure. A reflection that ends without a next step is just a regret.
• Deleting the failure. Next time someone suggests the reminder, you want the record to say it was tried and why it did not help.
• Waiting too long. Reflect while the facts are fresh, ideally the same day the fix is marked as failed.

Keep failed solutions visible in Problem Graph

Problem Graph is a problem and solution journal drawn as a map, and it is built around keeping failures in view. Its home page puts it this way: "The graph is honest. A solution that failed three times stays on the map as a failed solution, and that is exactly what the next person needs to know."

Here is the weekly report example in the app:

• Write the problem in one line and put it in the work lane.
• Add "Send everyone a reminder on Thursday" as a solution, mark it as trying, then record its outcome as failed.
• Add "Sign off on Thursday afternoon" as the next solution and record it as worked when it holds.
• Add "A Thursday 3 pm slot kept free" as a requirement of the working fix.
• If the same sign-off delay holds up other work, write that as its own problem and link the two.

The reflection itself is yours to keep in the solution's wording or your own notes. The point is that the failed solution never disappears: next quarter, the map still shows what was tried, what failed and what worked. Problems are private by default, so nobody else sees them unless you choose to share. For a longer look at recording attempts, see how to keep track of the solutions you tried.

Frequently asked questions

What does hansei mean?

Hansei is the Japanese term for self-reflection. In lean, it means looking back to see how a process or your own part in it can be improved, and ending with a countermeasure.

Is hansei the same as a retrospective?

They are close. A retrospective is usually a team meeting, while hansei can be done alone, and it asks you to name your own part as well as the process.

When should I do hansei?

Right after a fix fails, while the facts are fresh, and at milestones or the end of a project. A short written reflection the same day is better than a long one a month later.

Should I delete a solution that did not work?

No. Keep it with its outcome, so you and anyone you share with can see it was tried and why it did not help.

Get started

Think of one fix that failed this month. Answer the five questions in writing, then pick the next attempt.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.