← All articles
ControlRisk management

A risk needs an owner and a trigger

A risk that nobody owns is only a worry. I keep a living RAID log so that every worry becomes an item with a name, a sign to watch and a next step.

Ionut Ilasi3 min read

A risk that nobody owns is only a worry. I keep a RAID log for every project (risks, assumptions, issues and dependencies) because it turns a vague worry into an item with a name, a trigger and a next step.

A living log, not a document

Each entry has an owner, a likelihood and an impact in plain words, and a trigger: the sign that tells us the risk is about to become real. The trigger is the part people skip. Without it, a risk is looked at again only when it has already become an issue.

I keep the wording simple. Likelihood and impact are high, medium or low, with one sentence on what the risk would mean for the project. A scoring matrix adds precision that nobody believes, and a short sentence is read by everyone, including the client.

The log is reviewed every week in the PM sync. Items are closed, escalated or reworded. A log that is updated only before a steering meeting is a record of the past, and it is of no use to the people who need to act now.

Assumptions and dependencies from day one

Every assumption we plan on goes into the same log, with an owner and a validation date. An assumption is a risk we have chosen to accept for now, and it should be visible. The cost of being wrong decides which ones we confirm first.

External dependencies are the risks I look for first, because they sit outside the team's control. Typical examples are a client environment that is not ready on time, or client inputs that arrive late. I put each one in the log in the first week, with a date and a named person on the other side, and I ask for confirmation well before the date, not on it.

Flag it before acting on it

When I see a risk, I raise it before I act on it. Even when I think I can fix it quietly, the people affected should hear about it from me early. This is the no-surprises principle in practice: a risk that has been shared can be helped, and a risk that has been hidden can only be explained.

Bring a response to steering

Every major risk goes to the steering committee with a proposed response, not only a description. Steering is where decisions are made, so I arrive with options, a recommendation and the cost of each. The committee decides, instead of learning about a problem and asking me what to do.

No risk should reach steering without a proposed response.

A risk the committee decides to accept stays in the log, with the name of who accepted it and the date. That keeps the decision visible and makes it easy to reopen if the trigger fires.

None of this removes risk. It makes sure the project meets each risk with time, with an owner and with a plan. The goal is not an empty log. It is a log in which nothing is a surprise. A project with no risks written down is not a project without risks, only one where nobody is looking.

Previous articleA red status is information, not a failure Next articleTrust is built in the ordinary weeks

Working on something complex?

If this is how you want your next programme to be run, let's talk.