Out of Scope Productions is a Third Person Consulting company. Visit TPC →
Out of ScopeProductions
← The Ten StagesProblem framing · Root cause · Baselines · Readiness

Diagnose: Find the Real Problem

Most failed fixes were aimed at the wrong problem. This brief shows how to turn a request into a problem you can test, keep more than one explanation alive, and hand the next stage a diagnosis it can trust.

1. What this stage is for

Every change starts with someone noticing that something isn't working. A plant manager sees rework climbing. A project director sees requests for information piling up on one subconsultant. An IT lead hears that nobody uses the new document system. A safety manager watches near-miss reports dry up and isn't sure whether that's good news. The temptation at this moment is to name a fix straight away: more training, a new tool, a tighter procedure, a reorganization. Diagnose is the stage where you resist that temptation long enough to find out what is actually wrong. PM-1 · #13

The stage has a clear job. By the end of it you should be able to state the business or safety outcome at stake, the size of the gap, who it affects, what is causing it, which causes training can fix and which it can't, and how ready the organization is to change. You should also be able to say what you still don't know. That last part matters more than it sounds: a diagnosis that admits its gaps is far more useful than one that sounds certain and turns out to be wrong. DGN-CNS-01 · #13

Diagnosis is not only for big transformations. The same habits apply to a single crew that keeps missing hold points, a finance team whose month-end close always runs late, or a software team whose releases keep breaking. The scale changes; the discipline doesn't. In a small firm, a diagnosis might be a two-hour conversation and a page of notes. In a capital programme it might be a formal front-end review with an independent reviewer. What both share is that they separate the problem from the solution and test the first before buying the second. PM-9 · DGN-FED-01

A useful definition of done: the diagnosis is finished when someone who wasn't involved could read it, check its evidence, and reach the same conclusion, or see exactly where they would disagree. Everything in this brief serves that standard.

2. Why diagnosis goes wrong

The best evidence on how diagnosis fails comes from medicine, where errors are studied carefully, and from public investigations of accidents and failed projects. Both point the same way. Failures are rarely caused by a lack of method. They're caused by settling on one plausible story too early, trusting indicators that measure the wrong thing, and skipping the one test that would have shown the system wasn't ready. DGN-FRM-02 · DGN-BIAS-01

A study of 100 diagnostic errors in internal medicine found that only seven were "no-fault" errors alone. In the other 93, the researchers found an average of nearly six contributing factors per case. System factors, such as poor handovers, missing information or workload, contributed to about two-thirds of the cases. Thinking errors contributed to about three-quarters. Many cases had both. The single most common thinking error was premature closure: settling on the first plausible answer and no longer considering alternatives. DGN-FRM-02 · DGN-BIAS-01 · PM-2

Figure 1. What lay behind 100 diagnostic errors
Thinking errors contributed74 of 100
System factors contributed65 of 100
Both togetherabout 46
"No-fault" errors alone7 of 100

Medical diagnosis, not organizations; applying it at work is inference. The lesson that transfers: expect several causes, and expect at least one to sit in the system rather than the person. DGN-FRM-02

Organizational failures show the same pattern at a larger scale. Canada's Phoenix pay system was framed around savings, budget and timeline; its only pilot was cancelled, the system was never tested as a whole, and more than 100 functions were deferred to fit the budget without anyone re-examining the expected benefits. A year after launch, about half of employees had errors in a single pay run. Before the 2005 Texas City refinery explosion, a very low personal-injury rate was read as a sign of good process safety, while earlier surveys and audits had already flagged deep problems. In both cases, the information existed; the diagnosis didn't use it. DGN-RDY-03 · DGN-RDY-04 · DGN-BSL-02 · DGN-DATA-02

Four traps account for most of the damage:

  • The solution-shaped request. "We need Revit training" or "we need an AI tool" arrives as the brief, and the diagnosis quietly becomes a search for evidence that it's right. DGN-FRM-04 · IDE-DES-02
  • The people-problem default. "Crews don't follow procedures" feels like a diagnosis but is usually a symptom. Ask what in the system made the behaviour likely or rewarded it. DGN-FRM-03 · PM-3
  • The wrong indicator. A metric that looks healthy can measure something the real risk doesn't depend on. DGN-BSL-02
  • The hollow check. A test that passes for the wrong reason, or paperwork marked "closed" when the work wasn't done. DGN-GAP-02 · DGN-GAP-03

3. Frame the problem

Start by rewriting the request as an observed gap against a named outcome. State the outcome that matters, the level it's at now, the level it should be at, who is affected and since when. Then strike out any word that names a fix. If the statement only works with the fix still in it, you have a solution looking for a problem. DGN-FRM-01 · IDE-DES-01

The request

"Our site engineers need a two-day course on the inspection and test plan."

The gap statement

"On our three Ontario sites, 14% of concrete pours since March went ahead without the hold point being released, against a target of zero. It's concentrated on two sites and started when the new ITP template replaced the old one."

The second version does three things the first can't. It names a measurable outcome. It tells you where to look, because two sites and a template change are clues. And it leaves the cause open: the template, the inspector's availability, the schedule pressure or the engineers' knowledge could all be responsible, and a course only fixes one of them. DGN-FRM-01 · QMS-ITP-02

When the request comes from a sponsor, diagnose the request itself before accepting it as the brief. Write down the decision the sponsor faces and what evidence would show the requested solution addresses it. Agree at the start that the diagnosis might find the request wrong. This is easier to say in the first meeting than after you've spent three weeks confirming the wrong thing. Where a solution is legally mandated, such as certified training for working at heights, diagnose the barriers to it working rather than whether to do it. DGN-FRM-04 · SOP-CAN-02

On capital projects, the equivalent of framing is front-end definition. Industry research on large industrial projects finds that how complete the front end was at authorization is one of the strongest predictors of whether a project delivers what it promised. Owners can score this with tools such as the Project Definition Rating Index: in NASA's building projects, those scoring 200 or less averaged about 1% over budget and 2% late, against 6% over and 11% late above that line. The association is correlational, but the element-level scores also show where owner, designer and contractor rate the same item differently, which is a diagnosis in itself. OGV-FEL-01 · DGN-FED-01 · DGN-FED-02

Practise it. In Project: Countdown!, The Gate (Long Lead, Part 1) asks whether a $142-million line is really ready for a final investment decision, and the By Design short case Is It Training? starts with exactly the request above.

4. Sort the causes

Once the problem is framed, list the candidate causes and sort them into families. Six families cover most workplace problems, and more than one usually applies. Record evidence for and against each. Recommend training only where a knowledge or skill gap is actually shown, and only alongside fixes for the other families that turned out to matter. DGN-FRM-02 · IDE-DES-02

Figure 2. Six cause families, and the question that tests each
KnowledgeCould they explain what to do and why, if you asked?Training can help
SkillCan they do it, to standard, without help?Practice can help
Motivation & incentivesIs doing it right rewarded, ignored or punished?Training won't fix it
Process & environmentDoes the procedure, schedule or site make the right way hard?Training won't fix it
Tools & dataDo the template, software and information support the task?Training won't fix it
CapacityIs there enough time and people to do it properly?Training won't fix it

In the medical study behind Figure 1, most thinking errors came from gathering and combining information, not from missing knowledge. Treat "they need training" as one hypothesis among six. DGN-FRM-02 · #15

A practical way to use the families: for each one, ask the people closest to the work for a recent example. If engineers can explain the hold-point rule perfectly but released pours anyway because the inspector was booked two days out, the gap is capacity and process, not knowledge. If they can't explain it, knowledge is in play, but probably not alone. DGN-GAP-01 · DGN-DATA-04

Two cause families deserve extra suspicion. The first is the behaviour explanation. "Unsafe acts cause most injuries" is a line that has circulated for decades; before Texas City, the refinery's safety campaign was built on it, and investigators found systemic process-safety and management failures instead. Treat any behaviour explanation as a hypothesis that needs its own evidence. The second is capacity, because it is the family people are least likely to volunteer. If a business case assumes each person will handle twice the workload after a new system arrives, measure what they handle now, in the current system, before relying on the assumption. DGN-FRM-03 · DGN-TNA-03

For judgment-heavy tasks, where experts can't easily explain what they do, simple interviews will miss most of it. Structured methods such as cognitive task analysis, which combine interviews with observation and real cases, produce much better training content for troubleshooting, estimating and emergency command, though they take time and need genuine experts. Don't build content from expert self-report alone: experts routinely leave out steps they no longer notice they take. DGN-TNA-01 · DGN-TNA-02 · #18

5. Keep explanations open

The single most useful habit in diagnosis is to keep at least three competing explanations open until the evidence tells them apart. For each, write what would confirm it and, more importantly, what would rule it out. Close an explanation only after you've checked the evidence against it. This is the direct remedy for premature closure. It also changes how you collect data, because you go looking for the observation that would separate the explanations instead of the one that confirms your favourite. DGN-BIAS-01 · DGN-CNS-03

Figure 3. A differential for "pours released without the hold point"
ExplanationWould confirm itWould rule it outStatus
Engineers don't know the new hold-point ruleThey can't describe it; errors spread evenly across sitesThey can explain it; errors cluster on two sitesRuled out
The new template hides the hold pointErrors began with the template; the field is on page 4Sites on the old template show the same rateSupported
Inspector availability forces a choicePours booked with under 48 hours' notice to the inspectorInspector was on site for most released poursOpen

Keep the "open" row visible in the report. "Not yet established" is a finding, not a failure. DGN-CNS-01

Three more checks protect the diagnosis from its own blind spots:

  • Test the test. For every check the organization relies on, walk through how it is physically done and ask whether anything other than the target could make it pass. At Lac-Mégantic in 2013, the hand-brake test was done with the locomotive's air brakes still on, which made it look as if the hand brakes alone would hold the train. Commissioning tests, software test suites and inspection sign-offs can all pass for the wrong reason. DGN-GAP-02 · DGN-AST-01
  • Check that closed means done. Sample closed permits, work orders and corrective actions, and look at the state they claim to certify. A "check the box" habit was one of the Texas City findings. DGN-GAP-03 · QMS-CAP-03
  • Get a second look for high-stakes or contested diagnoses, from someone with no stake in the answer. In one study of 286 patients referred to a major clinic, about 1 in 5 ended with a distinctly different diagnosis after review, and two-thirds were refined. Ask the reviewer to examine the evidence, not your conclusion, and record whether they agreed, refined or overturned it. DGN-BIAS-02 · DGN-CNS-02

Be careful with the tools that promise to find "the" root cause. Five Whys is fine for quick triage of a simple, single-cause fault, but it oversimplifies complex events: the Lac-Mégantic investigation produced 18 causal and contributing findings. For serious events, use methods that trace how control failed through management and oversight, with a small interdisciplinary team. Debiasing checklists sound helpful, but the best-known ones were never rigorously tested, and a small trial found they didn't reduce errors. Pair them with structural changes and feedback rather than relying on them alone. QMS-RCA-03 · DGN-RCA-01 · DGN-BIAS-03 · QMS-RCA-06

Finally, log every warning. Keep a simple register of every warning or dissenting signal: who raised it, who received it and what was decided. Phoenix's executives didn't grasp the importance of warnings that the pay centre and the system weren't ready, and the decision to go live wasn't documented. A register costs minutes and makes that failure much harder to repeat. DGN-BIAS-04 · PM-22

6. Baselines that don't lie

A diagnosis needs numbers, and numbers chosen at the wrong moment can mislead badly. The most common mistake is baselining at the moment the problem was noticed. Problems get noticed at their worst. A metric picked because it looked bad will usually drift back toward its normal level on its own, a statistical effect called regression to the mean, and any fix introduced at that moment will appear to have worked. DGN-BSL-01 · #14

Figure 4. Why a worst-month baseline flatters any fix
0%4%7% Noticed here; fix introduced "40% better" 12 months beforeAfter

Use several measurements before the change, ideally a full operating cycle, and a comparison group where you can. DGN-BSL-01 · DGN-BSL-04 · LSC-MSR-05

Three further rules keep baselines honest:

  • Keep different kinds of risk in separate indicators. Personal-injury rates say little about the risk of a major accident. Texas City's low injury rate gave a misleading picture of process safety. For major hazards, track precursors such as barrier failures, relief-valve activations, loss of containment and shutoff failures. DGN-BSL-02 · DGN-HAZ-01 · CM-SAF-02
  • Correct counts for under-reporting. Where people fear reporting or are pressured to downplay injuries, counts fall without anything getting safer. Never trend a count tied to someone's bonus without checking this. DGN-BSL-03 · SOP-GOV-04
  • Read surveys for what they measure. Safety-climate scores partly echo recent injuries: a survey run two weeks after a serious incident will drop whatever the underlying culture. Weight the items about management commitment most, and check survey timing against incident dates. DGN-DATA-01

Before commissioning any new diagnosis, check whether earlier ones were acted on. If an audit two years ago found the same problem and nothing changed, the problem is no longer information. It's decision-making, and the diagnosis should say so. DGN-DATA-02 · DQ-LRN-04

7. Readiness, and handing it on

The last part of diagnosis asks whether the organization is ready to change. Readiness has two parts that are worth reporting separately: commitment, whether people value the change, and confidence, whether they believe they collectively have the knowledge, resources and time to make it work. Report how readiness varies between sites, teams and roles, not just the average: a wide spread is itself a warning. DGN-RDY-01 · DGN-RDY-02 · #38

Surveys and status reports aren't enough on their own. Where the stakes are high, confirm readiness with a behavioural test: a pilot, a dress rehearsal or a parallel run, made a gate criterion. If the test is cancelled, require a documented impact assessment and a fresh decision by the accountable executive. Whenever scope is cut later, re-run the benefits and readiness diagnosis; a cut that seems administrative can remove exactly the function the benefits depended on. DGN-RDY-03 · DGN-RDY-04 · #1

Then write it up in a form the next stage can use. A good diagnostic report separates three things: what was found, with evidence from at least two kinds of source; what is opinion, labelled as such; and what is not established, with what would settle it. It reports the hypotheses that failed as well as those that survived, says which cause families training can address and which it can't, and summarizes the warnings register. Keep the diagnostician independent of whoever will sell or deliver the solution, and plan who hears the findings, when, and through which channel, because the diagnosis itself changes the system. DGN-CNS-01 · DGN-DATA-03 · DGN-CNS-02 · DGN-CNS-04

A note for small organizations. None of this requires a consultant or a software platform. A thirty-person firm can do a sound diagnosis with a one-page gap statement, a short table of three explanations, a dozen recent examples from the people doing the work, and a baseline drawn from records it already keeps. The discipline is the point, not the paperwork. LSC-ORG-03 · PM-1

Practise it. Before the Rush (Margin of Error, Part 2) asks you to read cracks in a new bridge with the road below still open, and Month Seven (Long Lead, Part 2) asks whether "78% complete" means what it says.

The checklist. Write the gap without the fix. Diagnose the request. Sort causes into six families and expect several. Keep three explanations open and write what would rule each out. Test the test; check that closed means done. Get a second look when it matters. Log every warning. Never baseline at the worst moment. Report found, opinion and not established. Then hand on to Define.