# Problem Tree Analysis: Map Hypotheses Without Inventing Causes

Build a useful problem tree: distinguish observations, hypotheses, and consequences, then check relationships before acting.

- Canonical URL: https://www.harmate.com/en/blog/problem-tree-analysis-map-hypotheses-without-inventing-causes
- Author: Harmate Team
- Published: 2026-10-04
- Updated: 2026-10-04T00:20:20.032111+00:00
- Language: en

## Content

# Problem Tree Analysis: Map Hypotheses Without Inventing Causes

A problem tree helps a group represent a situation it considers problematic, conditions that might contribute to it, and perceived consequences. It does not mechanically reveal a “root cause.” Its branches are propositions to examine: some may be grounded in observed facts, while others remain tentative interpretations. The value of the exercise lies as much in how relationships are checked as in the final diagram.

The method is often used when preparing a project or collective action. An FAO guide on agricultural mechanization strategy recommends formulating the central problem precisely and checking proposed relationships rather than confusing a preferred solution with a problem ([FAO mechanization strategy guide, section 3.2](https://www.fao.org/fileadmin/user_upload/ags/publications/AGST_WD_7.pdf)). Treat the tree as a revisable working map, not causal proof.

## Start with an observable situation

The central problem should describe an unsatisfactory state within a defined scope. “Learners lack motivation” already attributes a disposition to people. “In the month after training, few participants report using the procedure at work” is more bounded: it names a period, population, and behavior to document. The group still needs to clarify what “few” means, how the information was gathered, and who did not respond.

Before drawing branches, ask:

| Question | What it protects |
|---|---|
| What concrete situation concerns us? | Avoids an overly broad topic or label about people. |
| Who experiences it, where, and when? | Makes scope and missing voices visible. |
| What have we directly observed? | Separates available evidence from proposed explanations. |
| What change would make the situation preferable? | Helps distinguish the problem from a solution already selected. |

If several formulations remain in contention, keep them visible for a few minutes and discuss their implications. Do not force agreement merely to produce a neat diagram. The FAO’s participatory planning manual describes collective clarification followed by examination of relationships among problems; groups should be able to revise cards when a proposed link does not hold ([FAO participatory planning manual](https://www.fao.org/4/a0489f/a0489f.pdf)).

## Build branches that remain open to discussion

Once the central problem is provisionally framed, participants can separately note possible conditions and perceived consequences. One idea per card makes it easier to move suggestions without turning them too quickly into fixed categories. The group can then arrange cards: possible conditions or contributing factors below, possible effects or consequences above.

The words “possible” and “perceived” matter. A card’s position in the tree expresses a proposed relationship, not a demonstrated one. An arrow means, “we think this might contribute to that,” or “this might follow from that.” It does not mean “necessary cause,” “sufficient cause,” or “established effect.”

For each card and relationship, ask:

1. **Is this a situation or already an explanation?** “The handout was unavailable in two rooms” describes a checkable condition; “participants are disengaged” interprets behavior.
2. **What trace could help examine it?** Distribution records, dated observations, interviews, and follow-up data may illuminate different aspects.
3. **What other explanations are plausible?** Keep multiple branches when evidence does not distinguish the hypotheses.
4. **What would count against this proposition?** A useful hypothesis can be tested; a formulation that absorbs every objection cannot.
5. **Is the group confusing sequence with causation?** One event occurring before another does not establish that it produced it.

A link can be marked “to check,” “contested,” or “supported by this trace.” These notes make uncertainty visible without scoring people or opinions. If the group does not know where a card belongs, keep it in a “needs clarification” area instead of manufacturing a relationship.

## Fictional example: participants report not using a new procedure

Imagine a training team notices in a follow-up questionnaire that several respondents say they have not reused a new procedure. The group provisionally frames the problem as: “During the month after the session, 14 of 32 respondents report not yet using the procedure at work; 18 participants did not respond.” This describes the responses received; it does not show that nobody used it or explain why.

Possible cause cards might include: no opportunity since the session, difficulty accessing the document, a different instruction within the team, or a need for support on first use. Possible consequences might include a return to the previous procedure or a request for help, but those effects also need checking. The group keeps visible that it does not know how many nonrespondents used the procedure.

Rather than conclude that “the training did not work,” the team chooses two checks. The first is a closed question (“Did a situation calling for the procedure arise during the period?”) to count responses, followed by an open question asking respondents to describe those situations or what got in the way. The second is a check that the current version was accessible on the relevant workstations. The accounts add context but do not represent every participant. The two leads call for different actions: if no opportunity arose, a reminder may be pointless; if the document is hard to find, access is what needs fixing. The tree clarifies the next questions; it does not decide the intervention by itself.

| Proposed branch | Current status | Possible check |
|---|---|---|
| No opportunity to practice | Hypothesis to clarify | Ask whether a matching work situation arose during the period. |
| Document hard to find | Checkable hypothesis | Verify access to the correct location and current version. |
| Previous instruction still in use | Needs documentation | Compare instructions and ask how they were communicated. |
| Return to the previous procedure | Possible consequence, not measured | Gather work-situation examples while accounting for nonresponse. |

## Facilitate without imposing one story

A group tree also reflects who is present, the time available, and power relationships. Ask participants to generate ideas individually first, then invite them to explain the relationships they propose. A project lead may have good reasons to defend a hypothesis; their role does not make it automatically true or false. Facilitation should make disagreement discussable, not erase it.

Cards should use language the group understands. Avoid mixing organizational causes, feelings, solutions, and consequences in the same branch. An intervention such as “send a reminder” is not a cause; it is a candidate action. Move it to a separate “possible actions” area, then ask which hypothesis it addresses.

Problem tree analysis is not interchangeable with other tools. A [fishbone diagram](https://www.harmate.com/en/blog/fishbone-diagram-5m-method-example-and-hypotheses-to-test) arranges possible factors around an effect using chosen categories; [the five whys](https://www.harmate.com/en/blog/5-whys-an-example-for-tracing-causes-without-inventing-certainty) explore a chain of questions, with a risk of reducing a complex situation to one branch. A [project lessons-learned review](https://www.harmate.com/en/blog/project-lessons-learned-method-questions-and-an-adaptable-template) instead starts from a project’s course and the learning to draw from it. The tree is better suited when several conditions and consequences intertwine and a project needs framing before action. These methods can complement one another.

## From a map to a proportionate decision

At the end of the workshop, keep the central problem, selected branches, disagreements, links still to check, and sources to seek. Do not silently remove minority ideas: they may indicate that another group or setting should be consulted. Record who participated, when, and for what purpose; the tree is not a complete representation of every experience.

The next decision might be to gather missing information, consult absent people, test a limited action, or reframe the problem. In logical framework approaches, the tree is often converted into an objectives tree, with each problem restated as a desired situation; that conversion carries over any unchecked links unless they were sorted out first. An action is more defensible when it targets a sufficiently documented relationship and the team plans how to observe its effects. When several hypotheses remain plausible, comparing explanations or postponing a major intervention may be more responsible than choosing the branch that sounded most convincing in the room.

To prepare that inquiry, a team can collect responses or import already gathered data, then examine themes and their associated verbatim excerpts. Harmate can help organize this material and prepare a revisable report; people remain responsible for interpretation, checking relationships, and making decisions. A tree is therefore a support for discussion and inquiry, to be updated when new observations change how the situation is understood.

### Sources and further reading

- [Karim Houmy, *Guide de formulation d’une stratégie de mécanisation agricole. Étude de cas : stratégie nationale de la mécanisation agricole au Mali* (FAO, 2008), section 3.2](https://www.fao.org/fileadmin/user_upload/ags/publications/AGST_WD_7.pdf): in French; an example of participatory problem analysis in the agricultural sector.
- [Martin L. van der Schans et al., *Manuel : Diagnostic participatif rapide et planification des actions d’amélioration des performances des périmètres irrigués. Application à l’Afrique de l’Ouest* (FAO, APPIA project), Appendix A, tool 20](https://www.fao.org/4/a0489f/a0489f.pdf): in French; a contextualized description and example of a problem tree with agricultural producers.