Three months into a project we inherited, we found the risk register. It was a spreadsheet with 47 items, last updated two months prior. Twelve of those risks had already materialised into actual problems. Nobody had updated the register because the steering committee didn't meet until next month. The project was in serious trouble, and the governance framework designed to prevent exactly this was part of the reason it got there.
What You Need to Know
- Quarterly or monthly risk reviews are too slow for enterprise delivery. By the time a risk is formally raised, it's usually already a problem
- Risk should be surfaced weekly, in plain language, with the client in the room
- The goal isn't to eliminate risk. It's to make it visible and actionable before it becomes a crisis
- Risk management is a conversation, not a document
The Steering Committee Problem
Enterprise project governance typically works like this: a steering committee meets monthly or quarterly. The project manager prepares a status report, including a RAG-rated risk register. Risks are discussed. Actions are assigned. Everyone goes back to their day jobs.
This looks professional. It ticks the governance box. And it's almost completely useless for actually managing risk.
Here's why. In a four-month gap between steering committee meetings, a risk can go from amber to red to catastrophic. A key dependency slips. A technical assumption turns out to be wrong. A stakeholder who was supportive leaves the organisation. By the time these show up in the formal risk register, the damage is done.
43%
of project risks that materialise do so within two weeks of first being identified
Source: PMI Risk Management Survey, 2017
Two weeks. That's the window. If your risk review cycle is longer than two weeks, you're managing a historical record, not actual risk.
How We Do It at IDESIGN
We surface risk weekly. Not in a formal report. In a conversation.
The Weekly Risk Conversation
Every week, our project lead sits down with the client's project owner (or equivalent) for 30 minutes. Not a status update. A risk conversation. Three questions:
1. What are we worried about? This is open-ended on purpose. Not "what's in the risk register" but "what's keeping you up at night?" This surfaces risks that don't fit neatly into a register category. Political risks. Resourcing risks. Risks that someone is hesitant to put in writing.
2. What changed this week? New information arrives constantly. A vendor delays. A team member is sick. Budget approval is slower than expected. Requirements shift. Each of these is a potential risk, and they need to be assessed in real time, not accumulated for a monthly review.
3. What decisions do we need? Risk often sits unaddressed because nobody has the authority (or the appetite) to make a decision. The weekly conversation identifies these blockers and either resolves them on the spot or escalates them immediately.
Plain Language, Not RAG Ratings
We've stopped using RAG (Red/Amber/Green) ratings in our risk discussions. Not because they're wrong in principle, but because they create a false sense of precision. What does "amber" actually mean? It means something different to every person in the room.
Instead, we describe risks in plain language. "The integration with the HR system is taking longer than estimated because the API documentation was inaccurate. We've lost about a week. If we don't get the corrected documentation by Friday, we'll need to adjust the timeline or reduce scope for the next release."
That's specific. Actionable. And it doesn't require a colour-coded legend to interpret.
Shared Ownership
The most important word in our approach is "together." Risk management at IDESIGN isn't something we do and then report to the client. It's something we do with the client. They see the same risks we see. They're involved in the response. When things go sideways (and they always do), there are no surprises.
The worst thing a project team can do is protect the client from bad news. Deal with it together.
Isaac Rolfe
Managing Director
The Three Categories That Matter
Not all risks are created equal. We group them into three categories that drive different responses:
Delivery Risks
Timeline, scope, quality. These are the traditional project risks. Will we finish on time? Will the scope be met? Will the quality be acceptable? These are the easiest to track because they're measurable, but they're often symptoms of deeper risks rather than root causes.
Technical Risks
Assumptions that might be wrong. Integrations that might not work as expected. Performance that might not meet requirements. Architecture decisions that might not scale. Technical risks are best managed through early prototyping and proof-of-concept work, not through register entries.
Organisational Risks
The hardest to manage and the most common cause of project failure. The sponsor changes. The priority shifts. The team that was supposed to support the integration is pulled onto another project. Organisational risks can't be mitigated with technical solutions. They require relationships, influence, and early warning systems.
Making It Work
Weekly risk conversations only work if two conditions are met:
The client has to be willing to be honest. If the client's representative can't (or won't) share what's really happening inside the organisation, the conversation is theatre. We establish this expectation at the start of every engagement.
The project team has to be willing to be vulnerable. Admitting uncertainty, flagging something you're not sure about, saying "I don't know yet" - these are strengths, not weaknesses. But they require a relationship where honesty is rewarded, not punished.
28%
of project failures attributed to poor risk management
Source: Gartner, IT Project Management Survey 2018
That's more than one in four. And the fix isn't a better spreadsheet or a more detailed register. It's a habit. Talk about risk weekly. Talk about it honestly. Talk about it together. Do it before the steering committee has to hear about it.