KaizenProof

Lesson 9 of 23 · 6 min read

Write the problem down before solving it

In Lean: problem statement

Builds on: Asking why until you reach something you can change

In one minute

A problem statement is a short written description of a problem that says what should happen, what actually happens, where and how often, and why it matters, using facts someone could check. Writing one before anyone proposes a fix stops a team arguing about different problems or solving the wrong one. It contains no cause, no solution and no blame: those come later, or not at all. Two people who do the work should both be able to read it and agree that it describes what happens.

The idea

When a friction hurts, the natural move is to jump to a fix. The trouble is that people carry different versions of the problem in their heads. One thinks it is about speed, another about errors, a third about one awkward customer. Writing the problem down (in Lean: problem statement) before anyone proposes anything makes those versions meet.

The four parts

  1. What should happen (in Lean: standard). The expected result, as the customer or the next step needs it. "Offer letters go out within two working days of approval, with the agreed salary and start date."
  2. What actually happens. Observed, not remembered. "Of the last twenty offer letters, six went out after more than a week and two were reissued with a corrected start date."
  3. Where and how often. Narrow it to where the problem really occurs: which team, which kind of item, which days. Counting real items, as in lesson 8, beats an impression.
  4. Why it matters. Who is affected, in their terms. "Candidates wait, and two asked whether the offer still stood."

The difference between parts 1 and 2 (in Lean: the gap) is the problem. If you cannot write part 1 because nobody has ever agreed what should happen, that is your first finding, and a useful one.

Three things to leave out

  • A cause. "Because the template is outdated" belongs in the 5 Whys, once it has been checked. Put it in the statement and the analysis is over before it starts.
  • A solution. "We need an e-signature tool" is a fix dressed as a problem. It quietly rules out every other answer, including removing the step.
  • Blame. Name the step, not the person: "letters prepared on Fridays", not a colleague's name. A statement that points at someone ends the conversation and changes nothing in the process.

Size and wording

Keep it to one problem small enough for your team to act on. "Onboarding is a mess" is a theme; "new starters' laptops are not ready on day one" is a problem. Use the words of the people who do the work. When you report a friction quickly, two sentences are enough: what should happen and what happens. The counts can come when you look closer.

Example

Illustrative example, not a real company.

A customer service team's first draft: "The evening shift keeps missing callbacks, so we need a callback scheduling tool." It blames a group, names a solution and states no fact.

After reading the callback log for the last month, the team rewrites it:

  • Should: a customer who asks for a callback is called within one working day.
  • Does: of the last forty callback requests, nine were called after two days or more and three were not called at all.
  • Where: all twelve late or missed calls were requested by phone after five in the evening; requests made on the website were all on time.
  • Why it matters: most of those customers called again, and several second calls were complaints.

The statement no longer mentions the evening shift or a tool. It points the 5 Whys at something nobody had looked at: what happens to a phone request logged late in the day.

Common mistakes

  • A missing fix posing as the problem. "We have no dashboard" describes an absent solution. Ask what goes wrong without it.
  • Impressions instead of observations. "Approvals are always slow" is a feeling. Count a few real ones.
  • Too big to act on. A theme like "communication" cannot be fixed by anyone in particular. Narrow it to one process and one gap.

Words to know

  • Write the problem down (in Lean: problem statement): what should happen, what happens, where and how often, and why it matters.
  • What should happen (in Lean: standard): the agreed, expected result of a process.
  • The difference between should and does (in Lean: gap): the problem itself, stated as facts.

Check your understanding

3 questions. Answer them all, then check. You can try again as often as you like; nothing about your attempts is kept.

Question 1 of 3Which problem statement is flawed?
Question 2 of 3A team writes: 'We need an automated reminder for expense approvals because managers ignore them.' What is wrong with it as a problem statement? Select all that apply.

Choose all that apply.

Question 3 of 3Which is the best 'what actually happens' line?

Loading…

Try it on your own work

Describe one recurring task that wastes your time, and see these ideas applied to it.

Report a friction (opens in a new tab)

Worksheet for this lesson: A3 Problem Solving Template (free download, no sign-up).

Where this comes from

Defining a problem as the gap between a standard and the actual situation, before looking for causes, is a basic step of the practical problem solving used in the Toyota Production System and across Lean and quality improvement.