Program risk is rarely spread evenly; it concentrates in a handful of dependencies, decisions, and relationships that carry most of the exposure. The Risk-Concentration and Readiness Check finds where the risk piles up and asks whether you are actually ready to carry it. Map the program's critical points, score each for how much would break if it failed and how prepared you are, and the map shows the two or three places that deserve real attention. It names the risks that matter before they materialize, so mitigation happens on your schedule rather than theirs.
Risk hides in a few load-bearing points
Long risk registers create a comforting illusion that risk is understood because it has been listed. In practice, risk in any real program is not evenly distributed. It concentrates. A single vendor sits under four workstreams. One unmade decision blocks three others. One relationship, if it sours, takes half the plan with it. These load-bearing points carry most of the program's true exposure, and a flat list of fifty risks scored one through five actively hides them, because it treats a peripheral risk and a structural one as equals.
The Risk-Concentration and Readiness Check is built to find those load-bearing points and test whether you are ready for them. It does two things a normal risk register does not. First, it looks for concentration: the dependencies, decisions, and relationships that multiple parts of the program lean on at once. Second, it pairs each with a readiness judgment, because a high-exposure point you are prepared to handle is a very different situation from a high-exposure point you have no answer for. The output is not a longer list. It is a short map of the two or three places where exposure is high and readiness is low, which is exactly where attention belongs.
Naming those risks before they materialize is the whole point. A risk that surfaces on its own timeline forces you to react under pressure. The same risk, named early through this check, lets you mitigate on your own schedule, when you still have options and time to use them. The difference is worth stating plainly. A risk you find on your own schedule is a problem you get to solve; a risk that finds you on its schedule is a crisis you have to survive. The check exists to convert as many of the second kind into the first kind as possible, while the cost of doing so is a conversation rather than a recovery. It is the same instinct behind a fire drill, which is that you rehearse the response while the building is calm precisely so that you are not inventing it in the smoke.
Scoring concentration against readiness
The check inventories the program's critical points and scores each on two axes: exposure, meaning how much of the program breaks if this point fails, and readiness, meaning how prepared you are to absorb or respond to that failure. The interesting cases are the high-exposure, low-readiness points; everything else is noise you can set aside. The table below shows the point types the check looks at and what a low-readiness signal looks like for each.
| Point type | How it concentrates risk | Low-readiness signal |
|---|---|---|
| Dependency | A vendor, system, or input that several workstreams share | No fallback, and no one owns the relationship. |
| Decision | An unmade call that blocks work downstream of it | No owner, no date, and no default if it slips. |
| Relationship | A person or party whose support the program assumes | Their posture is untested and no one is tending it. |
| Skill | A capability that lives in one or two heads | No backup, no documentation, and a single point of leave. |
| Assumption | A belief the plan treats as fact | Never validated, and expensive to unwind if wrong. |
Take a worked example. A team runs the check on a nine-month platform migration. The register had forty risks, but the check surfaces three load-bearing points. One vendor provides the identity service that four workstreams depend on, and there is no fallback and no named relationship owner: high exposure, low readiness. A go-live date decision sits unmade with the client, blocking three downstream teams, with no default if it slips: high exposure, low readiness. And a single engineer holds all the knowledge of the legacy data model, undocumented, with holiday booked in month four: high exposure, low readiness. Forty risks collapse into three that actually matter. The team assigns a relationship owner to the vendor and negotiates a fallback, forces the go-live decision to a date with a stated default, and pairs the engineer with a second person to document the model before the leave. The other thirty-seven risks are logged and left alone, because attention spent on them is attention stolen from the three that could sink the program.
Running the readiness check
- Inventory dependencies, decisions, relationships, skills, and assumptions separately. Concentration hides when these are mixed into one undifferentiated list.
- Score exposure by asking what breaks if this fails, not how likely it is to fail. Concentration is about blast radius; likelihood comes second.
- Score readiness honestly by naming the actual response you have. "We would figure it out" is a low-readiness answer, not a plan.
- Plot exposure against readiness and act only on the high-exposure, low-readiness quadrant. Spreading effort evenly across all points recreates the flat register you were trying to escape.
- Assign each surfaced point an owner and a mitigation date. A named risk with no owner is a risk you have described rather than reduced.
Where readiness checks go wrong
- Scoring likelihood instead of exposure. A low-probability failure under four workstreams still concentrates risk. Fix it by scoring blast radius first and probability second.
- Confusing a long register with coverage. Fifty flat risks hide the three that matter. Fix it by explicitly hunting for concentration rather than listing more items.
- Optimistic readiness scores. "We would handle it" masks the absence of a real plan. Fix it by requiring a named, specific response before scoring readiness as adequate.
- Ignoring relationships and assumptions. Teams score systems and decisions but skip the human and the unvalidated belief, which are often the biggest concentrations. Fix it by inventorying all five point types.
- Naming risks without owners or dates. An unowned mitigation never happens. Fix it by attaching a person and a deadline to every high-exposure, low-readiness point.
Before the program commits
- Dependencies, decisions, relationships, skills, and assumptions are inventoried separately.
- Exposure is scored by blast radius, not probability.
- Readiness scores rest on a named, specific response.
- Only high-exposure, low-readiness points carry mitigation effort.
- Every surfaced point has an owner and a mitigation date.