Risk Management That Actually Works in Enterprise Programs

Almost every project has a risk register. Almost no project manages risk well. The register gets created at kickoff, added to reluctantly when something goes wrong, and largely ignored in between. Here's how to change that.

Risk registers fail because they're treated as documents, not conversations

A risk register that lives in a spreadsheet and gets reviewed once a month is a compliance exercise. Risk management that works is a weekly conversation where the team asks: "What's most likely to slow us down in the next two weeks, and what are we doing about it?"

The format matters less than the cadence and the honesty.

Keep the list short

I've seen risk registers with 80 items. Nobody meaningfully manages 80 risks. Pick the 10 that could actually derail the project and focus on those. Anything below a certain impact threshold can be noted and left alone unless it escalates.

Every risk needs an owner and a date

A risk without an owner is a worry, not a managed risk. Assign each significant risk to a specific person and agree on a date by which they'll either resolve it or escalate it. This single change has more impact than any risk framework I've used.

Distinguish between risks and issues

A risk is something that might happen. An issue is something that has happened. Tracking them separately matters because the response is different. Risks need mitigation plans. Issues need immediate action and escalation if they're blocking delivery.

The best risk management is relationship management

Most delivery risks aren't technical. They're people problems — a dependency team that's overloaded, a stakeholder who changes requirements late, a vendor who's slower than contracted. These risks surface early if you have good relationships and late (or never) if you don't.

Invest time in the relationships that surround your project. That's your best early warning system.