“It could go wrong” does not support a decision

A migration depends on credentials arriving the day before. Everyone is concerned, but the plan stays green. When access fails, the team calls it a surprise. The signal was already there; it needed to become a decision. Risk management begins when a concern becomes specific enough to guide action.

Use a simple sequence: because this condition exists, this event may occur, causing this impact. For example: “Because access has not been tested, the team may be unable to migrate during the agreed window.” Prevention, alternatives, and ownership can now be discussed.

Assign an owner and a trigger

“The team” is rarely a clear enough owner. Choose someone to track the risk and obtain decisions. Define an observable trigger: “If access testing is not complete by Tuesday, activate the alternative.” This avoids waiting until useful options have disappeared.

Separate prevention from contingency. Testing early reduces likelihood; reserving another window prepares for failure. Both may cost time or money. Choose based on impact and the risk tolerance of whoever is accountable for the service.

A risk that happened needs resolution

While the event is uncertain, manage the risk. Once it happens, manage the issue, response, and consequences. Do not hide an active incident in a list of possibilities. Record the actual state and link the response to owned, scheduled project tasks.

Review risks that no longer matter and those introduced by changes. A huge, stale list can hide what matters. Regularly discussing the few risks that could change a delivery decision is more useful than assigning precise numbers to concerns nobody tracks.

Write the three risks that would change the plan

For each, record cause, event, impact, owner, prevention, trigger, and response. Ask what first evidence would show the risk approaching. Schedule a review. If nobody can act on the record, rewrite it: the purpose is decision readiness, not filling a table.

Sources & further reading

Sources accessed October 24, 2026. Numerical examples and scenarios are illustrative.

Ready to put this knowledge into practice?

We can work together on your team’s challenge or your next project.

Talk to Calembe ↗