A Risk Identified Is Not a Risk Managed

Every experienced project manager has seen a project where a significant risk materialised despite being documented months earlier. In many cases, the problem was not that the risk had been overlooked. It was that identifying it had quietly become a substitute for managing it. 

For many project teams, good risk management is often equated with having a comprehensive risk register. 

Neatly formatted. 

Probability. 

Impact. 

Mitigation. 

Owner. 

Review date. 

Everything exactly as the methodology prescribes. 

A well-maintained risk register is undoubtedly valuable. It provides visibility, creates accountability, documents organisational knowledge and demonstrates that uncertainty has been considered. But one important lesson emerges repeatedly across complex projects: 

A risk register is an essential part of risk management. But by itself, it rarely changes the project's exposure. That requires deliberate action. 

That distinction matters. 

On one large engineering project, the initial risk workshop was considered a success. By lunchtime, the team had identified nearly ninety risks. By the end of the exercise, the register contained hundreds of entries. 

The customer was reassured that the project had considered the major uncertainties. Senior management praised the thoroughness of the process. Everyone left the workshop feeling the project was well prepared. 

Three months later, a key supplier announced that a critical component would be delayed by eight weeks. 

The consequences spread quickly. 

Procurement slipped. 

Manufacturing schedules moved. 

Testing was delayed. 

Eventually, the customer delivery date had to be postponed by several months. 

During the post-project review, someone asked a simple question: 

"Was this risk already in the register?"

It was. 

The supplier delay had been identified months earlier. 

Its impact had been assessed as high. 

Its status remained open. 

The planned mitigation was: 

"Maintain communication with supplier." 

Nothing in the register was incorrect. 

The problem was something else. 

Without realising it, the team had begun to equate documenting the risk with managing it. 

The risk was documented. It was not under control. 

Maintaining communication was certainly valuable. It helped the team understand what was happening and provided early visibility of emerging problems. In that sense, it was an important monitoring activity and may even have reduced the likelihood of minor disruptions. 

But communication alone did not reduce the project's exposure. There was still no qualified alternative supplier. No additional schedule contingency. No predefined escalation trigger. No agreed contingency plan if the delay became unavoidable. 

The project had identified the risk. 

It had not changed the situation. 

That difference is where many teams struggle. 

Of course, not every significant risk can be eliminated. Sometimes technical, commercial or contractual constraints leave few realistic treatment options. In those situations, consciously accepting the remaining uncertainty may be entirely appropriate. The important distinction is that acceptance should be an informed decision, not an accidental consequence of assuming the issue is already under control. 

A good response changes what happens next. It may reduce the probability of an event occurring, lessen its impact if it does occur, improve the team's ability to detect early warning signs, transfer the risk to another party, or consciously accept the remaining risk after evaluating the available options. 

Simply documenting it creates visibility and accountability, but it rarely changes the outcome unless it leads to a deliberate decision. 

This experience also changes how comprehensive risk registers should be interpreted. 

Teams sometimes take pride in identifying hundreds of risks. Comprehensive identification is valuable, particularly on large or highly regulated projects. 

The more important question is different: 

Which risks require active treatment today? 

Every identified risk deserves an appropriate level of attention, but not every risk requires immediate intervention. Some require active treatment. Others simply require monitoring until their likelihood, impact or proximity changes. 

That prioritisation drives action. 

The answer also depends on ownership. Some risks can be managed within the project team. Others, such as regulatory change, exchange rate fluctuations or cybersecurity threats, require action at programme, portfolio or organisational level. 

Good risk management includes ensuring that risks are owned at the level where meaningful action can actually be taken. 

Another useful practice comes from an experienced project manager who approached weekly risk reviews differently. Rather than opening the risk register at the beginning of every meeting, he started with a single question: 

"What worries us this week that didn't worry us last week?" 

Only after that discussion did the team review the register. 

The purpose was not to replace documentation. It was to ensure that current thinking shaped the conversation before existing documentation shaped people's assumptions. 

Because risks evolve. 

A good risk register should evolve with them. 

But without regular challenge, even well-maintained registers can become snapshots of yesterday's thinking rather than reflections of today's reality. 

Another lesson became increasingly apparent over time. 

The most significant risks rarely announce themselves as major events. They usually begin as weak signals. 

A supplier who suddenly becomes less responsive. A key engineer repeatedly missing design reviews. A customer who unexpectedly stops asking detailed technical questions. 

Individually, these observations may not justify immediate escalation. Collectively, they often indicate that the project's risk profile is changing. 

Experienced project managers pay attention to these leading indicators, not because every weak signal becomes a major issue, but because patterns often emerge long before formal metrics deteriorate. 

One missed design review rarely matters. Several seemingly unrelated warning signs occurring together often do. 

Much of that experience comes from pattern recognition. Having seen similar situations before, experienced managers often recognise combinations of small changes that less experienced teams understandably dismiss as isolated events. 

Less experienced teams often wait until the issue appears as a red status on a dashboard, by which time the available response options are usually more limited. 

This is why effective risk management depends as much on conversations as documentation. 

The risk register provides the institutional memory. The conversations are where assumptions are challenged, decisions are made and actions are agreed. Without them, the register risks becoming an archive rather than a management tool. 

Ultimately, the purpose of risk management is not to produce better documentation. It is to support better decisions under uncertainty. 

Every risk response is, at its heart, a management decision: whether to reduce the risk, transfer it, prepare for it, or consciously accept it. The quality of those decisions determines how well a project navigates uncertainty. 

The value of a risk register lies not in the number of entries it contains, but in the quality of the conversations and decisions it enables. Those conversations often depend on the team's ability to challenge its own assumptions.

At the end of each week, it is worth asking a simple question: 

"If someone joined this project today with fresh eyes, what would concern them first?" 

Familiarity is valuable. It is also dangerous. 

The longer teams work on a project, the easier it becomes to normalise warning signs that would immediately stand out to someone seeing the situation for the first time. 

Fresh perspectives often reveal assumptions that experience has quietly accepted. Projects benefit enormously from people who are willing to ask uncomfortable questions before circumstances force everyone else to answer them. 

The purpose of risk management is not to predict every possible future event. That is impossible. It is to help teams recognise uncertainty earlier, make better decisions, and take deliberate action before limited options become no options. 

A project that experiences a realised risk has not necessarily managed risk poorly. Likewise, a project that avoids major problems has not necessarily managed risk well. Good risk management is measured by the quality of the decisions made before uncertainty becomes reality. 

Identifying a risk is the beginning of risk management, not the end of it. 

A risk register records uncertainty. Good project management changes what happens because of it.