Problem trees are still worth the afternoon

The problem tree is the most skipped step in programme design and one of the most mocked artefacts in the sector. Both reputations are earned. It gets skipped because the deadline is the template, not the analysis, and nobody ever had a proposal rejected for not attaching a problem tree. It gets mocked because a generation of practitioners sat through workshops where the tree was built by consultants on someone else's flipchart, in a language half the room did not speak, to produce a diagram nobody opened again.

So the case for it has to be made narrowly, and the title is the claim. An afternoon. Not a fortnight, not a facilitated retreat, not a participatory planning event with a budget line. The question is whether a few hours of drawing cause-and-effect relationships buys anything that cannot be got another way, and the answer turns out to be yes, for one specific reason that has nothing to do with participation.

The one thing it does

Every methodological guide describes the same mechanics. The EuropeAid Project Cycle Management manual sets out three steps: define the framework and subject of analysis, identify the major problems faced by target groups and beneficiaries, and visualise those problems as a diagram establishing cause and effect. ECHO's version puts it more compactly, presenting the analysis in diagram form with the effects of a problem on top and its causes underneath.

The LFA guide prepared for the Serbian government states the purpose in a single clause that is worth lifting out. The exercise is essential, it says, to ensure that root causes are identified and not just the symptoms of the problem.

That is the whole argument. A problem tree is a machine for distinguishing a cause from a symptom, and it works because the structure forces the distinction. You cannot place a card on the diagram without deciding whether it sits above or below the thing next to it, and that decision is a causal claim you have to defend in front of whoever else is in the room. The guiding question the guides prescribe, asked repeatedly down the tree, is "what causes that?"

Nothing else in the design toolkit makes you answer it. A logframe asks you to state an outcome, and you can state one without ever having tested whether it addresses a cause or a consequence. A theory of change asks for a causal pathway, which is closer, but it typically starts from the change you intend rather than from the situation you found, and starting from the intended change is precisely how you end up defending a preconceived intervention.

The mirror is why it saves time

There is a mechanical payoff that gets less attention than it should, and it is the reason the afternoon pays for itself rather than costing extra.

The objective tree is the problem tree inverted. Every negative statement becomes its positive counterpart, and the structure carries over unchanged. The central problem becomes the specific objective. The consequences sitting above it become the overall objective. First-level causes become outputs. Second and third-level causes become activities.

So the tree is not a separate deliverable that then has to be translated into a logframe. It is the logframe, drawn in a form that makes its causal claims visible before they are hidden inside a table. A team that has spent an afternoon on the tree has already done the hardest part of filling in the first column, and has done it in an order that surfaces disagreement early.

The EU guidance is also clear that this runs iteratively rather than as a one-way pipeline. One EuropeAid-based training manual is explicit: as you define the objectives tree from the problem tree, you check whether the problems were clearly identified and whether the logic still holds, and you can and should be altering the problem tree as you go. The tree is a working surface, not a record.

What goes wrong without it

The sharpest statement of the cost comes from an organisation's own toolkit rather than from any critic, which is what makes it credible.

WWF's cross-cutting tool on logical framework analysis says that developing a project logframe without having effectively gone through the participatory planning exercises it describes is the quickest way to develop a project that is unsustainable and does not adequately address real concerns among stakeholders. Then the line that matters: one of the pitfalls of the logical framework is that it is quite possible to prepare highly structured projects which appear to meet the logical framework requirements, but which are neither well focused nor needs oriented.

That failure mode is specific and it is invisible at review. The logframe validates. The vertical logic holds, in the sense that the outputs plausibly produce the outcome. Indicators are SMART, targets are numbered, assumptions are populated. Every check a reviewer can run comes back clean, because every check a reviewer can run is internal to the document.

What no internal check catches is an intervention aimed at a symptom. A programme that observes low clinic attendance and designs an awareness campaign has a coherent logframe. Whether attendance is low because people do not know about the clinic, or because the clinic has no staff on Tuesdays, or because the road floods for four months, is a question the logframe never asks. The problem tree asks it in the first twenty minutes, because somebody has to decide what goes underneath "low attendance" and the candidates are not equivalent.

What the critics got right

The case against the problem tree is serious and it should be stated at full strength, because the version of the tool defended here survives it only by being much smaller.

Robert Chambers and Jethro Pettit's critique of the logframe makes the argument about power rather than method. Donor-induced logframe meetings rarely include poor people, they note, while participatory poverty assessments present much evidence that the priorities of poor people often differ from those perceived by others. In those meetings expatriates often dominate and the language is English.

Their objection to ZOPP, the German variant where the problem tree originates, goes to the structure directly. The idea that stakeholders should brainstorm until they agree on one single core problem involves a reductionism that flies in the face of multiple and changing realities. That is not a complaint about facilitation quality. It is a claim that forcing a room to converge on one focal problem destroys information, and it is correct.

Bakewell and Garbutt's review for Sida found the related distortion in the partnership: the local NGO has to adapt to an alien way of thinking while the foreign partner does not need to adapt to the local context. They also record practitioners who would rather present their thinking as narrative, or visually, or as stories, and who found the conversion into framework language was performed for them by somebody else.

None of that is answered by insisting the tree is methodologically sound. It is an objection to what the exercise does in a room where one party controls the money.

Why the afternoon survives the critique

The critique lands on the workshop, not the diagram. That distinction is doing a lot of work and it is worth being precise about it.

Almost everything Chambers and Pettit object to is a property of how the analysis was staged: who was in the room, who set the language, whose flipchart it was, and the requirement to converge on a single agreed core problem before anyone could leave. Strip those away and what remains is a causal diagram that a programme team can draw among themselves in three hours, on the basis of what they already know and what their field staff have already told them.

That version makes no participation claim, which is the point. It is not a substitute for talking to the people affected, and pretending otherwise is the abuse Bakewell and Garbutt documented. It is an internal thinking tool that helps a team notice it has confused a symptom for a cause before it commits that confusion to a contract.

The reductionism objection also weakens at that scale. A team drawing its own tree does not have to converge on one core problem, because nobody is going to hold the room hostage until it does. Multiple roots can sit on the diagram unresolved, and the disagreement about which one matters is itself useful information to carry into design. The single-focal-problem rule was a facilitation device for getting large heterogeneous groups to a decision by Friday. It is not load-bearing.

What does not survive is the claim that the tree makes a design participatory. It never did, and the sector spent twenty years pretending otherwise.

Where this stops

Two limits, and the first one is more damaging than it looks.

The tree assumes the causal structure is knowable at design time by the people in the room. In a stable sector with a well-understood problem, that assumption mostly holds. In a rapidly changing context, in a conflict setting, or in any programme where the mechanism is genuinely uncertain, it does not, and a confidently drawn tree can lock in an early hypothesis with more authority than it deserves. A diagram on a wall is more persuasive than a paragraph of hedged prose, which is a property of diagrams generally and a hazard here specifically.

The second is that none of this is measured. There is no study comparing programmes designed with a problem tree against programmes designed without one, holding sector, budget and team capacity constant. The argument above rests on what the tool does mechanically, on WWF's statement of what goes wrong without it, and on the fact that every major methodological tradition prescribes the same step, which is suggestive and is not evidence of effect.

That absence is unsurprising and it is also a bit embarrassing for a sector that requires attribution evidence from everyone it funds. The step that is supposed to establish causal reasoning has never had its own causal claim tested, and the strongest honest defence of it remains that it costs an afternoon and the alternative failure is invisible until year two.

---

Sources

Method guidance

• Project Cycle Management Manual, European Commission EuropeAid. Source for the three steps of problem analysis and the definition of the exercise as establishing cause-and-effect relationships between existing problems
• Manual Project Cycle Management, European Commission DG ECHO (June 2005). Source for the two-stage structure of the logframe approach, the four steps of the analysis phase, and the convention of effects above and causes below
• Guide to the Logical Framework Approach, Government of the Republic of Serbia. Source for the statement that the exercise is essential to identify root causes and not just symptoms, and for the numbered construction steps including the guiding question "what causes that?"
• Basic Introduction to Project Cycle Management Using the Logical Framework Approach, Umhlaba Development Services, structured against the EuropeAid handbook. Source for the iterative instruction to revise the problem tree while building the objectives tree

The cost of skipping it

• Cross-Cutting Tool: Logical Framework Analysis, WWF. Source for the warning that building a logframe without the preceding analysis is the quickest route to an unsustainable project, and for the observation that a highly structured project can meet every logframe requirement while being neither well focused nor needs oriented

The critique

• Logframe: A Critique, Robert Chambers and Jethro Pettit. Source for the power analysis, the observation that donor-induced logframe meetings rarely include poor people, the dominance of expatriates and English, and the argument that ZOPP's single-core-problem rule involves a reductionism that flies in the face of multiple and changing realities
• The Use and Abuse of the Logical Framework Approach, Oliver Bakewell and Anne Garbutt, Sida (November 2005). Source for the asymmetry in which the local partner adapts to the framework while the foreign partner does not adapt to the local context, and for practitioners who would rather present their thinking as narrative or story. Hosted by PM4DEV