The evidence is thinner than you'd expect
Ask a project manager why risk management matters, and the answer comes without hesitation: you see trouble coming before it hits. Ask for the evidence, and the answer comes a lot slower. De Bakker and colleagues showed in 2010 that the literature offers little hard evidence that risk management contributes to IT project success. That's not a reason to stop doing it, but it is a reason to look more closely at what actually works.
Other research is more positive, with caveats. Zwikael and Ahn found in 2011 that risk management moderates the relationship between risk level and project success — a correlational finding, not proof of causation. Rabechini and Carvalho found, in 415 Brazilian projects in 2013, a significant positive effect on perceived success: having a dedicated risk manager was linked to a 3.9 times higher likelihood of it. Important detail: that figure comes from self-reported success, measured in one country, in one study. It tells you something, not everything.
What actually happens
The most concrete explanation comes from the same research team, a year later. De Bakker and colleagues described in 2011 how risk management partly works through communicative action: the process synchronizes perceptions among stakeholders and makes responsibilities explicit. In other words — the value doesn't sit primarily in the list of risks it produces, but in the conversation the process forces. Who's responsible for what. What the client thinks the biggest risk is, and whether that matches what the team sees.
That also explains why risk registers nobody ever opens again deliver so little. The document itself controls nothing. The conversation needed to fill it in did the work.
What this means in practice
For practice, this shifts where the attention should go. A risk taxonomy like Hillson's Risk Breakdown Structure from 2002 is, at its core, a prompt list: a fixed set of categories that ensures coverage and stops you from skipping a source of risk. But that list only does its job when it's actually worked through with the right people — not when one person fills it in and files it away.
In practice, that means: plan the risk session as a conversation, not a form to fill in. Invite the people who assess the risk differently than you do. Record who's responsible for what, not just what the risk is.
The honest disclaimer
This is exactly why we don't claim RisicoRadar produces a "scientifically validated risk score." An AI analysis of your project documents can systematically map the main risk sources across five categories — scope, planning, budget, quality, stakeholders — surfacing blind spots you'd easily miss on your own. That's valuable: it's precisely the prompt-list function the RBS approach describes. But the tool doesn't replace the conversation. It starts it, or sharpens it.
If you pull a risk report out of a tool and just file it away, you're repeating the exact mistake De Bakker and colleagues' 2010 research makes visible: the document itself does nothing. So take the first step yourself: let RisicoRadar spot the blind spots in your project documents, and use that output as the agenda for the conversation you'd otherwise forget to have.
Sources
- de Bakker, K., Boonstra, A. & Wortmann, H. (2010), Does risk management contribute to IT project success? A meta-analysis of empirical evidence, International Journal of Project Management 28(5).
- Zwikael, O. & Ahn, M. (2011), The Effectiveness of Risk Management, Risk Analysis 31(1).
- Rabechini Junior, R. & Monteiro de Carvalho, M. (2013), Understanding the Impact of Project Risk Management on Project Performance, Journal of Technology Management & Innovation 8(3).
- de Bakker, K., Boonstra, A. & Wortmann, H. (2011), Risk Management Affecting IS/IT Project Success Through Communicative Action, Project Management Journal 42(3).
- Hillson, D. (2002), Use a Risk Breakdown Structure (RBS) to Understand Your Risks, PMI Global Congress.