Influence Diagrams

Risk technique · See it on the map

Guide only — A diagram builder could serve this.

A network diagram showing how decisions, uncertain events, and outcomes affect one another.

When to use it

When a decision involves several interacting uncertain factors that would make a decision tree's branches multiply out of hand, and you want a single diagram that shows what depends on what without enumerating every combination explicitly.

When to avoid it

For a decision simple enough that a decision tree already communicates it clearly — an influence diagram trades the tree's readable branch-by-branch payoffs for compactness, and that trade isn't worth it when there's nothing to compress. It's also a weaker tool than a tree for actually walking a stakeholder through why a specific choice wins.

Steps

1. Identify the decision points, uncertain (chance) factors, and final outcome measures relevant to the situation.
2. Draw a node for each: typically a rectangle for a decision, an oval for an uncertain factor, and a diamond or rounded shape for an outcome value.
3. Draw an arrow between any two nodes where one directly influences the other — this is the diagram's main content, and getting it right requires genuinely understanding the causal structure, not just listing everything you know about.
4. Check the diagram for cycles; a decision-support diagram should resolve in one direction, decisions and chance factors flowing toward the outcome.
5. Use the diagram to identify which factors most directly drive the outcome, and to check whether a proposed decision addresses a real influence or a coincidental one.

What it produces

• A network diagram of decisions, uncertain factors, and outcomes with directional influence relationships marked.
• A shared, checkable picture of what the team believes drives the outcome — useful for spotting a disagreement about causation before it becomes a disagreement about the decision.

Common pitfalls

• Drawing every factor anyone mentions instead of only the ones with a real influence relationship, which produces a diagram too tangled to read — the opposite of what it's for.
• Treating the arrows as proven causation when they're really the team's working assumption; the diagram is only as good as the shared understanding behind it.
• Using this in place of a decision tree when a stakeholder actually needs to see the specific expected-value comparison between two named choices — the diagram doesn't compute a number the way a tree's EMV rollup does.

Worked example

A product launch decision involves three interacting uncertainties: competitor timing, manufacturing yield, and a regulatory approval date. Rather than drawing eight separate decision-tree branches for every combination, the team draws one influence diagram: an arrow from 'regulatory approval date' to 'launch window,' one from 'manufacturing yield' to 'units available at launch,' and one from 'competitor timing' to 'pricing decision.' The diagram makes visible that pricing and launch timing are influenced by different, independent factors — a fact the team had been implicitly treating as one combined risk.

Source

• PMBOK-6 §11.4.2.5

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.