What Is a Problem Tree?
A problem tree is a visual account of an undesirable situation: the focal problem sits in the middle, contributing causes below it, and consequences above it. Arrows express proposed cause-and-effect links. The purpose is to explain the situation before selecting activities, rather than starting with a preferred solution and inventing a problem around it.
A tree assembled in a workshop is a reasoned account, not proof of causality. Participants may know different parts of the situation, disagree about mechanisms, or lack evidence for an important link. Record those differences. A tidy diagram can conceal uncertainty just as easily as it can make an explanation clearer.
Use the analysis alongside a needs assessment and stakeholder analysis. Together they help establish whose problem is being described and who may be missing from the discussion.
Build the Tree Around a Specific Problem
Set the Boundary. Name the population, place and period. “Young adults cannot access suitable local employment” provides more direction than “poverty,” but still needs a locally meaningful definition of suitable employment. Separate differences between groups where a single statement would hide them.
Describe a Condition, Not a Missing Activity. “Applicants cannot demonstrate the skills employers require” is a problem statement. “There is no training center” already assumes a remedy. The second statement may prevent the group from considering recruitment practices, recognition of existing skills or transport.
Ask What Contributes to the Condition. Write each proposed cause separately. Keep asking what contributes to that cause until the next level stops helping the decision. There is no required number of levels. Put indirect influences below immediate causes and identify cross-links when one cause affects several branches.
Ask What Follows From the Condition. Place consequences above the focal problem. Check the direction of every arrow aloud: does the lower condition plausibly contribute to the upper one? If the relationship runs both ways, label the feedback rather than pretending the situation is purely linear.
Keep an Evidence Trail. Beside each important connection, record the source, an alternative explanation and what still needs checking. Separate observed conditions from participant interpretations. Where evidence conflicts, retain the disagreement and assign a proportionate next check.
A Worked Problem Tree
The following example is hypothetical. It illustrates planning choices, not findings from a real program.
A community learning service is concerned that enrolled adults frequently miss scheduled classes.
| Position | Hypothetical Statement | What to Check |
|---|---|---|
| Effect | Learners progress slowly through the course | Attendance and learning records, including other reasons for slow progress |
| Focal problem | Enrolled adults miss scheduled classes | Whether recorded absences reflect actual attendance and which groups are affected |
| Immediate cause | Class times conflict with paid work | Learners' schedules and differences by occupation |
| Immediate cause | The journey is difficult after dark | Travel routes, safety concerns and seasonal variation |
| Underlying condition | Scheduling decisions exclude some learner groups | How decisions were made and who could participate |
The tree does not establish that evening travel causes every absence. Illness, care responsibilities, teaching quality or inaccurate records may also matter. Seek explanations from people who stopped attending, not only those still available at class. Do not collect identifying or sensitive details in a public workshop record.
Turn Problems Into an Objective Tree
An objective tree describes a plausible improved situation. Begin by restating the focal condition as a desired outcome, then review the lower branches as possible means and the upper branches as possible benefits.
In the hypothetical example, “enrolled adults attend at times and places they can use safely” is more informative than “attendance problems solved.” A scheduling branch might become “class schedules reflect different work patterns.” A travel branch might become “learners can reach an accessible learning location.”
Do not mechanically reverse every negative statement. An improved condition may be infeasible, outside the project's authority, or dependent on a wider change. Remove an unsupported link, add a missing intermediate step, or revise an objective whose apparent solution creates another problem.
Test each proposed means-to-end connection. Would changing the lower condition help produce the upper one? Under what assumptions? Could flexible class times shift unpaid care burdens onto someone else? Would a different venue exclude another group? Record these questions before choosing a strategy.
Choose a Strategy and Carry It Into M&E
The objective tree is a set of options, not a commitment to fund every branch. Compare options against relevance to affected people, available evidence, feasibility, authority, resources, equity and possible harm. Document why some causes will be addressed and others will remain contextual assumptions.
In the hypothetical example, the service might first test alternative class times rather than open a new center. Specify the proposed mechanism and what evidence would lead the team to revise that choice. A manageable test can be preferable to an expensive response built on an uncertain explanation.
Carry the selected pathway into the theory of change. A logframe can then summarize the chosen objectives and measures. Keep the original problem analysis accessible so later monitoring can check whether the explanation still fits, rather than treating the first workshop diagram as permanent truth.
Common Mistakes
- Choosing the Intervention First. Reframe missing services as the conditions people experience before discussing remedies.
- Equating Agreement With Evidence. A shared explanation can still be wrong; identify the links that need confirmation.
- Hiding Power and Disagreement. Offer ways for less powerful participants to contribute without having to challenge an authority in public.
- Drawing an Endless Diagram. Stop when added detail no longer changes a strategy choice or a necessary evidence check.
- Measuring Only Activities. Monitor whether the targeted condition changes and whether the assumed pathway is working.
Frequently Asked Questions
Is a Problem Tree the Same as a Theory of Change?
No. A problem tree organizes explanations of an undesirable situation. A theory of change explains how a selected intervention is expected to contribute to change, including the assumptions behind its pathway. The first can inform the second without replacing it.
Must Every Cause Become a Project Objective?
No. Some causes lie outside the project's influence, have weak supporting evidence, or require an unacceptable trade-off. Keep them visible, record the implications, and choose objectives the project can reasonably pursue.
Last updated October 25, 20263 sources checked
M&E Studio also does this work for clients.
The team that writes and reviews this library takes on M&E system design, evaluation quality reviews, AI advisory and workflow automation.
problem tree analysis, objective tree, cause and effect tree