Near-certain problems: why the things you expect to go wrong need a budget and an owner — Business Finance and Financial Statements — Part 3 | ReadOS

Late in a project risk review, someone makes an observation that the room accepts immediately. The item under discussion, the one the production lead describes in the flat voice of someone who has seen it happen four times, is not really a risk. It is going to happen. “That’s not a risk, that’s a certainty. It doesn’t belong on the list.” The item comes off. The decision takes seconds, it is correct under the usual definitions, and nobody who agreed did anything wrong.

Follow what that decision moves. The item leaves the risk list, so it leaves the contingency calculation. It leaves response planning, so no fallback is designed and no owner is given a date. It stops consuming attention in the meeting where money is allocated and starts consuming money in the meeting where problems are reported after they happen. And all of this happens because the item was judged more likely, not less.

This article explains how the boundary between risks and issues can leave a business unprepared for exactly the problems it most expects, why contingency calculated from a risk list is systematically too small, and a simple way to record, price and fund near-certain problems so they are planned for rather than absorbed.

Risks, issues and the gap between them

Most project methods use two categories:

A risk is an uncertain future event that would affect objectives if it happened. Risks are scored by likelihood and impact, given responses and owners, and used to size contingency, the money and time set aside for things that might go wrong.
An issue is something that has happened, or is happening, and needs to be managed now.

The definitions are sound. The problem is the gap between them: a near-certainty, something the team confidently expects but which has not yet happened. It is too likely to be scored as a risk, so it is removed. But the issue process is built for events that have occurred, so it does nothing until the problem arrives. Nothing in between holds money in advance, schedules a preventive action or appears in any forecast.

The contingency cliff

Many likelihood scales stop below certainty. The top band may be “almost certain”, or the scale may simply instruct that anything above a threshold is treated as an issue. Contingency is often built by adding up likelihood multiplied by impact across the risk list. That creates a strange pattern: as an item becomes more likely, its contribution to contingency rises, until it crosses the threshold, at which point it drops to zero. The calculation has a cliff at the point of greatest expected cost.

Three misreadings

The risk list is the complete list of what might go wrong. It is the list of things judged uncertain enough to score. Unlikely items are deliberately filtered out by thresholds. Near-certain items are removed by definition, often with no record that they were ever considered.
An item leaving the list has been dealt with. A risk closed because its response worked and one removed because it became too likely both look like a reduction in open risks. The second kind improves the count faster.
Contingency covers the business’s exposure. It covers the risk list, and the list has had its most likely items removed. The calculation is correct on its inputs, but the inputs are missing their most expensive part. Contingency sized this way is too small, never too large.

Removal is the easy way out

Consider someone who owns a difficult risk, is asked each month for evidence that the response is working, and can see that it is not. There are two ways out: fix the problem, or argue that it is now so likely it no longer counts as a risk. The second is quicker, needs no engineering and is defensible under the usual definitions. It removes the item from the list, the need for a response plan and the monthly scrutiny. A process that offers this relief will get more of it.

Across several projects, near-certainties are often connected. A supplier who is consistently late, a seasonal labour shortage, a regulator with a known backlog, an ageing machine or a customer whose approvals always slip can produce the same expected problem on several jobs at once. Each project team removes its own instance from its own list on reasonable grounds, and nobody sees the total. The exposure that matters most across the business is the one most likely to be invisible.

A near-certainty log

Keep a short log beside the risk list, reviewed in the same meeting. It records every item removed from the risk list, or refused entry, because it was judged too likely. For each item, record:

What is expected, and which objective it threatens.
Who reclassified it, and when.
The likelihood, stated as a number rather than a band, such as 80% or 95%.
The full impact if it happens, in money and days.
The funding source now assumed to cover it: contingency, a specific allowance in the budget, the operating budget, or “unfunded”.
The owner and the date of the action that will prepare for or prevent it.
Whether it affects other projects.

“Unfunded” must be an allowed answer. A log that never records it is not being told the truth.

Two tests and one rule

The sum test. Add up the impact column and put it beside the contingency held. If the log’s total approaches or exceeds the contingency, the contingency is sized against the wrong list. Present both numbers together whenever contingency is discussed.
The direction test. Over two reporting periods, count items leaving the risk list because they became too likely, against items entering it. Steady one-way traffic out suggests reclassification is being used as relief.
The rule. No item leaves the risk list on likelihood grounds without a log entry and a named funding source. If the source is “unfunded”, the entry goes to the person accountable for the overall budget, because an unfunded near-certainty is a decision about money, not about the project.

Plan expected problems as work

A business can reasonably decide that anything above a certain likelihood should be planned as work rather than managed as risk. That is coherent, and often the best answer: a first production run that never meets specification on a new mould becomes a planned trial run with its own time and budget. A second round of certification testing that is usually needed becomes a planned second round. An approval that always slips becomes an approval requested earlier.

What is not coherent is removing near-certainties from the risk process without adding them to the plan. Either way, the expected problem must end up somewhere with a budget line and an owner.

Be wary of the opposite reflex: adding a permanent control or procedure for every expected problem. That may relieve the immediate exposure while creating a permanent cost that nobody later removes.

Use past jobs as evidence

The strongest evidence that something is near-certain is that it has happened on most similar jobs before. A short review of the last few comparable projects often reveals a pattern: the first production run always needs adjusting, a particular approval always takes longer than promised, a supplier always delivers part of the order late, commissioning always finds the same kind of fault. Write these patterns down. They turn a vague sense that “something always goes wrong” into specific, priced expectations that can be planned for. Keep the list current, and remove items when a permanent fix has genuinely changed the pattern, not merely when someone hopes it has.

Talking to customers about expected problems

Some near-certainties depend on customers, such as slow approvals, late information or changes after sign-off. It can feel awkward to raise these when quoting, but doing so is usually better than absorbing them silently. A clear statement of what the business needs from the customer, by when, and what happens to the timeline if it arrives late, sets expectations and protects both parties. Many customers respond well to a contractor who has evidently done this before and planned for it. Where the contract allows, link timeline adjustments to customer-caused delays explicitly, and take advice on the wording for significant contracts.

A worked example

This is an illustration. A small manufacturer is launching a new product that needs a new injection mould, product certification testing and new retail packaging. The project’s risk list includes a resin price rise (30% likely, $20,000 impact), absence of a key technician (20%, $15,000) and a breakdown of the moulding press (15%, $40,000). Contingency is calculated as the sum of likelihood times impact: $6,000 + $3,000 + $6,000 = $15,000.

In the review, three items were removed as “certainties”:

The first production run will not meet specification. It has happened on the last four new moulds. Impact: about $3,500 in scrap, about $4,000 of press time for a re-run and about $2,500 in mould adjustments, roughly $10,000 and a week.
Certification testing will need a second round. This happened on three of the last four products. Impact: about $6,000 and three weeks.
Packaging artwork approval by the retailer will slip. It always does, by one to two weeks. Impact: missing the retailer’s launch slot would cost about $8,000 in delayed sales.

The near-certainty log totals about $24,000, well above the $15,000 contingency, which had been sized as if none of these would happen.

The owner moves all three into the plan. A mould trial run is scheduled two weeks earlier, with its own budget. Two rounds of certification testing are booked and budgeted from the start. Artwork approval is requested three weeks earlier. The project budget rises by about $16,000 and three weeks on paper, but the launch date is now realistic, the contingency is left for genuinely uncertain risks, and the retailer’s slot is met.

How this applies to a small Australian business

Small businesses often handle expected problems informally: “it always happens, we’ll deal with it”. That works until several arrive at once or the business commits to a customer date that ignores them. Practical steps:

Ask your team what they are certain will go wrong on each significant job or project.
Keep a near-certainty log alongside any risk list.
Price each item in money and time.
Plan expected problems as work with their own budget and time, or fund them explicitly.
Look across jobs for expected problems with common causes, such as a consistently late supplier.
Compare the log total with your contingency before committing to prices or dates.
Use past jobs as evidence: what went wrong on the last three similar jobs?

The articles on pricing your risk controls and project management basics cover related practices.

Signals worth watching

A falling count of open risks without evidence that responses worked.
Issues that were never on any risk list.
The same expected problem recurring on successive jobs.
Contingency spent on events that were never scored.
Risk owners raising likelihood estimates just before a response is due.
Experienced staff predicting problems that never reach the budget.

Common mistakes

Removing near-certainties from the risk list without adding them to the plan.
Sizing contingency only from the remaining risks.
Treating “it always happens” as acceptable without pricing it.
Ignoring shared causes across projects.
Letting risk owners escape scrutiny by declaring items certain.
Adding permanent controls for every expected problem without considering their ongoing cost.

Frequently asked questions

Where should the line between risk and near-certainty sit? Many businesses use a threshold such as 80% or 90%. The exact figure matters less than what happens to items above it. They need a log entry, a plan and a budget.

Is planning for expected problems just padding the budget? No. Padding is unexplained extra money. Planning for expected problems is explicit: each allowance is linked to a named, evidenced expectation and an owner, and it can be removed if the evidence changes.

What if customers will not accept a longer timeline or higher price? Then the business has a choice to make openly: accept the exposure as unfunded, find a way to prevent the expected problem, or decline the work. Making that choice with the numbers in view is better than discovering it later.

How do we stop expected problems from recurring? Use the log across jobs. A problem that appears on every job is a candidate for a permanent fix, such as changing a supplier, a design standard or a process.

Questions to ask

How many items left our risk lists last quarter because they were judged too likely, and what is their total impact?
Which of last year’s issues started life as risks that were removed before they happened?
Which expected problems affect more than one job at once?
When we last set contingency, what did we leave out because it was too certain?
Who can remove an item from the risk list, and what must they record?
For the three biggest problems our team expects, which budget line pays for them?

Bringing it together

The boundary between risks and issues is necessary, but the usual arrangement sends the most likely problems from a funded, forward-looking process to an unfunded, reactive one. Keep a near-certainty log, price each item, test its total against contingency, and either plan expected problems as work or fund them explicitly. The things your team is already confident will go wrong are the easiest problems to prepare for. They should not be the ones your business is least prepared to pay for.

Source: KEVOS notes. Examples and figures in this article are illustrations.