The single-page problem report: forcing a thinking sequence onto one sheet

The sheet is a thinking constraint, not a template to complete

Give a team the boxes without the discipline and you get a decorated status report. Value comes from being forced to state the problem in terms a stranger could follow, to show the current condition with evidence rather than assertion, and to fit the analysis into a space too small for a data dump. Fitting it requires deciding what matters, and that decision is the intellectual work. Software versions of the format usually lose this, because a scrolling document has no edge, and the discipline was entirely in the edge.

Current condition first, and it takes longer than anyone expects

The commonest weakness is a problem statement that is really a solution in disguise, followed by a current condition described in adjectives. What belongs there is what is actually happening, observed at the process: how often, where, under which conditions, with what variation, sketched where possible rather than written. Teams resist this because it delays the part they enjoy. Coaches should hold the line, since a wrong description of the present makes every subsequent box worthless, and most failed countermeasures trace back to a problem nobody had properly located before choosing what to do about it.

Written backwards from a solution somebody already wanted

It is easy to spot and awkward to raise. The analysis contains one branch, the alternatives considered are strawmen, the countermeasure happens to be equipment somebody has been requesting for a while, and the target was set afterwards so the chosen solution meets it. This is rarely cynicism; it is usually a manager under pressure using the format to justify a decision already taken. The remedy is procedural rather than moral: review the current condition and analysis before any countermeasure is written, and treat a report presented complete for approval as a document that skipped the coaching.

Two names belong on the sheet

One is the owner, who does the work and holds the pen. The other is the coach or responsible manager, whose job is to ask questions rather than supply answers, and who is accountable for the quality of the thinking rather than for the result. Remove the second name and the exercise becomes form filling; remove the first and you get a report written by the improvement department about somebody else's process, which nobody will implement. The pairing is also how problem-solving capability spreads, since the method is learned by being coached through it rather than in a classroom.

The half that never gets written

Most reports stop when the countermeasures are agreed. The remaining sections, covering what was implemented, what actually happened, what is still open and what will be standardised, are where learning either happens or evaporates. They require going back much later, which nobody is scheduled to do. A practical discipline is that a report cannot be closed by the person who wrote it, only by the manager who agreed it, at a review held with the process running in front of them. Unclosed reports should stay visible, because a wall of confident countermeasures with no recorded outcome is itself a diagnosis.

Frequently asked questions

How long should one of these reports take to complete?

Long enough for the current condition to be observed properly, and short enough that the problem has not changed shape by the end. Small process problems move through in days; a chronic quality escape can run for weeks, with most of that time spent waiting to see whether the countermeasure held. What should worry a coach is a report completed in a single sitting, because that means the analysis came from memory and nobody watched the process.

Who should write it, the engineer or the supervisor?

Whoever owns the process and will live with the result. Engineers write better documents and often produce reports the area does not recognise or implement. A supervisor writing a rougher report, coached properly, produces a countermeasure that survives and grows the plant's capability at the same time. Where the problem crosses departments, the owner should be the person accountable for the outcome, with contributors named rather than a committee holding the pen jointly.

Do we need software to manage these reports?

Not to start with, and introducing it early shifts attention from the thinking to the workflow. Paper on a wall has properties a database lacks: the area can see it, it is embarrassing when stale, and it invites people to write on it. A register of open problems and their owners is worth keeping electronically once the volume grows, but the report itself works best where the work is, in a form the people doing the work can annotate.