Decision Trees Without the Headache


Decision Trees Without the Headache

Decision trees are usually taught as arithmetic. The worked example has four branches, tidy probabilities that sum to one, and a single number at the end that announces the winner. Candidates come away able to compute an expected value for a problem they will never meet, and convinced that the technique belongs to people with more time than they have.

The version worth using is smaller and less mathematical. A decision tree lays out a choice so that the assumptions everybody is already making become visible and arguable. Most of its value arrives before the arithmetic, and the number at the end is the least interesting thing it produces.

What the tree is actually doing

A tree has three kinds of point on it. There are the moments where you choose, which are the options genuinely open to you. There are the moments where the world chooses, which are the uncertainties you cannot control. And there are the endings, each of which has to be given a value, because a comparison needs something to compare. Drawing it means saying out loud what could happen, roughly how likely each is, and what each outcome would be worth.

Section 5 of the PMBOK® Guide gathers the tools and techniques a project manager can reach for, and a decision tree is among the smallest of them. It is useful because it converts a disagreement about opinions into a disagreement about numbers, and the second kind is much easier to settle. Two people who feel differently about a supplier can argue indefinitely. Two people who have written down different probabilities have something to go and check.

A small one, built properly

A vehicle programme needed a revised mounting bracket. The durability test result was ten weeks away, and the engineering lead put the chance of failure at about thirty per cent. Hard tooling cost one hundred and eighty thousand pounds. Committing to tooling now meant that a failed test would mean scrapping it and cutting a second set, at the same cost again. Waiting for the result meant tooling afterwards and paying sixty thousand pounds of expediting to hold the launch date, whichever way the test went.

Tooling now therefore costs one hundred and eighty thousand, plus a thirty per cent chance of another hundred and eighty thousand, which comes to two hundred and thirty-four thousand. Waiting costs two hundred and forty thousand, flat. The gap is six thousand pounds on a quarter of a million, which is nothing.

That result is far more useful than a winner would have been. The two options are effectively level, so the money is not what should decide it, and the programme manager could stop treating the cost argument as the real argument.

Where the numbers come from

The question that gets the most out of a small tree is where the answer flips. Tooling now beats waiting while the chance of failure stays below about a third; above that, waiting wins. The engineering lead's estimate was thirty per cent, which sits close enough to the flip point that nobody should be confident either way. That sent the team back to look at the test history for comparable brackets, which was a better use of an afternoon than continuing to argue.

Probabilities need a stated basis sitting next to them. Thirty per cent drawn from the failure record of eleven similar components is a different object from thirty per cent produced in a meeting, even though both write down the same figure. Where no basis exists, the honest move is to say so and treat the tree as a way of finding the flip point, then ask whether anyone believes the true number is on the other side of it.

Values need the same discipline, and the trap is trying to price everything. A launch slip that damages a customer relationship, a safety consequence, a regulatory undertaking: none of those belong inside the arithmetic, because putting a figure on them buries the judgement that matters in a number nobody will question afterwards. Keep them out of the tree and on the table. Reading when a technique is genuinely carrying the decision, and when it is dressing up a judgement somebody has already made, is a distinction a structured PMP exam preparation course draws repeatedly across the risk techniques.

When a tree is the wrong tool

Four conditions make it a poor choice. A decision with more than a handful of genuinely distinct options produces a diagram nobody can read and a false sense of rigour. A decision where the probabilities are unknowable, as opposed to merely unknown, produces arithmetic resting on nothing. A decision dominated by a consequence you have deliberately refused to price belongs to a different conversation. And a decision that has already been taken somewhere else does not need a tree; it needs somebody to say so.

For a PMP® candidate, it helps to recognise that expected monetary value is a comparison device and not a forecast. A tree saying two hundred and thirty-four thousand does not predict that anybody will spend two hundred and thirty-four thousand: the actual outcome is one of the branches, and none of them is that figure. In any situation you are asked to judge, name the outcomes that could genuinely happen before quoting any average of them.

Twenty minutes on a whiteboard with the two people who disagree is usually enough for a contested decision. Draw the options, mark the uncertainties, put rough numbers on the endings, and find the flip point. Where the answer is lopsided, you have a decision and a clear rationale to record. Where it is close, which happens more often, you have learned that the money is not the deciding factor, and the conversation can move to the thing that is.

By Andre Malowney

Interested in going further?

Knowing when a decision tree will earn its half-day, and when it will produce a confident figure from numbers nobody can defend, is what separates useful analysis from decoration in a risk review. Omega's PMP® Exam Preparation works through the risk techniques in the context of the decisions they exist to serve.

Decision trees sit among the wider set of tools and techniques catalogued in the PMBOK® Guide Eighth Edition.