Risk Management in IT Projects: Registers That Get Read

In this article:

Share the раgе:

Every IT project has a risk register. Almost none are read after week three, because the rows describe conditions ("integration may be delayed") rather than decisions someone has to make by a date. A register that gets read has six things on every row: a cause-and-effect statement, a trigger you can observe, an owner, the cost of doing nothing for a week, a decision date, and the options on the table when that date arrives. It is reviewed in the same meeting as the schedule, not in a separate ritual. PMI's 2026 Pulse of the Profession found that 31% of complex projects fail to achieve the full scope of their intended benefits, more than twice the 12% rate for projects overall. This guide covers the six columns, the three categories of risk IT projects under-record, how the register changes across delivery methodologies, and a review rhythm that keeps it alive.

Introduction

I have opened a lot of risk registers in month five of a project. The pattern is consistent. Forty rows, written in the first two weeks, scored red-amber-green, last updated the week the PMO asked for it. Half the rows have already happened. The other half describe things that were never going to happen, and the risk that is currently sinking the project is not on the list.

Nobody was lazy. The register was built to satisfy a template, and the template asks for conditions and scores. It does not ask what anyone is supposed to do.

What is risk management in IT projects, and why do registers stop being read?

Risk management in IT projects is the practice of identifying what could prevent the project from delivering its intended benefits, deciding in advance what will be done about each one, and acting on those decisions before the risk becomes an issue. The register is where those decisions are recorded.

Registers stop being read for one reason: nothing in them requires anyone to do anything. A row that says "vendor may deliver late, likelihood medium, impact high, mitigation: monitor" is a description. It has no trigger, no date, and no decision. It can sit at amber for six months and be technically correct the whole time.

The scale of the problem is not small. PMI's 2026 Pulse of the Profession, drawing on 2,023 project professionals and 511 senior leaders across 35 countries, found that 31% of complex projects fail to achieve the full scope of their originally intended benefits, more than twice the 12% rate reported for projects overall in PMI's 2024 research.<sup>[1]</sup> The report attributes much of the gap to organizational rather than technical factors, and unowned decisions are the most organizational failure there is.

Most IT projects are complex projects by that report's definition. They have multiple systems, multiple stakeholder groups, and dependencies nobody fully mapped. The register is the document that is supposed to hold the plan for when those dependencies fail.

Key Takeaway: A risk register is a list of decisions with dates, or it is a list of worries with colours. Only the first kind changes anything.

Running a programme where the register was last updated at kickoff? Our Planning practice rebuilds it around decisions and dates. Book a free consultation.

What belongs on every row of the register?

Six columns. The first two are what most templates already have. The other four are what makes the row actionable.

Column	What it forces you to state	Worked example
Cause and effect	Because of X, Y may happen, which would cost Z	Because the payments API is still in vendor beta, the integration may slip, delaying cutover past the quarter-end freeze
Trigger	An observable event that means the risk is materializing	Vendor has not published the production endpoint by 30 September
Owner	One named person with authority to act, not a team	Head of Integration
Cost of a week's inaction	What the project loses for each week the decision waits	Each week past the trigger date pushes cutover one month, to the next freeze window
Decision date	The last date a choice can be made without the cost above	7 October
Options on the date	The two or three things the owner can choose between	Proceed on beta with a fallback, defer cutover, or switch to file-based batch for release one

The cost column is the one that gets the register opened. Executives do not read risk registers. They do read a line that says a specific decision, left for one more week, moves cutover by a month.

The decision date is the column that stops rows sitting at amber forever. A risk with a decision date is a milestone. It goes on the same calendar as the build tasks, it turns red when it passes, and someone has to explain why.

Most registers arrive with likelihood and impact scores and none of the other four columns, because the template came from a methodology handbook and the handbook was written for scoring, not deciding. ID Business Analysis Canada rebuilds the register as a deliverable of every Requirements Engagement on a delivery program, with a business analyst rewriting each row into the six-column form, tracing the trigger to something observable in the project's own systems or vendor commitments, and putting every decision date onto the delivery calendar next to the milestones it protects.

Key Takeaway: Six columns. If a row cannot state what the owner decides, by when, at what cost of waiting, it is a worry with a colour, and it should come off the register.

Which risks do IT projects under-record?

Three categories, and each is under-recorded for the same reason: the person who can see it is not the person writing the register.

Three categories of risk IT project registers under-record: stakeholder, data, and dependency, with who can see each and when it surfaces.

Stakeholder risk. A named person who can withhold a decision or a sign-off, under a condition you can state. Most registers have one row that says "stakeholder engagement" and nothing about who, what, or when. The stakeholder register described in our earlier post is this category of risk written properly: each row is a person, a trigger, and a cost.
Data risk. The migration, the reconciliation, the field being used for a second purpose since a merger. Discovered at trial load, which is usually month seven. The people who know are the operations staff who work around the data every day, and nobody asked them in week two.
Dependency risk. The vendor API in beta, the other project's release that yours needs, the environment that will not be ready. Known to the technical leads, recorded as "external dependency, medium," and never given a trigger date.

Technical delivery risk, the category most registers are full of, is usually the best managed, because the developers see it and raise it. The three above are the ones that sink projects, and they are the ones a template-driven register misses.

Key Takeaway: Stakeholder, data, and dependency. Go and ask the people who can see them, and put a trigger date on each one.

How does risk management differ across IT project management methodologies?

The register changes shape, and the six columns do not.

Predictive and waterfall. The register is a standing document, reviewed at phase gates and in the weekly delivery meeting. The decision date column matters most here, because phases are long and a risk can sit unreviewed for months if nothing forces it onto the calendar.
Agile. Risks live in the backlog as spikes, explicit risk items, or acceptance criteria on stories, and the sprint boundary is the natural decision date. The trap is that a backlog item can be deprioritized indefinitely without anyone noticing that a risk decision has been deferred. Keeping a short separate register with the six columns, reviewed at sprint review, prevents that.
Hybrid. Most IT programmes are hybrid whether they admit it or not: agile build inside a predictive governance frame. The register belongs at the programme level with the six columns, and the delivery teams feed it from sprint reviews. The failure mode is two registers, one for the PMO and one for the teams, that never agree.

Whichever methodology is in use, the review has to happen in the same meeting as the schedule. A risk review held separately from the schedule review is the ritual that produces month-five registers nobody has opened.

Key Takeaway: The methodology decides where the register lives and how often it is reviewed. The six columns are the same in all of them.

How do you keep the register alive after week three?

Three practices, all of which cost less than the review meeting most projects already hold.

Weekly review rhythm for an IT project risk register, with three practices that keep it short and current.

Review it in the schedule meeting. Not in a separate risk meeting. The register is a list of dated decisions, and dated decisions belong beside the milestones they protect. Walk the decision dates in the next four weeks, ask each owner whether the trigger has been seen, and move on.
Report the oldest waiting decision, not the RAG count. "Twelve amber, three red" is not information. "The payments API decision is nine days past its date and the cost is one month of cutover" is. Put it at the top of the status report.
Retire rows. A risk that has materialized is an issue and moves to the issue log. A risk whose decision date has passed without the trigger appearing is closed. A register that only grows is a register nobody trusts, because everyone knows most of it is stale.

The register should get shorter as the project progresses, because decisions are being made. A register that is longer in month six than in month one is recording worries faster than it is resolving them.

Key Takeaway: Same meeting as the schedule, oldest waiting decision at the top of the report, rows retired as decisions are made.

Frequently Asked Questions

What is the difference between a risk and an issue in IT project management?A risk is something that may happen and has not yet; an issue is something that has happened and needs handling now. The transition between them is the trigger. When the trigger is observed, the risk row closes and an issue opens with the decision the owner already chose from the options column. Registers that mix the two become unreadable, because half the rows need a decision and half need action, and nothing distinguishes them.

How do we start rebuilding a risk register on a project that is already running?Take the current register and, for each row, ask whether it names a trigger, an owner, a cost of waiting, a decision date, and options. Rows that cannot be rewritten in that form come off. Then go to the three under-recorded categories, stakeholder, data, and dependency, and ask the people who can see them what they are worried about. ID Business Analysis Canada does this as a two-week rebuild inside a live program, with a business analyst producing the six-column register, the decision dates on the delivery calendar, and the first status report with the oldest waiting decision at the top. The rebuilt register is usually a third the length of the original.

How often should an IT project risk register be reviewed?As often as the schedule is reviewed, and in the same meeting, which on most programmes means weekly. The review itself is short if the register is in the six-column form: walk the decision dates falling in the next four weeks, confirm with each owner whether the trigger has appeared, and record the decision if the date has arrived. A monthly standalone risk review is the cadence that lets a decision date slip by three weeks before anyone sees it.

Is stakeholder management risk part of the project risk register?It should be, and it usually is not. Most registers hold technical and schedule risks in detail and stakeholder risk as one line. Each stakeholder who can withhold a decision is a risk row in its own right: a named person, the condition under which they withhold, the cost if they do, and the date by which their decision is needed. Moving those rows into the main register, with the same owner and review rhythm as everything else, is the single change that most improves how stakeholder risk gets handled.

Conclusion

The template asked for likelihood and impact, so that is what the register has. What the project needed was a list of decisions, each with a date and a cost of waiting, reviewed in the meeting where the schedule already is.

If your register was last opened when the PMO asked for it, ID Business Analysis Canada's Planning practice rebuilds it in the six-column form, puts the decision dates on the delivery calendar, and hands back a document a third the length that the steering committee will read. Book a free consultation and bring the current version.

Get in touch

Registers That Get Read: Risk Management in IT Projects