The RISMAN method: risk analysis your whole project team understands

Ask a project manager in Dutch construction, infrastructure, or at a water authority about risk analysis, and chances are the RISMAN method will come up. For nearly thirty years it has been the go-to standard for mapping project risks in a structured way. But what exactly does the method involve? And how do you make sure a RISMAN analysis becomes more than a spreadsheet that never gets opened again after the kickoff?

In this post we explain how the RISMAN method works, which steps you go through, and how to keep the method alive in practice.

What is the RISMAN method?

The RISMAN method is a Dutch approach to risk analysis and risk management in projects. The core idea: together with your team, you systematically map which risks threaten the project outcome, you determine which of those matter most, and you tie mitigation measures to them. You do this not once, but cyclically throughout the entire project.

What sets the method apart from a simple risk list is its structured way of identifying risks. You look at the project from multiple perspectives, so you find not only the obvious technical risks, but also the political, legal, and organizational surprises that most often derail projects in practice.

The origin: born from major infrastructure projects

The method was developed in the mid-1990s through a collaboration involving Rijkswaterstaat, ProRail (then NS Railinfrabeheer), Gemeentewerken Rotterdam, Delft University of Technology, and Twynstra Gudde, among others. The reason was familiar: large infrastructure projects were consistently running over on time and budget, and there was a need for a shared, practical approach to controlling risks both up front and during execution.

That heritage explains why the RISMAN method is still so widely used today by contractors, engineering firms, municipalities, and water authorities. The method was built for projects with many stakeholders, long timelines, and a public context. Exactly the environment in which many Dutch project organizations operate.

The RISMAN analysis in four steps

At its core, a RISMAN analysis runs through four steps.

Step 1: Define the goal of the analysis

Sounds obvious, yet it is often skipped. What is the analysis about? The whole project or a single phase? Is it about time, cost, quality, or safety? Without a sharp goal, you end up with a grab bag of risks that no one can prioritize.

Step 2: Identify risks from seven perspectives

This is the heart of the method. Instead of brainstorming freely ("name a few risks"), you deliberately look at the project from different angles:

• Political and administrative: support, decision-making, elections, changing officials
• Financial and economic: budget overruns, price increases, indexation, financing risks
• Legal and regulatory: permits, contracts, procurement rules, claims
• Technical: design, execution, soil conditions, interfaces between disciplines
• Organizational: capacity, knowledge, collaboration, turnover of key people
• Geographic and spatial: surroundings, cables and pipelines, nature reserves, accessibility
• Social: local residents, media, public opinion, stakeholder resistance

By explicitly walking through each perspective, you avoid blind spots. A technically oriented team finds technical risks effortlessly, but without this structure it quickly misses the administrative risk that ends up halting the project for six months.

Step 3: Determine the most important risks

Not every risk deserves equal attention. For each risk you assess the likelihood of occurrence and the impact on your project goals, and you prioritize based on that. Do this together where possible: when the whole team votes on likelihood and consequence, you get not only a better estimate but also the conversation about why estimates differ. That conversation is exactly where the most insight comes from.

Step 4: Map out control measures

For the most important risks, you define measures. The RISMAN method distinguishes between preventive measures (which address the cause and reduce likelihood) and mitigating or corrective measures (which limit the consequences if the risk occurs anyway). Every measure gets an owner and a deadline. A measure without an owner is not a measure, it is a good intention.

From RISMAN analysis to RISMAN cycle

This is where things often go wrong in practice. Many organizations run the analysis once, put the result in a report, and move on. But the creators of the method were clear: the analysis is step one of an ongoing cycle.

The RISMAN cycle looks like this:

1. Carry out the risk analysis (or update it)
2. Choose the control measures
3. Implement the measures
4. Evaluate: have the measures been carried out and have they had an effect?
5. Update the analysis: which risks have disappeared, changed, or emerged?

And then you start again. On large projects you run through this cycle each quarter, for example, or at every phase transition. That way the risk register grows along with reality, instead of remaining a snapshot of how the project once looked.

The pitfalls of the RISMAN method in practice

The method itself is strong, but execution determines the outcome. Three pitfalls we often see:

1. The analysis stays with one person. If the risk manager works through the seven perspectives alone, you miss the knowledge of the people doing the work, the environmental managers, and the contract specialists. The broader and more varied the group, the better your risk analysis becomes.

2. The register lives in a spreadsheet. Versions get scattered, measure deadlines go unmonitored, and no one knows which list is current. The cycle stalls, and with it the whole method.

3. The number beats the conversation. Likelihood times consequence produces a score, and that score becomes sacred. Yet risk management is precisely about the substantive dialogue behind that number: why does one person rate this risk high and another low? That is where the real value sits.

Applying the RISMAN method with modern tooling

The RISMAN method only truly comes into its own when you involve the whole team and keep the cycle running. Software like RiskChallenger is built for exactly that. Team members join risk sessions via a QR code without needing an account, the team votes together on likelihood and impact, and automated reminders keep track of control measure deadlines. That way the RISMAN cycle becomes not an administrative obligation, but a recurring conversation the team actually benefits from.

Organizations such as Heijmans, Delfland Water Authority, and Aveco de Bondt work on their project risks this way every day. Or as one user put it: "It makes risk management a little more fun, and it starts to spark the imagination more."

Frequently asked questions about the RISMAN method

Which projects is the RISMAN method suitable for?It was originally developed for large infrastructure projects, but the method works for any project with multiple stakeholders and serious uncertainties: from area development to dike reinforcement, and from IT implementation to events.

What is the difference between the RISMAN method and ISO 31000?ISO 31000 is an international guideline with principles for risk management at the organizational level. RISMAN is a concrete, practical way of working for risk analysis in projects. They are not mutually exclusive: you can use RISMAN as the project-level implementation within an ISO 31000 framework.

How often should you run through the RISMAN cycle?That depends on the dynamics of your project. A common rhythm is quarterly, supplemented by an update at every phase transition or major change.

Ready to get started with risk analysis in your project?

The RISMAN method gives you the structure, but the difference is made by the people around the table and the discipline to keep the cycle going. Want to see how to make your risk sessions more interactive and monitor your measures automatically? Start a free 30-day trial or schedule a personal demo.