Cause-Effect Diagrams

The five whys

The five whys drills one branch further than a fishbone session usually goes by hand. ASQ: "Use the five whys technique when you want to push a team investigating a problem to delve into more details of the root causes. The five whys can be used with brainstorming or the cause-and-effect diagram." The method is plain: write the problem at the top of a page, then "Ask 'why' or 'how' five times and write the answers on the lines drawn from number one to five", noting that "It may take less or more than five times to reach the root cause or solution."

Worked example: why fee payment is taken but the form is not submitted

The team runs both tools on release 2.0's largest complaint. The fishbone sorts what the team already suspects into four categories (Materials and Mother Nature turned up nothing specific to a software portal, so the session did not force entries there); the five whys then follows the Machinery branch's first cause, the one whose mechanism, a race between the gateway's callback and the form's session timer, is precise enough to test.

# release 2.0's first registration week: brainstormed causes of "payment taken,
# form not submitted" (34 of the help desk's 78 complaints, FINDINGS 5.11)
causes = {
    "Machinery": ["the gateway's success callback can arrive after the form session has timed out",
                  "a late callback retry is not matched back to the order it belongs to",
                  "the confirmation page re-reads the wrong order id after back and forward"],
    "Methods": ["the form never re-checks payment status before asking the student to pay again",
                "nothing routinely matches the gateway's ledger against ExamReg's session log"],
    "Manpower": ["the help desk cannot see the gateway's side of a transaction",
                 "a student who reloads mid-payment is not a case the session design expected"],
    "Measurement": ["no alert fires when a callback arrives after its session has timed out"],
}

def plural(n):
    return "cause" if n == 1 else "causes"

print('effect: "payment taken, form not submitted" (34 of 78 complaints, FINDINGS 5.11)')
for category, items in causes.items():
    print(f"\n{category} ({len(items)} {plural(len(items))} so far)")
    for item in items:
        print(f"   - {item}")
fewest = min(causes, key=lambda k: len(causes[k]))
print(f"\nfewest ideas so far: {fewest} ({len(causes[fewest])}); ASQ: look there next")

whys = [
    ("Why does payment sometimes get taken but the form stay unsubmitted?",
     "the gateway's success callback sometimes arrives after the form's session has timed out"),
    ("Why does the session time out before the callback arrives?",
     "its timer is set to ordinary form-fill time, not to how long the gateway can take to confirm"),
    ("Why can the gateway take longer than the session allows?",
     "confirmation depends on the payment gateway's own provider, whose timing ExamReg does not control"),
    ("Why did this not surface before the first registration week?",
     "release 2.0's tests checked response time, never a callback arriving after a session had ended"),
    ("Why did the requirement not cover a late callback?",
     "the payment confirmation requirement never stated what to do if it arrived after the session ended"),
]
print("\nfive whys, on the Machinery branch's first cause:")
for i, (why, because) in enumerate(whys, 1):
    print(f"{i}. {why}\n   {because}")

effect: "payment taken, form not submitted" (34 of 78 complaints, FINDINGS 5.11)

Machinery (3 causes so far)
   - the gateway's success callback can arrive after the form session has timed out
   - a late callback retry is not matched back to the order it belongs to
   - the confirmation page re-reads the wrong order id after back and forward

Methods (2 causes so far)
   - the form never re-checks payment status before asking the student to pay again
   - nothing routinely matches the gateway's ledger against ExamReg's session log

Manpower (2 causes so far)
   - the help desk cannot see the gateway's side of a transaction
   - a student who reloads mid-payment is not a case the session design expected

Measurement (1 cause so far)
   - no alert fires when a callback arrives after its session has timed out

fewest ideas so far: Measurement (1); ASQ: look there next

five whys, on the Machinery branch's first cause:
1. Why does payment sometimes get taken but the form stay unsubmitted?
   the gateway's success callback sometimes arrives after the form's session has timed out
2. Why does the session time out before the callback arrives?
   its timer is set to ordinary form-fill time, not to how long the gateway can take to confirm
3. Why can the gateway take longer than the session allows?
   confirmation depends on the payment gateway's own provider, whose timing ExamReg does not control
4. Why did this not surface before the first registration week?
   release 2.0's tests checked response time, never a callback arriving after a session had ended
5. Why did the requirement not cover a late callback?
   the payment confirmation requirement never stated what to do if it arrived after the session ended

Figure 105.1 Release 2.0's cause-and-effect diagram for its largest first-week complaint

What the fishbone found. Eight causes across four categories, none of them a guess about which student or which day: a family of Machinery causes about the gateway's callback and session timing, a family of Methods causes about what the system fails to re-check, a family of Manpower causes about what the help desk cannot see, and one Measurement cause about what nobody is alerted to. Measurement has the fewest entries, one, which by ASQ's rule is where the team should brainstorm further next, a separate question from which branch to chase first.

What the five whys found. Starting from Machinery's first cause, the chain of five answers does not stop at the gateway, a third party ExamReg does not control; it stops one step further back, at the session timer's length and, beneath that, at a requirement that never said what should happen to a late confirmation. That is a cause the team can act on: change the requirement and the timer, not merely apologise for the gateway's timing.

Where this has been seen before. FINDINGS 5.2.2 records that one of release 2.0's twelve after-release defects took 72 hours to fix because the fix had to wait on the payment gateway's own provider to change its side of the callback, and Chapter Ninety-One, on statistical process control, found that same repair time sitting outside the control limits of the other eleven: a special cause, needing an agreement with the provider on response times rather than a change to ExamReg's own process. That record and this chapter's five whys were built from different data, a repair-time log against a structured brainstorm, and they arrive at the same mechanism. Neither proves the two are the identical defect; together they are two independent readings that agree on where release 2.0's gateway integration is weak, which is the kind of agreement a real investigation would treat as confirmation, not coincidence.

What it does not mean

A fishbone diagram does not prove a cause; it organises candidates. Every branch in the worked example is a brainstormed hypothesis until it is checked; only the five whys branch was followed to something specific enough to test, and even that needs confirming before a fix is built on it.

The 6 M's are a checklist for completeness, not a form to fill in mechanically. ASQ's own advice is to rename or drop categories that do not fit; this chapter used four of six because release 2.0 is software with no physical materials or weather to blame.

Five whys is not exactly five. ASQ says explicitly that it may take more or fewer questions; five is a name and a habit, not a rule that stops a team one question early or pushes it one question past a good answer.

A cause found by one branch does not rule out the others. The Methods, Manpower and Measurement branches were not chased in this chapter; they may hold real, separate causes of the same complaint, still open.

Quick revision

• Cause-and-effect diagram (fishbone, Ishikawa diagram; ASQ): sorts a brainstorm's causes for one stated effect into categories, drawn as ribs off a spine leading to the effect, shaped like a fish skeleton.
• Ishikawa's 6 M's: Materials, Machinery, Methods, Measurement, Manpower, Mother Nature (sometimes Money); rename or drop categories to fit the problem.
• Procedure (ASQ): state the problem; draw the spine and categories; brainstorm causes per category, asking "why" for subcauses; focus further brainstorming where ideas are fewest; then decide which causes to pursue.
• Five whys (Toyoda, via ASQ): ask "why" repeatedly, typically five times, to drill from a symptom to a specific, actionable cause; pairs naturally with a cause-and-effect diagram.
• Worked example: 34 of 78 complaints were "payment taken, form not submitted"; the fishbone found eight candidate causes in four categories; five whys on the Machinery branch reached a requirement gap about late payment confirmations, the same mechanism as the 72-hour outlier fix of FINDINGS 5.2.2 and Chapter Ninety-One's statistical process control.

Test yourself

1. What is a cause-and-effect diagram, and why is it also called a fishbone diagram? A tool that sorts a team's brainstormed causes of one stated problem into a small number of categories, drawn as branches off a spine leading to the problem; it is called a fishbone diagram because the finished drawing looks like a fish skeleton.

2. Name Ishikawa's 6 M's and say what each covers. Materials (parts, supplies); Machinery (equipment, including software); Methods (procedures and processes); Measurement (indicators and data capture); Manpower (people and their training); Mother Nature (environment and externalities); a less common seventh, Money, is sometimes added.

3. Outline the procedure for building a fishbone diagram. Agree the problem statement; draw the spine with the problem in a box at its head; add the main categories as ribs; brainstorm causes under each category, going deeper by asking why; when ideas run out, concentrate on the categories with fewest of them; then decide which causes to act on.

4. What is the five whys technique, and when is it used? Repeatedly asking "why", usually about five times, to follow a symptom down to a specific root cause; used to push a team past a first answer, often together with a cause-and-effect diagram, when a deeper cause is wanted than a one-line brainstorm entry gives.

5. In the worked example, which branch did the five whys follow, and what did it find? The Machinery branch's first cause, that the payment gateway's callback can arrive after the form's session has timed out. Five whys traced it past the gateway itself to the session timer's length and, beneath that, to a requirement that never specified what should happen if confirmation arrived late.

6. How does the five whys' finding connect to release 2.0's repair-time data? FINDINGS 5.2.2 records an after-release fix that took 72 hours because it waited on the payment gateway's provider to change its side of the callback, which Chapter Ninety-One's control chart flagged as a special cause. The five whys, built independently from a structured brainstorm, arrived at the same mechanism, two different methods agreeing on the same weak point.