Problem Tree Analysis: How to Find Root Causes

When It Matters

Problem analysis is how you come to understand the context you plan to work in, so you can see the key issues and where your resources will do the most good. It comes first in design because almost everything else rests on it.

The analysis can inform the concept note and the project baseline. It is the necessary groundwork for a theory of change, which means it also shapes how you will monitor, evaluate and learn later. Analyzing the issue can bring hidden assumptions into the open, and those assumptions are exactly what you need for the logframe and for managing risk.

It also shapes the intervention itself. The analysis is the basis and the justification for what you propose to do.

How It Works

The problem tree gives you a picture of the known causes and effects of one issue. Work through six steps.

Identify existing problems. Start from a needs assessment. Surveys, interviews, focus groups or meetings tell you what problems people face, how big they are and how important people think they are. List them.
Define the core problem. Pick one specific problem and state it as an existing negative situation. Write "crops infested with pests", not "no pesticides available".
Formulate causes. Ask what causes the core problem, then what causes that cause, and keep going toward the bottom root cause. A tree should have between 3 and 5 levels: fewer will not reach the underlying issues, and more becomes unwieldy.
Formulate effects. Go the other way. List what the core problem leads to, then what those effects lead to.
Draw the diagram. The focal problem is the trunk, the causes are the roots and the effects are the branches. Every problem should sit after the problem that causes it and before the problem it causes.
Review logic and validity. For each problem, ask whether the causes below it are enough to explain why it happens. Then test the causes against evidence, and where a cause rests on opinion, check it with a survey. If the data does not support it, take it off the tree.

The tree is only the first of three stages. Next comes the objective tree. Reverse each negative statement into a positive one, so that lack of awareness becomes increased awareness. You now have a solution tree that shows means and ends.

The third stage is the analysis of strategies, where you decide the scope. Not every objective can be reached at once, so you cluster and choose. Once you settle on a preferred intervention, the core problem (reversed) becomes the outcome, the reversed causes below it become activities and the reversed effects above it become longer-term outcomes. That structure feeds the logframe.

Key Components

A sound analysis has several linked parts, moving from a negative reality toward a planned response.

A specific core problem. It is an existing negative situation, not a lack of something, stated precisely: write "crops infested with pests" rather than "no pesticides available". A specific problem works better than a vague or broad one, which has too many causes for an effective project.
Causes and effects. Causes go in the roots, written in negative form such as lack of knowledge. Effects go in the branches, along with the effects of those effects.
Stakeholder analysis. For each stakeholder, record their key problems, their motivation, their potential to contribute and how best to interact with them. A simple table does the job.

Stakeholder	Key problems	Motivation	Potential to contribute	How to interact
[Group name]	[Specific issues]	[Why they care]	[Resources or influence]	[How to engage]

Evidence on what works. Researching which interventions are effective is one of the most critical steps and the one most often missed. Check previous programs and existing theories of change.
An objective tree. This is the bridge to the logframe. Turn the negatives into positives, and the team can see the outcome and the activities that lead to it.

Best Practices

Involve local staff, partners and beneficiaries. In-country staff belong on the analysis team because outsiders rarely read local dynamics as well. Bring in partners and beneficiary representatives too. Without shared analysis, partners may form different views of the issue and pull in different directions once implementation starts.
Size the group to the method. Problem tree work suits a small focus group of about six to eight people with flip chart paper. Even a larger workshop should have no more than 25 participants. Split into smaller groups, each producing its own tree, when the group is big, when women may speak less in front of men, or when you specifically want one group's view.
Let the discussion do the work. The conversation while you build the tree is the real value. Get a facilitator, a wall or whiteboard and sticky notes, and allow half a day or more. Keep a side list for ideas that do not fit, under titles like solutions, concerns and dilemmas.
Account for causes you will not tackle. Existing regulations are one example. If your intervention leaves a cause alone, it can still block your objectives, so carry it into the evaluation.
Share the finished tree. Show it to stakeholders and let them react.
Revisit the analysis. Understanding changes as work proceeds. Review the analysis at any mid-term review and again in the final evaluation to capture lessons.

Common Mistakes

Writing a lack of something as the problem. "No pesticides available" is a solution in disguise. Describe the situation instead, such as crops infested with pests.
Choosing a vague or over-broad problem. Saving water has too many causes for one project to handle.
Treating beliefs as verified causes. A brainstorm produces opinions, not findings.
Phrasing interpretations as problems. "The government is lazy" is a judgment. Say precisely what the negative condition is and stay with what can be observed.
Reading importance from position. Where a problem sits in the tree does not tell you how important it is. Judge importance on its own, not from the layout.

Example

In one program, community members believed that husbands blocking family planning was a root cause of unplanned pregnancy, and it went onto the problem tree. Before building on it, the team ran a survey. It showed that only 2% of women had this problem, so the team took it off the tree.

Had it stayed, the project would have been designed around a cause that few people share. The lesson is that community beliefs are a starting point: test each cause with a survey or existing evidence before it stays on the tree.