Project Risk Management: Qualitative vs Quantitative

Key takeaways

A risk is something that might happen and would change the project if it did. A problem that is already happening is an issue, and it belongs on a different list.
Qualitative analysis ranks risks with words and a one-to-five scale for likelihood and impact. It is fast, cheap and good enough for most small and mid-size projects.
Quantitative analysis puts numbers on the risks: expected money, three-point estimates and simulations. It earns its keep on big, expensive projects with real data behind the guesses.
A ranking is only useful if every top risk gets an owner, a response (avoid, mitigate, transfer or accept), a trigger and a date to look at it again.
Risk is the early-warning half of control: it is how a business sees trouble at the right moment, with the right data, while there is still time to choose.

Every project has a moment when somebody leans back in their chair and says, "What could possibly go wrong?" and the entire room looks at them as if they had just taunted a bear. Experienced project managers know that silence is the wrong response. The right response is a list.

Risk management is the habit of asking that question on purpose, early, in daylight and with a pen, instead of at 4:45 on a Friday afternoon when the delivery truck is somewhere in Nevada and nobody knows why. It has a reputation for being heavy, full of acronyms and spreadsheets that only one person understands. It does not have to be. This guide is the plain-English version: what a risk is, how to rank risks with words (qualitative analysis), how to rank them with numbers (quantitative analysis), and how to know which of the two your project actually needs.

If you have read the risk register guide for small businesses, think of it as the notebook and this article as the method for filling it in. If you are building your plan, risk is one of the ten sections that matter in a project management plan. And if you run a business more than a single project, the idea underneath all of it is the one I keep returning to in Project Focus: control is what lets you make the right decision, at the right moment, with the right data.

What a risk is, and what it is not

A risk is an uncertain event or condition that, if it happens, changes your project for better or worse. The key word is "uncertain." It might happen, and it might not. An issue is a risk that has already happened, or a problem that was certain from the start. The key word there is "now."

The difference matters because the two lists need different treatment. A risk gets assessed, owned and watched. An issue gets fixed, today, by someone with the authority to fix it. When a team mixes them, the risk log fills up with fires and nobody does the quiet work of preventing the next ones.

Three more definitions will save you arguments later.

Threats and opportunities. Risk is not always bad. A supplier might deliver early, a permit might clear in half the time, a competitor might stumble. The PMBOK Guide treats both sides: threats you want to shrink and opportunities you want to grow. Most small teams track only threats, and that is fine, as long as you notice a gift when one arrives.
Cause, event, effect. A good risk is written as one sentence with three parts: "Because the landlord has not confirmed the key date (cause), the suite may not be available when the contractor arrives (event), which could push opening back by two weeks (effect)." Cause and effect keep you honest. "Delays" is not a risk. It is a mood.
Known unknowns and unknown unknowns. A risk register can only hold what you can imagine. For the rest, you keep a reserve: some time and some money that nobody has spent yet. We will get to it.

Step 1: find the risks

Risks live in people's heads, so the first job is to get them out. Do this as a team, in thirty minutes, with sticky notes and no judgment. Five prompts work well:

Walk the schedule. For each major piece of work, ask what has to be true for it to start on time and finish on time.
Look at the people. Who is critical, who is stretched and what happens if they are sick, leave or disagree?
Follow the money. Which costs are estimates, which are quotes and which are hopes?
Check the outside world. Suppliers, weather, regulators, the economy, the neighbors.
Remember last time. Open the lessons learned from the previous project. Last time's surprises are this time's risks, wearing a different hat.

Then ask the team the most useful sentence in risk management: "Imagine it is six months from now and the project failed. What happened?" Psychologists call it a pre-mortem, and it works because it gives people permission to say the unsayable. Nobody wants to be the pessimist in a planning meeting, but everybody has a good story about a disaster that happened to somebody else.

Qualitative analysis: rank the risks with words

You now have thirty sticky notes and a sinking feeling. Qualitative analysis is how you turn that pile into an order. It is called qualitative because it uses judgments (low, medium, high) instead of measurements (dollars, days).

Rate each risk on two questions, from one to five:

Likelihood: how likely is it to happen? One means "would surprise me," five means "I would bet lunch on it."
Impact: if it happens, how much does it hurt the project's schedule, cost, quality or reputation? One means "annoying," five means "we call the lawyer."

Multiply the two numbers. A risk with likelihood four and impact three scores twelve. A risk with likelihood two and impact five scores ten. The scores give you a ranking, and the ranking tells you where to spend your attention. Put the risks on a grid with likelihood on one side and impact on the other, and you have the picture most people know as a probability and impact matrix: the top right corner is where the trouble lives.

The first time you do this, one thing will go wrong. Everyone will rate everything differently, because "high" means a different thing to every person in the room. The fix is to write down what each number means for your project before anyone scores anything. For a small clinic or restaurant opening, an impact table might look like this:

Impact 1: less than a day of delay or less than $500.
Impact 2: up to three days or up to $2,000.
Impact 3: up to two weeks or up to $10,000.
Impact 4: up to a month or up to $30,000.
Impact 5: more than a month, more than $30,000, or a safety or legal problem.

Those figures are illustrative. Yours will be different, and the point is that they are written down. A scale tied to real days and dollars turns an argument about adjectives into a conversation about consequences.

Two bias warnings, because humans are human. Optimism bias makes your own plan look safer than anyone else's. Anchoring makes the first number said in the room the one everyone drifts toward. A simple remedy for both is to ask people to write their scores privately, then reveal them at the same time, and discuss only the risks where people disagree by two points or more. Those disagreements are where the information is.

Two dice mid-roll on a wooden desk beside a blank notebook, a pencil and a calculator — Quantitative analysis is, at heart, rolling the dice thousands of times on a spreadsheet instead of once on your career.

Quantitative analysis: rank the risks with numbers

Qualitative analysis tells you which risks matter most. Quantitative analysis tells you how much they might cost, in money and time. It is heavier, so use it on purpose. Three tools cover most needs.

Expected monetary value

The simplest quantitative tool is also the one you can do on the back of an envelope. Expected monetary value (EMV) is probability multiplied by impact in dollars. If there is a 30 percent chance that a permit review runs long and each week of delay costs you $4,000 in rent and carrying costs for three weeks, the impact is $12,000 and the EMV is $3,600.

Do that for each major risk and add the results. The total is not a prediction of what will happen, because no single risk costs its expected value; it either happens or it does not. The total is a size for your reserve: the amount of contingency that makes sense given everything you know. Here is an illustrative example for a small second-location opening.

A permit review that runs long: 30 percent chance, $12,000 impact, EMV $3,600.
An oven delivered two weeks late: 20 percent chance, $9,000 impact, EMV $1,800.
The lead baker leaves before opening: 10 percent chance, $15,000 impact, EMV $1,500.
A supplier raises prices: 40 percent chance, $4,000 impact, EMV $1,600.

The total is $8,500. A reserve of about that size, held by the sponsor and released only by a decision, is a defensible number. A reserve of "ten percent because ten percent sounds right" is a guess in a suit. For how contingency and the schedule fit together, see the project management plan guide and the critical path method.

Three-point estimates

When you estimate a task, one number hides the uncertainty. Ask for three: an optimistic estimate (everything goes right), a most likely estimate and a pessimistic one (a bad week, not the apocalypse). A common way to combine them, the PERT average, is (optimistic + 4 times most likely + pessimistic) divided by six. If painting takes three days at best, four days most likely and nine days at worst, the weighted estimate is (3 + 16 + 9) / 6, about 4.7 days. The gap between the best and worst numbers is itself a risk signal: a wide spread tells you which tasks deserve a closer look.

Simulation

The grown-up version is a Monte Carlo simulation. Instead of one schedule, a spreadsheet or tool rolls the dice thousands of times: every task gets a random duration within its optimistic-to-pessimistic range, the schedule is added up each time and you get a picture of the outcomes. Rather than "we will finish on March 14," you get "there is an 80 percent chance we finish by March 29." That sentence is much more useful to a sponsor, because it comes with its own odds.

Simulation is powerful and often oversold. It needs a decent model of the project and honest ranges for the inputs, and its output is exactly as good as those guesses. A simulation fed by wishful numbers is just wishful thinking with a nicer chart. Use it when the stakes and the data justify it: large budgets, many dependencies, a hard deadline and some history from similar jobs.

Qualitative or quantitative: which do you need?

A rough rule I use:

Small project, small team, low stakes: qualitative only. A one-page register, a one-to-five scale and a weekly look. That is enough, and it is more than most projects ever do.
Medium project with real money on the line: qualitative for everything, and EMV for the top five or six risks, to size a reserve you can defend.
Large project with a hard date, many parties and some history: qualitative first, then three-point estimates and a simulation for the schedule and cost, run by someone who has done it before.

Notice that the answer is never "quantitative instead of qualitative." Qualitative always comes first, because you cannot put numbers on a risk you have not found and ranked. Quantitative analysis is a magnifying glass for the top of the list. It is not a replacement for the list.

Two hikers at a mountain trailhead in the Wasatch, looking at the sky and a folded map before a climb — Nobody hikes a ridge without looking at the sky first. A risk review is the same glance, done on purpose.

Step 3: decide what to do about each risk

A ranked list does nothing until each top risk gets a response. The PMBOK Guide names several strategies for threats, and four of them cover most real life.

Avoid. Change the plan so the risk cannot happen. Pick a vendor with stock on the shelf instead of waiting for a custom order. Avoidance is the cleanest response and often costs a little scope or money.
Mitigate. Make the risk less likely or less costly. Submit the permit application early and ask for a pre-submission meeting. Cross-train a second person for the critical role.
Transfer. Move the consequence to someone better able to carry it, usually through insurance, a warranty or a fixed-price contract. Transfer does not make the risk disappear, and it often costs a premium, so read the fine print. The guide to contract risks shows where the fine print bites.
Accept. Do nothing in advance, on purpose. Active acceptance means you set aside a reserve or write down what you will do if it happens. Passive acceptance means you decided the risk is too small to bother with, and you noted that decision.

For opportunities, the mirror images are exploit, enhance and share, and the same acceptance rule applies. Most small teams will never need the vocabulary. The habit is what matters: for every risk near the top, pick one of these four verbs and write it next to the risk.

Then finish the row. A risk entry that works has these columns:

The risk, in cause, event and effect.
Likelihood, impact and score, with the date you rated them.
Response, the chosen strategy and the specific action.
Owner, one named person. A risk with no owner is a coincidence waiting to happen. If you need to assign owners clearly, a RACI chart takes thirty minutes.
Trigger, the early sign that the risk is about to happen: the supplier stops answering email, the permit office asks a third question, the lead baker's lunch breaks get suspiciously long.
Next review, a date.

The trigger column is the secret weapon. It turns a vague worry into something you can watch. A risk with a trigger is a smoke detector. A risk without one is a hope.

Making it a rhythm, not a document

The most common failure in risk management is a beautiful register that nobody opens after week two. The cure is to bolt it onto a meeting that already happens.

Every week, spend five minutes of the project meeting on the top five risks. Has anything changed? Has a trigger fired? Does a score need to move?
At each milestone, do a fresh pass: new risks, retired risks, a new look at the reserve.
On the one-page status report, show the top three risks and what you are doing about each. The status report guide shows where they fit on the page.
When something happens, record it, move it to the issue list and write down whether the response worked. That is tomorrow's lessons learned.

Your sponsor needs to see risk, too, and in the right dose: not a forty-row sheet, but the top few, with the decision you need from them. For how to keep that relationship healthy, see keeping your executive sponsor engaged.

If you run a business instead of a single project, this is where Project Focus and risk meet. A business with its leads, operations and sales connected to one scoreboard sees trouble early: the pipeline thins, a process stalls, a number moves the wrong way. Risk management is how you decide ahead of time what to do when it does. The details differ, but the logic is the same as in data-driven project management: the right data, at the right time, to make the right call.

The risk hall of fame

Real mistakes, in no particular order, from projects I have seen or heard about. Each one has a lesson for the price of a smile.

The register that lives in a drawer. Written once, praised once, never opened again. Fix: five minutes in the weekly meeting.
The list of forty risks. If everything is a priority, nothing is. Fix: work the top five to eight.
"Delays" as a risk. A mood is not a risk. Fix: cause, event, effect.
No owner. Everyone agreed it was important, so nobody did it. Fix: one name per risk.
The contingency that vanished. The reserve was quietly spent on scope changes. Fix: the sponsor holds it, and spending needs a decision on the log.
False precision. A simulation with a precise answer from invented inputs. Fix: show the ranges, and say where the numbers came from.
Risk as blame. A team punished for raising a risk stops raising them. Fix: thank the messenger, loudly.
Ignoring the good news. An opportunity noticed too late is just a story. Fix: ask "what could go right?" at least once.

Where this sits on the PMBOK map

In the process view of the PMBOK Guide, risk is planned, identified, analyzed (qualitatively and quantitatively), given responses, implemented and monitored. In the newer view, uncertainty is a performance domain that runs through the whole project. The tools above serve both. As always, the Guide is a map and not a rulebook, and a small project needs only the parts that change a decision. If you are following the series on a single project, risk planning gets its own part in PMBOK step by step, after the scope, schedule and cost baselines. You can start earlier with the first two parts: the business case and the charter and the stakeholder register.

The risk ranker

The ranker below uses the qualitative method from this article. The sample is a small second-location opening, with illustrative scores. Rate each risk's likelihood and impact from one to five, and the tool multiplies them and lists the risks from highest to lowest. Replace the sample risks with your own, keep the list to eight or so, and give the top three an owner, a response and a trigger before the end of the week.

What to do this week

Set a thirty-minute meeting with your team. Run a pre-mortem: "It is six months from now and this failed. What happened?" Put every answer on a sticky note. Agree what impact one to five mean in days and dollars for your project, then rate the notes privately and compare. Rank them with the ranker above, take the top five and write for each one a response, an owner, a trigger and a next review date. Put five minutes on the agenda of your next weekly meeting, and keep it there. If you want to go further, pick the top three and do the EMV arithmetic to size a reserve.

If you would like help building a rhythm that sees trouble early, that is part of how I work with owners and teams through Project Focus and my project management consulting services. You are also welcome to tell me about your project.

What is the risk everybody on your current project can see and nobody has written down? Tell me in the comments.

More tools. The risk register template and the decision log are free in the toolkit.

General information, not legal, insurance or financial advice. The examples and figures are illustrative. PMBOK and PMP are registered marks of the Project Management Institute, Inc. This site is independent and is not affiliated with, or endorsed by, PMI.

Frequently asked questions

What is the difference between qualitative and quantitative risk analysis?

Qualitative analysis ranks risks with judgments, usually a one-to-five score for likelihood and for impact, so you can see which risks matter most. Quantitative analysis puts numbers on them, such as expected money, three-point estimates and simulations, so you can size a reserve or put odds on a finish date. Qualitative always comes first, and quantitative is used on the top of the list when the stakes justify it.

How do I calculate the expected monetary value of a risk?

Multiply the probability of the risk by its impact in dollars. A 30 percent chance of a $12,000 loss has an expected monetary value of $3,600. The sum across your major risks is not a forecast of what will happen, but a sensible size for a contingency reserve.

What is the difference between a risk and an issue?

A risk is something that might happen and would change the project if it did. An issue is a problem that is already happening. Risks are assessed, owned and watched, and issues are fixed now by someone with the authority to do it. Keep them on separate lists.

How many risks should a risk register have?

As many as you can find, but only a handful can be worked at a time. Rank them and give the top five to eight an owner, a response, a trigger and a review date. A register of forty equal priorities is a list, not a plan.

Project Risk Management in Plain English: Qualitative vs. Quantitative, and Which One You Need

What a risk is, and what it is not

Step 1: find the risks

Qualitative analysis: rank the risks with words