Is This a Risk or an Issue?

Here is how the argument usually goes. The delivery lead says the utility conflict is an issue because it exists, it has been surveyed, and somebody has to pay to move the line. The risk lead says it is a risk because the extent has not been determined and the cost could be anywhere in a wide range. Both are describing the same object correctly and reaching different conclusions, because they are answering different questions.

The uncertainty about whether resolved when the survey came back. The uncertainty about how much has not. Those two uncertainties live in different places on a program and the whole taxonomy follows from keeping them apart.

What is the actual definition?

ISO 31000 defines risk as the effect of uncertainty on objectives, and that phrasing is more precise than it looks. Uncertainty is the constitutive element. Remove it and you do not have a smaller risk, you have something that is not a risk at all.

So an issue is not a big risk and a risk is not a small issue. An issue is a condition that exists. It is managed by resolution rather than by treatment, funded from budget or change rather than from contingency, and owned by whoever can fix it rather than by whoever can influence its likelihood.

The distinction has a much older lineage than the project management literature. Knight separated measurable risk, where the distribution of outcomes is known well enough to price, from unmeasurable uncertainty, where it is not. That line does different work than the risk-versus-issue line but it establishes the same underlying discipline: be specific about which kind of not-knowing you are dealing with, because the response differs.

The four categories and who pays for each

Risk

May or may not occur. Owned by whoever can influence the probability. Funded from contingency, which exists precisely because these outcomes may not happen and the organization does not want to fund each of them at full value. Enters the quantitative model with a probability and a consequence range.

Issue

Has occurred or exists now. Owned by whoever must resolve it. Funded from budget, change order or reserve draw, because there is nothing probabilistic left about whether the money is needed. Does not enter the risk model as a probabilistic event. Its residual uncertainty about magnitude belongs in the base estimate as a range on that cost.

That last point is the one most often lost. Moving an item from the risk register to the issue log is not the same as removing its uncertainty. The uncertainty changes category: it stops being uncertainty about occurrence and becomes uncertainty about extent, and extent uncertainty is estimate uncertainty. Programs that forget this end up with an issue recorded at a single point value and a forecast that has quietly become less honest than it was when the item was a risk.

Assumption

This is the dangerous one and it is worth being blunt about why.

An assumption is a risk whose uncertainty has been removed by declaration rather than by evidence. Writing that the permit will be issued by March, or that the existing structure will be found adequate, or that the third party will deliver on the date they gave, converts an uncertain event into a planning fact.

An assumption is a risk with the uncertainty removed by decree. It carries no probability, no contingency, no owner watching it, and no presence in the model.

The compounding problem is structural. Quantitative models take their input from the risk register. Assumptions are not in the risk register, they are in the basis of estimate, and nobody feeds the basis of estimate into the simulation. The result is a program whose largest exposures can be entirely invisible to its own risk analysis, which is why a well-run model can still miss the thing that lands.

The correction is mechanical: every material assumption gets a line in the register describing the risk that it is wrong. The permit assumption becomes a risk that the permit is delayed beyond March, with a probability and a consequence. It is the same fact, entered in the place where it will be modelled and monitored.

Dependency

Something outside the program that the program requires. Owned elsewhere. Cannot usually be managed, only escalated and monitored, which makes the response set genuinely different from a risk you control.

Dependencies deserve their own category because treating them as risks produces mitigation plans nobody can execute. The realistic responses are earlier warning, a fallback that does not require the dependency, or acceptance with contingency. Writing a mitigation strategy for another organization's decision is a way of appearing to manage something you cannot touch.

What misclassification does to the numbers

This is the part with a dollar figure attached, and it moves in both directions.

Take a risk that carried a forty percent probability and an impact range around two million dollars. It occurs. Now consider two ways the books can be kept.

In the first, the two million is added to the forecast as a cost, and the entry also stays in the risk register at forty percent because nobody closed it. The simulation now adds roughly eight hundred thousand dollars of probability-weighted exposure on top of a cost that is already counted. The contingency requirement is overstated and the organization holds money it does not need, which has a real opportunity cost.

In the second, the entry stays in the register at forty percent and the cost is not added to the base, on the reasoning that the risk register already covers it. The model now includes forty percent of a cost that is certain. The forecast is understated by roughly 1.2 million dollars and nothing in the output indicates it.

Both errors are ordinary, both survive review, and both are caught by the same one-line rule: every cost is either uncertain and in the model, or certain and in the base. Never neither. Never both.

Three questions that settle it

Ask them in order and the classification falls out.

• Has it happened? If yes, it is an issue, whatever remains unknown about its size. Move the remaining uncertainty into the estimate as a range.
• Is the uncertainty about whether, or about how much? Whether means risk. How much means an estimating range. Programs conflate these constantly and it is the single most common source of a corrupted model.
• Can we still change the probability, or only the consequence? If only the consequence, check whether this is really a dependency, because the response set for something you cannot influence is different in kind.

And one more, asked separately: what have we written down as a fact that is not yet a fact? That question turns up assumptions, and the answers are usually already known to everyone. They have simply never been given a probability, which means they have never been in a number.

Evidence matrix

What to do with this

Run one reconciliation. List every entry in the risk register that has occurred and check, for each, whether its cost is in the current forecast. Then list every entry in the forecast that came from a realized risk and check whether the register entry was closed. The two lists should be identical and they will not be.

Then open the basis of estimate and pull out every sentence containing the words assumes, assuming or it is expected that. Each one is a risk that has been written down in the wrong document. Most programs find between five and fifteen, and two or three of them are material.