Risk: reactive versus proactive, categories, and the risk table

The thinking move: uncertainty you have written down is cheaper than uncertainty you have not

Every project carries the same uncertainty whether or not anyone names it. The difference between the two strategies for dealing with it is when you pay, and what options you still have when you do. A reactive strategy does nothing until a risk becomes a problem, then fights the fire, and when fire-fighting fails, manages the crisis. A proactive strategy begins before technical work starts: identify potential risks, assess each one's probability and impact, rank them, plan to avoid the ones that can be avoided, and prepare a contingency for the ones that cannot. Both cost money. The proactive strategy costs less, earlier, at a time when options still exist; the reactive one costs more, at the worst possible moment, when almost every option has already expired. Every real project is partly reactive — nobody predicts everything — so the question is never whether to be proactive but how much of the uncertainty you convert into written, ranked, owned rows.

What a risk actually is

A software risk always has two characteristics, and an answer that gives one of them is only half right. The first is uncertainty: the risk may or may not happen. The second is loss: if it does happen, unwanted consequences follow. Both are needed, and the boundary case is the one that earns the mark — a risk with 100 per cent probability is not a risk, it is a constraint. "The team must use Kotlin because the client mandates it" is certain, so it belongs in the plan as a constraint, not in the risk table. It is also worth separating a risk from a problem: a problem is a risk that has already materialised, and the moment it does it leaves the risk table and enters the issue log.

Three categories, and two cross-cuts

Risks are categorised by what they threaten. Project risks threaten the plan — budget, schedule, staffing, resources, stakeholders, requirements; if one lands, the schedule slips and costs rise. Technical risks threaten the quality and timeliness of the software itself — design, implementation, interface, verification and maintenance problems, plus specification ambiguity, technical uncertainty and obsolescence; they occur because the problem turned out to be harder than you thought. Business risks threaten the viability of the product even if it is built perfectly — building something nobody wants (market), something that no longer fits the strategy (strategic), something the sales force cannot sell (sales), losing management support, or losing the budget.

Two cross-cuts run through all three. The first is knowability: known risks are found by a careful reading of the plan and the environment, predictable risks are extrapolated from past experience (staff turnover, a customer who changes their mind), and unpredictable risks are the ones nobody sees coming. The second is generic versus product-specific: generic risks threaten every project, while product-specific risks can only be found by someone who understands this technology, these people and this environment. Product-specific risks cause most of the damage, and the question that finds them is worth memorising: what special characteristics of this product may threaten our plan?

Identification and projection

Identification is systematic, not intuitive. The risk item checklist works through generic subcategories — product size, business impact, stakeholder characteristics, process definition, development environment, technology to be built, and staff size and experience — each of which is a prompt for the product-specific question above.

Projection then rates each risk on two independent axes. Probability is estimated by the team, typically by polling members individually and re-polling until the assessments converge, rather than by a single confident voice. Impact is assessed across four risk components — performance, cost, support and schedule — combined into one value on a four-point scale where 1 is catastrophic, 2 critical, 3 marginal and 4 negligible. Note the direction: a low number is a bad outcome.

The risk table, and risk exposure

The risk table is where projection becomes management. Every risk goes in, however remote, one per row, with five columns: the risk, its category, its probability, its impact, and a pointer into the RMMM plan. The table is then sorted by probability and by impact together, so that high-probability high-impact rows rise to the top, and a cutoff line is drawn somewhere down it. Everything above the line is actively managed; everything below is monitored and revisited. The cutoff is the entire economic point of the instrument: management attention is finite, so a low-probability catastrophic risk should not consume the attention that a high-probability critical one needs.

One further number sharpens the ranking. Risk exposure is RE = probability × cost, where cost is what the risk would actually cost if it materialised. It converts two incomparable axes into one currency figure, and the sum of the exposures across the table is a defensible contingency budget.

Worked example — the BorrowBox risk table

BorrowBox release 1 produced eleven candidate risks; five survived to the table. Sorted, the top three are: the locker vendor's SDK slipping six weeks (technical, 60 per cent, impact 1 — it lands squarely on the critical path); fewer than two hundred members joining in the first month (business, 55 per cent, impact 2); and only two of the four developers having shipped Kotlin before (project, 50 per cent, impact 2). The cutoff line goes under the third row. Below it sit the council delaying the second locker site (project, 30 per cent, impact 2) and the payment provider changing its API (technical, 25 per cent, impact 3) — real, monitored, not managed.

Risk exposure makes the top row concrete. A six-week slip costs about 4.8 person-months of stalled and re-sequenced work plus a launch pushed past the spring gardening season, which the team priced at 38,000 dollars. RE is therefore 0.6 × 38,000 = 22,800 dollars, which is more than the cost of building the locker simulator that would remove most of it — and that comparison, not the row's position in the table, is what actually authorises the mitigation.