Calculation Desk Project controls Open full desk

Decision Analysis / analysis brief

Decision trees: compare uncertain choices explicitly

Describe two options with their cost, probability of success and payoffs in each outcome to calculate both expected monetary values and the margin between them. The guide shows how to test the branches, expose assumptions and combine EMV with risk appetite.

Live reading

Calculator workspace

Enter a current project reading to update this decision signal.

1 — Decision tree — compare two options

EMV = −cost + p·payoff(success) + (1−p)·payoff(failure)

Each option is a branch: pay its cost, then chance decides between a success payoff and a failure payoff. The branch with the higher expected monetary value wins — on average. Classic uses: build vs buy, prototype vs commit, upgrade vs replace. Remember EMV is a long-run average; for one-shot, bet-the-company decisions, weigh the worst case too.

Full analysis

EMV(option) = − Cost
             + P(success) × Payoff(success)
             + (1 − P) × Payoff(failure)

Parameters

Option A — cost
Upfront cost of choosing branch A.
e.g. 40000
Option A — P(success) %
Probability branch A succeeds.
e.g. 60
Option A — payoff if success
Value delivered when A succeeds.
e.g. 100000
Option A — payoff if failure
Value (often 0, sometimes negative) when A fails.
e.g. 0
Option B — cost
Upfront cost of choosing branch B.
e.g. 10000
Option B — P(success) %
Probability branch B succeeds.
e.g. 30
Option B — payoff if success
Value delivered when B succeeds.
e.g. 60000
Option B — payoff if failure
Value when B fails.
e.g. 0

Results

EMV — Option A
Expected value of branch A after its cost.
EMV — Option B
Expected value of branch B after its cost.
Better option
The branch with the higher expected value, and by how much.

Charts

Expected value comparison
Which branch wins on average, and how wide a bet each one is.

What decision tree — compare two options actually answers

+

A decision tree makes uncertain options and their consequences visible.

Start with a clean definition. State the unit, time window, and whether each figure is planned, actual, or forecast. A result can be mathematically correct and still be operationally wrong when a team mixes calendar days with working days, approved budget with total cost, or a current snapshot with a period-to-date value. The calculator is transparent: change an input and watch the output move, then explain why it moved.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

Use the result as a signal in a control loop. If the reading is favorable, confirm that scope and quality have not been reduced to create a better number. If it is unfavorable, investigate the cause before prescribing a generic recovery action. A late schedule may reflect changed scope, a poor dependency, or a bad estimate. A risk score may reflect disagreement about scales rather than a change in exposure.

Uncertainty deserves an explicit sentence. Forecasts are conditional on their assumptions, and rankings are relative to the set of items being compared. Add a range where inputs are estimates, show sensitivity where one assumption dominates, and agree what evidence will cause the team to revise the reading. This makes the page useful for governance rather than just for producing a polished percentage.

Common mistakes are classification mistakes. People use a ratio as a percentage, add probabilities that belong to different branches, treat a reserve as a forecast, or compare values calculated with different boundaries. Another frequent error is false precision: reporting several decimal places when inputs were rough workshop estimates. Round for the audience, but keep the full browser calculation for traceability.

On a real project, pair the result with an owner and a next action. A metric without a response path is decoration. Decide who validates the inputs, who discusses the implication, and when the number is checked again. If the result crosses a threshold, define escalation before pressure arrives. If it remains stable, say what stable means and how long that conclusion may stand.

For exams and formal methods, use the stated formula and assumptions. For practice, add context the question leaves out: baseline changes, data quality, dependencies, stakeholder tolerance, and the cost of waiting. The best professional answer can be more cautious than the best multiple-choice answer. That is not indecision; it is disciplined interpretation.

Keep a small decision record with input values, date, source, result, interpretation, and action. When the project changes, do not overwrite history. Compare the new reading with the old one and explain the movement. This turns a one-time calculation into evidence about the system and gives a future project manager enough context to learn from the forecast instead of repeating its assumptions.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

For a worked reading, enter the example values above and write down the intermediate meaning before interpreting the verdict. First identify the baseline. Next identify the observed performance, probability, or variation. Then calculate the derived measure. Finally ask whether the direction and size of the result justify an action. This order keeps arithmetic from becoming a substitute for project judgment.

Worked through end to end

Enter the example values shown in the instrument, note the baseline, and read each output in the unit displayed. The point is to make the calculation reproducible, not to imply that one example predicts every project.

Step 1

Validate the inputs, read the derived result, and record the action it supports.

How to read the result

Interpret the verdict alongside scope, data quality, dependencies, and the date of the reading. The metric stops being useful when those boundaries are hidden or when a team treats a signal as a guarantee.

Mistakes that survive into real reporting

The most damaging mistakes are mixed units, stale baselines, false precision, and decisions made without an owner or review date. Keep the inputs and assumptions visible.

On the exam and on a real project

Use the formal method for a consistent answer, then add practitioner context: assumptions, uncertainty, stakeholder tolerance, and the cost of waiting.