Chapter 24 — Issue logs and root causes
Lesson map
Lesson 24 published. Map, example, EX070.
flowchart TD
N0["Learning outcomes"]
N1["24.1 The log"]
N2["24.2 Root causes"]
N3["24.3 Tracking closure"]
N4["24.4 Patterns"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX070"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["24.1 The log"]
N2["24.2 Root causes"]
N3["24.3 Tracking closure"]
N4["24.4 Patterns"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX070"]
[Learning outcomes]
|
v
[24.1 The log]
|
v
[24.2 Root causes]
|
v
[24.3 Tracking closure]
|
v
[24.4 Patterns]
|
v
[Worked example] --> [Exercise EX070]
Learning outcomes
You will (1) run an issue log; (2) use root cause techniques; (3) track issues to closure.
24.1 The log
Ravi maintains the data issue log for repairs. Each issue records description, reporter, date, data affected, impact, priority, owner, status and resolution. Anyone can submit issues through a form. The steward triages weekly. Ravi adds a link to supporting evidence, such as check results. He explains that a log gives the organisation a memory of problems and their fixes, which prevents the same investigation being repeated when a problem returns. The log is reviewed at the monthly repairs meeting, where the most serious open issues are discussed.
24.2 Root causes
Ravi uses the five whys technique on an issue where tenant phone numbers are often wrong. Why? Because they are entered incorrectly. Why? Because call handlers type them from memory after calls. Why? Because the screen to edit numbers is not open during calls. Why? Because opening it takes several clicks. Why? Because the system layout was never reviewed. The fix is to show the phone field on the main call screen. The supplier makes the change, and call handlers welcome the simpler screen.
24.3 Tracking closure
Issues close only with evidence. For the phone number issue, Ravi measures the share of numbers confirmed correct in a sample before and after the screen change and records the improvement. He also confirms with call handlers that the new layout works. Issues closed without evidence are reopened. He notes that the reopening rate itself is a useful measure of whether fixes really work. In the first quarter, two issues are reopened because their fixes did not hold, and both are then fixed properly after a second root cause investigation by the steward and Ravi.
24.4 Patterns
After six months, Ravi groups issues by cause: manual entry, system design, partner data, unclear definitions and process gaps. Manual entry and partner data cause most issues. He presents the patterns to Mrs. Okonjo, who prioritises validation at entry and contractor specifications for the next year. Ms. Moreau explains that issue logs become strategic tools when their patterns guide investment, rather than serving only as lists of individual tasks. The patterns are repeated every six months, and Ravi adds a chart showing how the mix of causes changes over time.
Worked example
Ravi runs a repairs issue log with evidence links, traces wrong phone numbers through five whys to screen layout, closes issues with measured evidence and groups six months of causes to guide priorities.
Synthetic case. Issues are synthetic.
Errors and limits
Fixing symptoms without root causes lets issues recur.
Exercises
- EX070 — Phone root cause. What was the root cause of wrong phone numbers? Rubric: 3 = the system layout hid the phone field during calls;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX071 — Reopening measure. What does the reopening rate show? Rubric: 3 = whether fixes really work;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX072 — Top causes. Which causes produced most issues? Rubric: 3 = manual entry and partner data;; 2 = both;; 1 = one;; 0 = none.
Continue studying — lesson 24 (chapter 24 of 30)
← Chapter 23 · Course chapter index · Chapter 25 →
Continue to the next authored lesson.