IT project risk management with aregister that actually gets used

Project risk management has a poor reputation in IT teams: a thirty-line spreadsheet filled in on kick-off day, shown once to the steering committee, then filed away. When a problem hits, it either was not on the list, or it was and nobody had looked at it since. You have probably lived through this.

I run short projects on my own: websites, integrations between tools, business applications. I have no PMO team to keep a register for me, so I kept what helps and dropped the rest. I have also built my own content machines around a simple idea of risk control: anything that can be checked is checked by the tool, and a check that did not run counts as a failure. Here is how I carry those habits over to the risk register of an IT project.

01Why IT project risks get underestimated

A study by Bent Flyvbjerg and his co-authors covering 5,392 IT projects shows that cost overruns do not follow a bell curve. Most stay modest, but a fat tail of projects overrun to an extreme degree, and decision makers badly underestimate how likely that is. The mechanism the authors put forward will sound familiar to anyone who has run an integration: technical components depend on each other, and a problem in one spreads to the others.

I have seen a small version of this on a project: centimetres in one tool and millimetres in another distorted an entire render. The fault was tiny at the source and visible everywhere downstream. The lesson I took from it is practical: the reference data has to be explicit, and dependencies between tools go into the register on day one.

02Identifying risks without an endless brainstorm

I do not start with "what are the risks?", a question so broad it produces generalities ("delays", "budget"). I reread the scoping document and look for four things.

1. Assumptions: every "we assume", "normally", "the supplier told us that". An unchecked assumption is a risk in disguise.
2. Dependencies: between tools, workstreams and suppliers. That is where the spreading described above begins. I draw them before writing them down, as in a web project plan built on its dependencies.
3. People nobody can replace: the one person who knows the old system, the approver who goes on holiday at the wrong moment.
4. Dates that cannot move: a trade show, a legal deadline, a campaign. I learnt to treat those separately in my early years in film and video production, where the shoot date is not up for negotiation.

HM Treasury's Orange Book adds two angles I forget too often: the limits of the information available, and the biases of the people identifying the risks. It also asks you to record risks whose source sits outside the project. A supplier changing its API is not in your hands, but its impact on your go-live date is.

An hour with the team and a technical contact is usually enough for a first list of ten to fifteen lines. Beyond that, I merge.

03Assessing likelihood and impact without false precision

The Orange Book sets the principle: a level of risk is defined with common criteria that combine likelihood and consequences. The temptation is then to build a five-by-five matrix with scores from 1 to 25. I gave up on that precision.

In his video on what goes into a risk register, Mike Clayton advises sticking to high, medium and low unless you really understand probability, and adding proximity: a risk that could happen tomorrow deserves more attention than one expected in a year. That is exactly what I do.

My grid in three questions

• Likelihood: does this happen on one project in three, one in ten, or almost never?
• Impact: does it push back the go-live date, cost a workstream's worth of effort, or get sorted within the day?
• Proximity: when will we know whether the risk is happening?

The final score has one job: sorting. I turn it into red, amber or green, like the verdict of my content machines. Red needs an action before the next review. Amber is justified in writing: we accept it, but we say why. Green just gets reread.

04A short risk register with one owner per line

A small register filled in consistently beats a large one kept badly: that is Mike Clayton's first piece of advice in the video above, and I learnt it the hard way. These are the columns I keep.

• An ID, never reused, even once the line is closed.
• The risk, written as "if [cause], then [consequence] on [objective]".
• Likelihood, impact and proximity: high, medium, low, and a date.
• The status, red, amber or green.
• The response: avoid, reduce, share or accept, with the specific action.
• The owner, a named person rather than a team.
• The warning sign, what will tell us the risk is getting closer.
• The next review date.

The response column follows the Orange Book's options: avoid the activity that creates the risk, reduce its likelihood or its consequences, share it through a contract, or accept it by informed decision. The same document asks that each response sets out the actions, the people responsible, the early warning indicators and the deadlines. The warning sign column is the one most often missing from the registers I review.

For owners, I follow the advice in the video: the project manager does not own every line. A workstream lead takes the significant risks, a specialist the narrower technical ones. Otherwise nobody else is looking.

05Keeping the register alive until go-live

A register lives through its review, not its creation. The Orange Book says it in its own way: the steps are presented one after another, but in practice they are iterative. My routine takes ten minutes a week.

1. Reread the red and amber lines, and only those in detail.
2. For each one, check whether the warning sign has gone off.
3. Add the risks that appeared during the week. Once a risk has been identified it goes into the register, even if it looks minor.
4. Close what can no longer happen, with the date and the reason.
5. Escalate to the steering committee whatever the team cannot decide alone, framed as a decision to make.

Two habits come straight from the way I build tools. First, a check that did not happen is a red, not a green: if nobody has tested the data migration, the "incomplete migration" risk is not under control, it is unknown. Second, I check the way an end user would. On one project, a site looked fine to the logged-in team and was still broken for visitors because of a cache. Since then, acceptance testing before go-live also happens in a private browser window.

Breaking the work down helps too. The Scrum Guide points out that an iterative approach is there to control risk and that short sprints limit the cost of a mistake to a shorter period. Delivering a first partial integration after two weeks reveals more risks than a month of meetings.

When a risk sits in a calculation, I would rather test it than debate it. At Moonworkers, an oracle written from the official texts replayed hundreds of contribution cases and found four one-penny errors caused by a rounding rule. No likelihood grid would have found them.

06What the register will not do for you

The register does not replace a decision. A line that has been red for three weeks with no action is telling you something about the project's governance, not about the risk itself.

It does not catch the extreme overruns described in Flyvbjerg's study very well: those often come from a chain of small dependencies that nobody had connected. The register helps you see them earlier if it records the dependencies; it does not make them predictable.

It also has a cost. On a three-week project with two people, a five-line list in the scoping document is enough. I would not build a thirty-column register for a brochure site. And I have missed obvious risks because the list existed and I trusted it too much: an integration specification that changed at every meeting was not recorded as a risk, when it clearly was one. Since then I version it, as I explain in the integration specification between an ERP and an online shop.

07Where to start this week

Take your scoping document and underline every assumption. Turn the five weakest into "if…, then…" lines, and give each a named owner, a warning sign and a review date. Block ten minutes a week in the team's calendar to go through them. That small register will tell you more than a large spreadsheet handed to the committee.

If you are starting an IT project and would like an outside view of its risks before you commit, I do this kind of scoping as part of my project direction work. We can talk about it.