Problem tree analysis is a visual method for exploring a focal problem, its possible causes, and its consequences. The central issue forms the trunk, causes form roots, and effects form branches. Its value is the discussion and investigation it organizes. A completed tree does not, by itself, prove a causal explanation.
You may encounter the method as árbol de problemas in Spanish or arbre à problèmes in French. The core distinction stays the same: what is happening, what might produce it, and what follows from it. Keep those three levels separate before discussing solutions.
ODI's problem tree planning guide describes the focal-problem, causes, and consequences structure. The evidence labels, workshop sequence, and example below are practical additions for team use.
When should you use a problem tree?
Use a tree when several explanations compete, the problem crosses roles, or proposed solutions address different parts of the system. It can help a support team examine repeated escalations or a delivery team investigate late approvals.
Choose another method when the decision is already straightforward. A small, well-understood defect may need a direct fix and verification. A serious incident may require a formal timeline and an approved incident process. The tree can support that work, but it does not replace evidence preservation or specialist investigation.
A tree is also a poor substitute for asking affected people. A room of managers can produce a coherent explanation of a user's problem without ever checking the user's experience. Include those perspectives before the diagram becomes authoritative.
Start with a bounded focal problem
Write one observable issue in the center. “The project is a mess” is too broad. “Content approvals for the current release repeatedly arrive after implementation begins” identifies a process and a context.
Check whether the statement contains an assumed cause. “Approval delays caused by careless stakeholders” already chooses an explanation. Remove the attribution and investigate the conditions instead.
Keep a note beside the tree with the period, affected group, and evidence available. If participants disagree about whether the focal problem exists, resolve that disagreement or narrow the scope before building more branches.
Build the tree in five steps
- Describe the focal problem. Use one sentence and record its limits.
- Add direct possible causes below it. Ask what condition could produce the observed issue.
- Explore causes of those conditions. Stop when evidence runs out or the discussion leaves the chosen scope.
- Add effects above the problem. Ask what changes for users, teammates, or the organization when it occurs.
- Inspect every connection. Explain why one card could lead to the next and what evidence would challenge that relationship.
Avoid a rule that every root needs the same number of levels. A neat diagram is not the goal. One branch may be well understood while another remains a question.
Worked example: late approval of release content
Hypothetical example: a product team notices that release content frequently changes after implementation starts. They choose one recent release as the initial scope rather than claiming the problem affects every project.
Their first tree looks like this:
| Layer | Card | Current evidence |
|---|---|---|
| Effect | Implementation must be revised | Change history shows two revisions |
| Effect | Support receives final wording late | Handoff date recorded in release notes |
| Focal problem | Content approval arrives after implementation begins | Dates from the current release |
| Possible direct cause | No explicit point for requesting approval | Process walkthrough; needs confirmation |
| Possible direct cause | Reviewer availability is assumed | Interviews with two participants |
| Deeper possible condition | Ownership changes by content type | Conflicting instructions in two documents |
The team resists adding “reviewers do not prioritize the work” as a fact. That may be one explanation, but the current evidence also supports ambiguity about who should review and when.
They choose to test the ownership branch first. The investigation is modest: compare the documented approval route with the actual route for five recent content changes. If ownership was clear in those cases, they will revise the tree rather than defend the diagram.
Add evidence labels to the cards
Use three simple labels: observed, supported interpretation, and untested hypothesis. These are working labels, not scientific certainty scores. Add an evidence link or a short note explaining the label.
For important arrows, record the proposed mechanism. “Unclear ownership leads to a late approval request” explains more than placing the two cards near each other. Ask what else could explain the same observation and whether an exception challenges the connection.
Be particularly careful with effects expressed as money or customer loss. A late approval can create rework, but that does not establish a specific revenue impact. Keep financial claims separate until someone can show the calculation and its assumptions.
Run a 50-minute workshop
Use the first ten minutes to agree on scope and evidence. Give participants seven minutes to write causes and effects silently, then spend fifteen minutes arranging cards and explaining relationships. Reserve ten minutes for evidence challenges and eight minutes to select an investigation.
The facilitator should ask, “What would we expect to observe if this were true?” That question turns a confident opinion into something the team can test.
Park solution ideas beside the tree. Do not discard them, but do not let “buy a new tool” become a root cause. After the tree is credible enough to guide action, compare responses against the selected condition.
For a group already collecting observations in a retrospective, bring only the selected theme into the tree workshop. Trying to map every card at once creates an unmanageable forest.
Turn the tree into action
Choose a branch using three criteria: its importance to the focal problem, the strength of current evidence, and the team's ability to investigate or influence it. A highly influential branch outside your control may need escalation; a weaker but testable branch may be the right first experiment.
Record a short investigation card:
- Relationship to test: which cause-and-effect connection matters?
- Evidence needed: what observation could support or challenge it?
- Owner and access: who can obtain that evidence appropriately?
- Decision date: when will the tree be revised?
- Possible next action: what decision depends on the result?
An objectives tree can later restate selected conditions as desired outcomes. Do not assume reversing the wording establishes a workable solution. “Ownership is clear” still needs a mechanism, a person maintaining the rule, and a way to detect ambiguity.
Use a simple retrospective idea for the follow-up conversation and inspect whether the selected change altered the original problem. Our improvement guide explains how to keep that learning visible.
Frequently asked questions
Is a problem tree the same as a fishbone diagram?
Both can organize possible causes. A problem tree explicitly connects a focal issue with causes and effects; a fishbone commonly groups possible causes into categories. Neither proves causality just by displaying it.
How many root causes should a problem tree have?
There is no useful universal number. Include relevant branches supported by the scope and evidence, then prioritize investigation instead of trying to fill a symmetrical diagram.
Can a problem tree include positive outcomes?
Keep the initial tree focused on the problem and its effects. You can create a separate objectives view afterward, while preserving which relationships remain assumptions.