What is expected monetary value?
Expected monetary value is the probability-weighted average financial outcome of an uncertain event or decision. You multiply each possible outcome’s monetary impact by its probability, then add the results. The formula is:
EMV = Σ (probability × impact)
Three properties make it useful. Outcomes must be mutually exclusive and collectively exhaustive, probabilities must sum to 1.0, and impacts must be expressed in money — including negative values for costs and losses.
A single risk with a 30% chance of costing $100,000 has an EMV of 0.30 × (−$100,000) = −$30,000. An opportunity with a 20% chance of saving $50,000 has an EMV of 0.20 × $50,000 = +$10,000. Together they net to −$20,000 of expected exposure. Neither number is a prediction. They are the average result if you could run the same situation many times.
> Important note: EMV is not the most likely outcome. A risk with a 10% chance of a $1,000,000 loss has an EMV of −$100,000, even though the most likely outcome is that nothing happens at all. That gap between “average” and “likely” is where most misinterpretation starts.
How do you calculate EMV step by step?
You need three things per outcome: a complete list of possibilities, a probability for each, and a monetary impact for each. The arithmetic is trivial; the discipline is in the inputs.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.
Step 1: Define the decision or risk precisely
“Vendor delay” is not a risk; “the integration vendor delivers the API two weeks late, delaying the billing module” is. Precision matters because it determines both the probability and the impact. Vague risks produce vague numbers that nobody acts on.
Step 2: List mutually exclusive outcomes
For a risk, the simplest complete set is “occurs” and “does not occur.” For a decision, list each scenario: on time, delayed, failed. If your outcomes overlap or leave gaps, the probabilities will not sum to 1.0 and the total will be wrong.
Step 3: Assign probabilities from evidence
Use historical frequency where you have it: if 4 of your last 12 similar integrations slipped by two weeks, 33% is a defensible starting point. Where you have no data, use three-point estimates from the people doing the work and record the source.
Step 4: Quantify impact in money, not severity labels
Translate “high impact” into currency: rework hours × loaded rate, penalty clauses, extended overhead, delayed revenue. If an impact cannot be monetized, keep it out of the EMV and manage it qualitatively — do not assign it a fake number.
Step 5: Multiply and sum
For each outcome, multiply. Then add. Check that probabilities sum to 1.0 and that the sign convention is consistent — threats negative, opportunities positive. A quick sanity check: the EMV must sit between the best and worst outcome.
Worked example: one risk, two outcomes
A data migration has a 30% chance of a failed cutover requiring a rollback and a second attempt.
| Outcome | Probability | Impact | EMV |
|---|---|---|---|
| Clean cutover | 0.70 | $0 | $0 |
| Failed cutover | 0.30 | −$80,000 | −$24,000 |
| Total | 1.00 | — | −$24,000 |
The project should carry $24,000 of expected exposure for this risk. Note what the calculation does not say: it does not say to budget $24,000 for the migration. It says that across many similar migrations, this risk costs about $24,000 each on average.
How do you use EMV to size a contingency reserve?
Add the EMVs of every identified risk in the register, net out the opportunities, and use the result as the starting point for your contingency reserve. Then adjust upward for risk appetite and for the fact that EMV represents a 50th-percentile outcome, not a safe one.
Here is a five-risk register for a $900,000 software project.
| ID | Risk | Probability | Impact | EMV |
|---|---|---|---|---|
| R1 | Key developer leaves mid-project | 25% | −$120,000 | −$30,000 |
| R2 | Third-party API changes without notice | 20% | −$60,000 | −$12,000 |
| R3 | Security review finds critical issues | 40% | −$45,000 | −$18,000 |
| R4 | Client delays content sign-off | 50% | −$20,000 | −$10,000 |
| R5 | Hardware procurement slips | 15% | −$80,000 | −$12,000 |
| O1 | Reusable component built early | 30% | +$40,000 | +$12,000 |
| Net EMV | −$70,000 |
The naive reserve is $70,000, or 7.8% of the $900,000 budget. That number has a specific meaning: if these risks behave as modeled, $70,000 is the expected cost. It is not the amount that keeps you safe 80% of the time.
Two adjustments are worth making. First, if the organization needs an 80% confidence level rather than 50%, the reserve must exceed the EMV — how much depends on the shape of the distribution, which is why Monte Carlo simulation exists. Second, EMV sizing works when risks are independent. If R1 and R5 are correlated (both depend on the same supplier), the combined exposure is larger than the sum suggests, and simple addition understates it.
A useful governance rule: reserve the net EMV as the base contingency, then document the confidence level it represents and what happens if exposure exceeds it. PMI’s guidance is clear that contingency covers known risks, while unknown risks belong in a separate management reserve — mixing the two is how reserves get raided for scope changes.
How does EMV work inside a decision tree?
A decision tree lays out choices, chance events, and payoffs, then rolls back from the end to the start. At each chance node you calculate an EMV; at each decision node you choose the branch with the higher value. The result is a defensible comparison between options with different risk profiles.
Worked example: build in-house or outsource
A company must deliver a platform module. Option A builds in-house for a fixed $180,000. Option B outsources for $150,000 but carries more delivery uncertainty.
| Option | Scenario | Probability | Cost | EMV contribution |
|---|---|---|---|---|
| A: In-house | On time | 70% | $180,000 | $126,000 |
| A: In-house | Two-week delay | 30% | $220,000 | $66,000 |
| Total A | 100% | $192,000 | ||
| B: Outsource | On time | 50% | $150,000 | $75,000 |
| B: Outsource | Delay and rework | 40% | $210,000 | $84,000 |
| B: Outsource | Vendor failure, rebuild | 10% | $300,000 | $30,000 |
| Total B | 100% | $189,000 |
Outsourcing wins by $3,000 in expected cost — a margin so thin it should not decide anything on its own. That is the honest lesson of the example. Option B is cheaper on average but has a 10% chance of a $300,000 outcome, which is 60% worse than the in-house worst case. An organization with thin reserves should take Option A despite the slightly higher expected cost, because it cannot absorb the tail.
That is not a failure of EMV. It is EMV doing its job: producing a number precise enough to argue about, and exposing the risk profile that the number hides.
Worked example: bid or no-bid
EMV is also used to price the cost of pursuing work. Suppose bidding costs $15,000 in proposal effort. If you win — a 40% chance — the contract yields $300,000 of profit. If you lose, you recover nothing.
- Win: 0.40 × $300,000 = +$120,000
- Lose: 0.60 × $0 = $0
- Gross EMV of bidding: $120,000
- Net of bid cost: $120,000 − $15,000 = +$105,000
The bid is worth pursuing on expected value, provided the 40% win probability is realistic. If the true win rate is 10%, the EMV becomes $30,000 − $15,000 = +$15,000, and the effort is probably better spent elsewhere. Small changes in probability move the answer more than most people expect, which is why probability calibration deserves more attention than the multiplication.
What does a positive or negative EMV actually mean?
A negative EMV means the expected outcome is a net cost; a positive EMV means the expected outcome is a net benefit. Neither is a verdict on whether to proceed. The number tells you the average result, not the range, and decisions are made by organizations that experience one outcome, not the average of many.
This distinction has a formal name. An organization that maximizes EMV is risk neutral: it is indifferent between a guaranteed $50,000 and a 50% chance of $100,000. An organization that is risk averse applies a utility function, where the pain of losing $100,000 outweighs the pleasure of gaining the same amount. PMI’s work on decision trees makes the point directly: a wager with symmetrical +$100 and −$100 outcomes has an EMV of zero, and a risk-neutral organization is indifferent, while a risk-averse one refuses it.
Most real organizations are risk averse, especially with money they cannot replace. That does not invalidate EMV; it means EMV is the first filter, not the final decision. Use it to eliminate options that are clearly worse, then examine the survivors’ worst cases before choosing.
Practical interpretation rules that hold up:
- Treat EMV as a comparison tool, not a forecast. It is most useful when ranking options, least useful when quoted alone in a status report.
- Always report the range next to the average. “EMV is −$24,000, worst case −$80,000” is a decision aid. “EMV is −$24,000” is a number that invites the wrong conclusion.
- Check whether the decision is repeatable. Portfolio-level decisions (which of 40 projects to fund) behave like the average. One-shot decisions (this factory, this acquisition) do not.
When is EMV the wrong tool?
EMV fails in five recognizable conditions.
The decision is genuinely one-shot. A company builds one headquarters, launches one product, runs one migration. There is no “many repetitions” over which the average asserts itself. The expected value may be positive while the realistic downside is fatal.
Tail risk dominates. Low-probability, high-impact events are exactly where EMV is least informative. A 2% chance of a $10 million loss contributes −$200,000 to the total, which looks manageable on paper and is catastrophic in practice. Reserve sizing for tail risk needs confidence levels, not averages.
Probabilities are guesses dressed as data. If the probability comes from a workshop where nobody had historical data, the EMV inherits that uncertainty and adds a misleading decimal point. Record the source and confidence of every probability, or the model is theater.
Risks are correlated. EMV addition assumes independence. Supply-chain failures, currency moves, and key-person departures tend to arrive together. Correlated risks require simulation or explicit scenario analysis, not summation.
Important outcomes are not monetary. Reputation, regulatory standing, safety, and team burnout do not monetize cleanly. Excluding them from the model does not make them irrelevant; it just moves the decision to a place where the model cannot see it.
| Method | Best for | Limitation |
|---|---|---|
| EMV | Comparing options, sizing base contingency | Hides variance and tail risk |
| Expected utility | Risk-averse decisions with large downside | Utility curves are subjective |
| Monte Carlo simulation | Correlated risks, confidence-level reserves | Requires distributions and tooling |
| Decision tree without EMV | Mapping options and sequencing | Needs quantification to rank branches |
| Qualitative risk matrix | Early screening, non-monetizable risks | No comparability across projects |
What mistakes should you avoid?
- Forgetting that probabilities must sum to 1.0. A register that lists only the “risk occurs” branch is calculating half an expectation.
- Mixing sign conventions. Threats negative, opportunities positive, consistently. A register with unsigned impacts produces nonsense totals.
- Treating EMV as a budget line. It is an expected value, not a spend authorization. Confusing the two leads to under-funded reserves.
- Double counting. If you already included rework in the base estimate, do not add a rework risk on top of it.
- Using EMV on scope changes. Contingency and management reserves exist for risk. Scope changes go through a change order, not through the reserve.
- Reporting precision you do not have. An EMV of “$23,847” derived from guessed probabilities is false precision. Round to a useful figure and state the assumption.
> Practical tip: Keep three fields next to every EMV in the register: probability source, impact basis, and last review date. Six months later, the number will have changed, and the note explains why.
How do you run EMV without a dedicated risk team?
You need a register with probability, impact, and owner per risk, plus the discipline to review it monthly. A spreadsheet works for a project with 15–30 risks; the failure mode is not the math but the maintenance, because registers rot when they live apart from the work they describe.
That separation is the usual problem. Risks sit in a document, mitigation tasks sit in a task board, and the reserve sits in a finance spreadsheet. When the monthly review arrives, nobody can tell whether the mitigation was actually done, so probabilities stay frozen at their original guesses.
Doitify keeps risks and constraints alongside the tasks and milestones they threaten, with owners, due dates, and work reports that show whether mitigation actually happened. That makes the EMV review a ten-minute check rather than an afternoon of reconstruction — and a register that gets reviewed is worth more than a sophisticated one that does not. We build the platform, so read that as a product note rather than an independent comparison.
FAQ
Conclusion
Expected monetary value is one multiplication and one addition, repeated until the uncertainty has a number. Its value is not precision — it is comparability. Two vendors, three design options, and a dozen risks can all be placed on the same scale, and the argument moves from opinion to arithmetic.
Use it as the first filter, not the final word. Report the range beside the average, adjust the reserve for the confidence level you actually need, and check whether the risks in your register are independent before you add them. Then look at the worst case with clear eyes, because that is the outcome you will have to survive — and EMV, for all its usefulness, will never tell you whether you can.
If this post on expected monetary value was helpful, you might also enjoy Team Weekly Report Template and Project Dashboard Examples: 10 Dashboards That Keep Projects on Track.
Join Doitify Today
Move projects forward without the chaos: all your tasks, progress, and team reports in one unified workspace. Built for companies, startups, and remote teams — with a quick setup and a free trial.