Request a consultation
Skills & Careers10 November 2026EMPO

Problem solving tools for teams

Three simple root cause tools for NGO teams: the 5 Whys, the fishbone diagram and the problem tree. Steps, examples and when to use each one.

Short answer

Use the 5 Whys for a clear single problem, a fishbone diagram to sort many possible causes into groups, and a problem tree to map causes and effects for a larger issue. Define the problem in one sentence, work as a group, include field staff and partners, and test each cause against evidence before you choose an action.

Key points

  • Define the problem in one clear sentence before you start.
  • 5 Whys suits simple problems; fishbone and problem tree suit complex ones.
  • Work as a group and include people who know the field.
  • Test each cause with evidence, not opinion.
  • Do not jump to solutions until the root cause is agreed.

Why use a problem solving tool?

Teams often fix symptoms. A report is late, so someone works overtime. A distribution is delayed, so the team sends a reminder. Next month the same problem returns. A root cause tool helps you ask why the problem keeps happening, so you can fix the cause once.

The Tearfund problem analysis guide says problem analysis helps you understand what drives a situation and where to use your resources for the most impact. It is best done as a group, because different people see different parts of the problem. Include in-country staff and partners, because people outside the country rarely see the same dynamics.

Which tool should I choose?

ToolBest forTime
5 WhysA single, clear problem30 to 60 minutes
Fishbone diagramMany possible causes that need sorting1 to 2 hours
Problem treeA larger issue with causes and effects2 hours or more

Northwestern University's network guide says the 5 Whys is best for complicated problems from one group of causes, and weaker for multifaceted problems. Fishbone diagrams suit problems with unclear causes. Root cause trees suit long-running, multi-layer problems.

How do I use the 5 Whys?

Follow these steps.

  1. Write the problem as one specific sentence. For example: "Monthly reports from Township B arrive five days late."
  2. Ask: why does this happen? Write the answer.
  3. Ask why again about that answer. Write it down.
  4. Continue until the team agrees you have reached a cause you can act on. Five rounds is a guide, not a rule.
  5. Check each answer. The Elrha Humanitarian Innovation Guide says each answer should be plausible, credible, backed by evidence and objective.

Example: reports are late because data arrives late. Data arrives late because enumerators upload once a week. They upload once a week because mobile data is expensive. Data bundles are not in the budget. The root cause is a budget gap, not slow staff.

A tip from Tearfund: resist "fix-it" mode too soon. Keep digging until the root issue is clear.

How do I draw a fishbone diagram?

A fishbone diagram, also called a cause and effect diagram, sorts ideas into groups.

  1. Agree on the problem and write it in a box on the right. This is the head of the fish.
  2. Draw a line to it, the spine.
  3. Brainstorm the main causes and write them as bones leading from the spine. Typical groups are people, process, resources, context and partners.
  4. For each bone, ask "why does this happen?" and add sub-causes.
  5. Look at places where there are few ideas. The group may have missed something.

The result shows patterns. Often the same cause appears under two bones, which signals where to act first.

How do I build a problem tree?

A problem tree shows causes below the problem (roots) and effects above it (branches).

  1. Write the main problem in the middle, the trunk.
  2. Add direct causes below it. Ask "why does this exist?"
  3. Add causes of those causes. Tearfund suggests three to five levels. Fewer than three may miss the real issue, and more than five becomes too complex.
  4. Add effects above the trunk. Ask "then what happens?"
  5. Review the tree as a team. Mark the root causes that you can influence.

A problem tree is useful at design stage. It feeds directly into your objectives and your logframe. Tearfund notes that analysis should be reviewed during the project, for example at a mid-term review.

How do I keep the session honest?

  • Use evidence. Bring data, reports and field notes. Mark opinions as opinions. See critical thinking for programme staff.
  • Invite quiet voices. Ask each person to write on cards first, then share.
  • Include the affected people where it is safe and possible. The Elrha guide says how a problem is defined, and who defines it, is critical to how it is addressed.
  • Be careful with sensitive causes. Some causes involve conflict or power. In insecure contexts, do not record names or details in widely shared documents.

What mistakes should I avoid?

  • Starting without a clear problem statement.
  • Stopping at the first cause, which is usually a symptom.
  • Blaming a person instead of a process.
  • Listing causes you cannot influence and ignoring those you can.
  • Ending without actions. Track actions in an issue log or action tracker.

How EMPO can help

EMPO is a reliable, Yangon-based training and consultancy provider and one of Myanmar's leading names in practical NGO training, with 1,200+ people trained and 15 partner organisations. We teach project management, MEAL and Organisational Development, online or in person across Myanmar, in English and Burmese, and can design a session around your own team's problems. See our training services or contact us.

Sources

Questions people ask

How many whys should I ask?

Five is a rule of thumb. The Tearfund problem analysis guide says you may need to ask why more or fewer than five times before you reach the root cause.

Can we do this online with a remote team?

Yes. Use a shared whiteboard or a shared document. Ask each person to add causes on their own first, then discuss together.

What do we do after we find the root cause?

Turn it into an action with an owner and a date, and add it to your action tracker. Check later whether the problem has changed.