A Problem Tree is a group analysis tool used in Project Cycle Management (PCM) to make a messy situation discussable. It turns a pile of complaints, symptoms, and arguments into a shared cause-and-effect picture, so a partnership can agree what problem they are actually trying to solve, what is driving it, and what is merely an effect downstream - wikis.ec.europa.eu 
# What it is
The “tree” metaphor is literal. The trunk is the core problem (the negative situation you want to change). The roots are causes (what produces the core problem). The branches are effects (what the core problem leads to). The value is not the drawing. The value is the argument you have to resolve in order to draw it - fao.org
A Problem Tree showing how the roots are causes (what produces the core problem), and the branches are effects (what the core problem leads to).
# Where it sits in PCM
In a classic PCM sequence, the Problem Tree belongs in the analysis stage, before you start drafting activities, budgets, and outputs. In other words, it is a deliberate speed bump: you do not get to “solutions” until you have agreed what the problem is, and what you believe causes it - ec.europa.eu
# What it is for A Problem Tree helps a group do four things that are deceptively hard.
It separates symptoms from causes, so you do not fund an expensive response to a visible effect while leaving the root drivers untouched - fao.org
It makes assumptions visible, because cause-and-effect is where politics hides (and where your project risks will later live) - ec.europa.eu
1. It gives stakeholders a shared language for disagreement, because you can argue about “is this a cause or an effect” without arguing about who is a bad person - wikis.ec.europa.eu
1. It creates a clean bridge into the Objective Tree and then the Logical Framework Approach, because every negative statement can be flipped into a desired positive condition - learn.tearfund.org
# How to build one
A useful Problem Tree is usually built in a facilitated workshop with the people who live with the issue and the people who can change it. The steps below are simple, but they are not easy - fao.org
Start by agreeing the topic boundary and the stakeholder group in the room. If key voices are missing, the tree will politely mirror the blind spots of the people present.
Write problem statements as negative conditions that already exist, not as a lack of a solution. “Low trust between agencies” is a problem statement. “Need more training” is already a proposed intervention.
Choose the core problem. This should be specific enough to be actionable, and central enough that causes and effects can plausibly radiate from it.
Add causes and effects, one statement per card or sticky note, and keep asking the brutal question: “Does this directly cause that, or is there something in between.” Then reorder until the cause-and-effect chain is coherent.
Check the logic. Read it as sentences from roots to trunk to branches. If the group cannot read it out loud without wincing, it is not finished.
# Rules that keep it honest
Problem Trees fail when they become a performance. A few strict habits keep them useful - wikis.ec.europa.eu
Keep each statement testable. If someone asks “how would we know”, you should be able to imagine evidence.
Avoid mixing levels. “Policy is unclear” and “Frontline staff lack time” may both be true, but they sit at different layers. That is fine, as long as the causality between them is explicit.
Allow multiple roots. Real problems are overdetermined. If your tree has one root cause, it is probably propaganda.
Stop the tree from swallowing the world. If everything becomes a cause, you are doing sociology, not project design. Timebox and prioritise.
# Turning it into an Objective Tree
Once the problem analysis is agreed, PCM usually flips the Problem Tree into an Objective Tree (sometimes called a solutions tree). Each negative condition is rewritten as a positive condition, and the cause-and-effect chains become means-and-ends chains - learn.tearfund.org
An Objective Tree is the reverse of a Problem Tree.
This flip is where PCM becomes subtly moral. You are no longer describing reality. You are describing what you want reality to be, and claiming that certain means will plausibly lead to certain ends.
# How it feeds the logframe
The Problem Tree and Objective Tree provide the raw logic for the logframe: what you treat as core becomes a candidate for the project purpose/outcome; the “means” chain suggests outputs and activities; and the messy roots that sit outside your control often become assumptions and risks - ec.europa.eu
If you skip the tree, you often end up with a logframe that is internally tidy but externally untrue.
# Common failure modes The tree becomes a shopping list of interventions. If cards start with “create, deliver, build, train”, you have jumped ahead. Go back to negative conditions. The trunk is a vague abstraction. “Poverty” is not a helpful trunk unless your whole programme is that wide. “Irregular income among smallholder households in X district” is closer to something you can design for. Effects are treated as causes. A symptom can look like a driver if you do not ask “what produces this.” The tree exists to make you ask it. The group forces consensus too early. A good facilitator can park contested branches as alternatives until evidence or lived experience settles the argument.
# Facilitation prompts These questions are small levers that move a group from opinion to analysis.
> What is the evidence that this causes that?
> If we fixed this card, what changes would we expect to see?
> Is this inside our influence, or is it an external condition we must assume?
> Are we describing reality, or smuggling in a solution?