Risk Management Isn’t Optional. Here Are 5 Tips for Doing It Right

I’m amazed at how often I receive requests for help creating an effective risk management process. These inquiries usually come from organizations with a risk management process that hardly anyone uses. Stakeholders, program managers, department heads and executives are mystified about why nobody is declaring risks on their projects, which can create the false perception that everything is going fine.

Why does this happen? One reason is that project managers believe making risks visible to leadership could impair their efforts. Another reason is an organizational culture that creates a negative perception of risks. For example, I have seen some highly entrepreneurial companies foster a mindset of rugged heroism, which causes project managers to think they have to fix everything themselves. In this project environment, project managers worry that escalation to leadership will be seen as a sign of weakness.   

In fact, there’s no use pretending any project is risk-free. Risk management is an essential part of any project: Whether you’re climbing a mountain or changing a light bulb, there are always risks. For anyone who’s ever been leery about flagging risks, or is just looking for some new approaches, here are five tips.

1. Think of risk management as a way to get what you need, when you need it.

Project managers rarely have the financial or command authority to change schedules or release additional funding—that’s leadership’s job. For this basic reason, declaring and escalating risks enables leaders to provide risk mitigation assistance. 

Making risks visible to your leadership gives them enough lead time to provide relief when it is needed, not weeks or months later when unmitigated risks turn into project problems.     

2. Don’t forget: People can be risks, too.

I have seen many risk management plans focus entirely on things: systems that might not be ready, processes affected by outside regulatory bodies, estimates that were done in a hurry at year-end budget cycles, etc.

What project managers often fail to consider in their risk planning is that people can also be risks.

For example, let’s say your project sponsor is replaced by someone who has no experience in the subject areas of your project. This lack of experience initially will cause longer decision-making cycles as the new sponsor comes up to speed in the subject areas.

So be sure to include people risks in your risk register—they can affect your progress as much as more inanimate factors.  

3. Create guiding principles for risk management.

While there may be a process in place for managing risks once they appear, quite often it is unclear to project managers when and how to escalate risks to higher levels in an organization based on their potential impact.  

To create clarity and promote transparency around risk management, the best approach is to set guiding principles that govern the process. The rules should be simple and broadly communicated throughout an organization.

Examples of guiding principles include:

Declaring project risks demonstrates professional discipline that will be recognized by leadership.

 A potential mitigation approach should be prepared for every identified risk.  

Risks with greater potential impact need to be made visible at higher levels in the organization.

4. Use the 30/20/10 rule of thumb.

In my experience, the most frequent question asked by project managers is how many risks should be identified on a project. For example, a person might feel that a small project should have a small number of risks. But that’s not necessarily true, especially if a small project impacts a large population of people.

One risk management approach I recommend to project managers is the 30/20/10 rule, which starts with a broad slate of risks and narrows them down throughout the life of the project.

Here’s how it works: Identify risks at the beginning of the project that, if realized, would affect 30 percent of the schedule, budget or results. Midway through the project, the goal is to lower the potential impact of risks to 20 percent of the schedule, budget or results. By the end of the project, the project should carry risks containing no more than a 10 percent impact.

5. Don’t forget the bigger picture.   

Project managers frequently tell me they would have finished a project on schedule, but team members were pulled into another project. Translation: another project was more important. And the strategic relevance of your project matters just as much as how you manage that project on a day-to-day basis.

To manage the risk of irrelevance, conduct an assessment on a recurring basis of how your project fits into your organization’s strategy and portfolio. Validate the relative priority of the project against other active and pending projects, and check on potential scheduling dependencies that may impact your plans, as well as any resource conflicts that may be triggered by other projects.

What techniques do you use to identify and mitigate risks on a project? If you’ve worked at an organization where flagging risks attracted negative attention from higher-ups, how did you deal with this challenge?