Researcher Hub

Problem Tree Analysis needs the right participants, but the facilitator matters more.

I have watched two facilitators run the same Problem Tree workshop — same participants, same focal problem, same protocol — and produce two different trees.

The facilitator shapes what causes become visible through dozens of micro-decisions: whose contribution gets probed further, whose gets summarized quickly, when to push deeper and when to move on, which root is placed at the bottom of the tree and which becomes a branch. These decisions appear procedural. They are analytically consequential.

I have reviewed hundreds of Problem Trees from Cambodia NGOs. The pattern is consistent: technical causes — knowledge gaps, resource limitations, capacity weaknesses — are mapped in detail. But the power dynamics, institutional incentives, and political interests that sustain those technical conditions are absent — or reduced to a single vague entry.

This is not always dishonesty. It is often a rational organizational response. A facilitator who names powerful economic interests as a root cause of illegal logging — or political patronage as a root cause of weak enforcement — is naming causes the project cannot address and relationships the organization cannot afford to damage. An unskilled or cautious facilitator steers away from those causes without the room even noticing.

A skilled facilitator does the opposite: designs the session to surface what institutional pressure tends to suppress, and builds validation steps that test the tree against evidence and against the voices of those who were not in the room.

What causes do you find most difficult to name in a Problem Tree — and what makes it difficult?

From From Problems to Impacts by Narith Khim (2026)

The most common design error I see across Cambodia is writing outputs where outcomes should be.

"Three training sessions conducted." "Materials distributed to 50 villages." These are outputs — things the project delivers and controls. An outcome is different: it is a change in the target group — what the specific people the project is designed to reach know, believe, or do differently as a result.

When you write outcomes as outputs, you build a monitoring system that measures delivery — not change. At the end of the project, you can prove you delivered. You cannot prove anything changed in your target group because of it.

A simple test: after every output, ask "And then what happens in the target group?" That answer is your outcome. Outputs are what projects guarantee. Outcomes are what projects must influence. Confusing them produces designs that serve the report more than the people the project is meant to reach.

What output-written-as-outcome do you see most often?

From From Problems to Impacts by Narith Khim (2026)

From Problems To Impacts is available on Amazon now!

If you want to design stronger, results-based projects with confidence, join our 2-day in-class intensive training on Problem Tree, Results Chain, Logframe & Theory of Change.
📅 31 Jan – 1 Feb 2026
📍 Coffee Culture, Phnom Penh, Cambodia
🎓 Facilitator: Khim Narith, Project Design & MEAL Specialist
👉 Register now: https://forms.gle/EMH2wvdbjSuUqTsU8

អរគុណដល់ អង្គការក្តីសង្ឃឹមសម្រាប់ស្ត្រីកម្ពុជា ដែលបានផ្តល់ឱកាសឲ្យខ្ញុំ ជួយពង្រឹងសមត្ថភាពបុគ្គលិករបស់អង្គការលើជំនាញ ការគ្រប់គ្រង និងសរសេររបាយការណ៍គម្រោងដោយផ្តោតលើលទ្ធផល តាមរយះវគ្គបណ្តុះបណ្តាលចំនួន២ថ្ងៃ (27-28 ខែមិថុនា 2025)។