What a root cause analysis is and why it fits a personal problem
A problem you keep meeting again is rarely solved by the fix you reach for first. The short answer to how to do a root cause analysis on a personal problem is to state the problem as a plain fact, ask why in small steps, check each answer against what you know, and fix the cause you reach instead of the symptom you started from.
Root-cause analysis began as a method for engineers. Wikipedia describes it as a method of problem solving used for identifying the root causes of faults or problems, used in IT operations, manufacturing, accident analysis and healthcare. It serves as input to a remediation process, where corrective actions are taken to prevent the problem from recurring. Nothing in that goal belongs only to factories. A late habit, a recurring argument and a bill that is always overdue all come back for the same reason a fault does: the cause was left in place.
A journal for problems and the attempts made on them is Problem Graph, where a problem goes down in one line and the solutions tried on it are attached. Every problem there sits in one of four lanes, and personal is one of them. A notebook works too. What matters is that the chain of causes and the attempts exist on paper.
Symptom or cause: the difference that decides the fix
The same page separates two ways of dealing with a fault. Reactive management treats the symptoms quickly after the problem occurs. Proactive management focuses on the real cause rather than its effects, and there accuracy matters more than speed.
A personal problem usually needs both moves, in that order: relieve the damage today, then look for the cause so the same day does not come back next week.
The page also gives a plain rule. A factor is the root cause if removing it prevents the problem from recurring. A causal factor affects the outcome, but removing it does not prevent recurrence with certainty. That rule is useful on your own problems because it can be asked of any candidate: if this were gone, would the problem stop coming back?
How to do a root cause analysis on a personal problem: state it as a fact
Write one line that a stranger could check. A label such as "disorganized" cannot be checked. "Leaves the house after 8:15 and reaches work late, three mornings a week" can. A good line names what happens, how often and where, and contains no cause and no blame.
This line becomes the top of the record, and a vague line produces a vague chain of answers.
Step 2: ask why, one link at a time
The most widely used method for the chain is five whys, an iterative technique that repeats the question why, each time directing it to the answer of the previous one. The page says the number of whys may be higher or lower depending on the problem, so five is a habit and not a rule. It credits the technique to Taiichi Ohno at Toyota, and describes its key idea as avoiding assumptions and logic traps by tracing the chain of causality in direct increments.
A direct increment is a small step: each answer must explain the one before it, not jump to a general theory about your character.
Write each link as a pair: the question and the answer. Keep them in order, top to bottom, so the chain can be read from the symptom down to the cause.
A worked example: arriving late three mornings a week
The example is invented, and it is small on purpose. Dana, a made-up person, writes the problem line: "Leaves the house after 8:15 and arrives late, three mornings a week."
- Why did Dana leave after 8:15? Lunch was still not packed at 8:00.
- Why was lunch not packed? Dana decides what to take only in the morning.
- Why is it decided in the morning? The kitchen has nothing planned or ready to grab.
- Why is nothing ready? The weekly shop is often skipped.
- Why is the shop skipped? Sunday is the only slot for it, and Sunday fills with other things.
The fifth answer points to a process that does not exist: the shop has no protected time. The page on five whys makes the same observation, that the real root cause often points toward a process that is not working well or does not exist. Replacing a lunch, a new lunch box or an earlier alarm would each treat a symptom. The first two would let the problem run on, as the fuse and the bearing do in the Wikipedia page's machine example, where replacing parts lets the machine run for a while but the problem recurs until the root cause is dealt with.
The fix Dana tries is to give the shop a second slot on Thursday evening. That is a guess about the cause, not a fact about it, and the next step says how to treat it as one.
Step 3: check each link before trusting the chain
A chain of whys is only a set of guesses until each link is checked. The five whys page records that others at Toyota and elsewhere have criticized the technique as too basic and arbitrarily shallow, which is a reason to check and not to abandon it. The checks are cheap.
- Look for evidence. Did lunch really still sit unpacked at 8:00 on all three mornings, or only on one?
- Ask whether the answer is the only one. Another cause could sit beside it. The page notes that one or several factors may constitute the root cause, and that the singular form is only customary.
- Apply the removal question. If a planned lunch existed every morning, would Dana still leave late on those three days?
If the third check fails, the chain stopped too early, or it followed the wrong branch. Go back one link and ask again from there.
Step 4: try the fix and record how it ended
A fix is also an attempt, and attempts need a record: what was done, how it ended, and why. In Problem Graph a solution is given an outcome of worked, partly or failed, and a failed solution stays on the map. The same three words work in a notebook.
For Dana, the entry reads: "Thursday evening shop, tried for three weeks. Partly: late mornings fell from three to one. The remaining one follows a day with a late meeting." The word "partly" is the useful part. It says the root cause was probably real but not the only one, and it opens a second chain starting from the one morning that is still late.
The record also guards against a common failure: trying the same idea twice because the first attempt was forgotten. An earlier post covers how to track what you tried to solve a problem in more detail.
One more caution comes from the Wikipedia page on root-cause analysis, and it applies to personal problems more than to machines: a cure can be worse than the disease. A root cause that is real may still be too expensive to remove. If Dana's cause had been a job that starts too early, the cure of changing jobs could cost more than the lateness does. Write the cost beside the fix, and when it is high, look for a smaller cause further up the chain or accept a partial result.
Frequently asked questions
How many whys should a personal problem take?
There is no fixed number. The five whys page says the number may be higher or lower depending on the problem. Stop when the next answer would be a process or a condition you can change, and not a feeling or a person.
What if every chain ends in the same cause?
That is a useful result. A cause that sits under several problems is worth fixing first, and a record that shows several problems with one cause makes it easy to see.
Is root cause analysis only for problems with a single cause?
No. The root-cause analysis page says one or several factors may constitute the root cause. Branch the chain when an answer has two parts, and follow each part.
What if the chain ends in another person's behavior?
Move one link back to what you can change, such as the request you made, the time you asked or the agreement that exists. A chain that ends in "they should be different" has no fix to try.
What a root cause analysis can and cannot show
A chain of whys explains a problem; it does not prove its answer. It is built from the memory and judgment of the person writing it, and each link can be wrong in ways that are not visible from inside. The checks in step 3 reduce that risk and do not remove it. A root cause is held as the current explanation, kept while the fix works and replaced when it does not. The chain says where to push, and the recorded outcomes say whether the push moved anything.