Why Do We Need to Worry About Risk Management?
As many around the world rejoice and reflect on the cave rescue in Thailand, I’m struck by how important the vision of getting everyone out safely drove an almost impossible project. For years, I have written about the need for project managers to create a compelling vision statement and get people behind it. There really is no substitute. But is having a compelling vision all there is?
In this series of blogs, I will write about some other important parts of project management. I’ll start with risk management, as I suspect that risk management was a huge part of the cave rescue project.
It’s easy to think about risks when lives are at stake. But what about risks on more routine projects? Why do we need to worry about risk management on them? For starters, thinking about risks is one way to reduce your chances of project failure. And with failure rates still high, maybe we need to be focusing on risks.
I’ve written before on how to do risk management. The key is to make it a part of your regular process. If it’s not part of your discipline, it won’t happen.
What kind of risks should you be considering?
That depends on the nature of your project. Do you have key people involved who are particularly critical? Are there particular products needed that might not arrive on time? Is there some kind of process change people need to adopt where failure to comply could derail your project? Could weather problems complicate your project? The list goes on.
I once read about a massive IT conversion that was scheduled to take place in Florida during hurricane season. I’ve forgotten the details, but if I remember correctly, no one created a backup plan and a hurricane hit. The conversion failed miserably.
I’ve seen projects where there were both project risks in the short-term and longer-term risks associated with the successfulness of the actual project output. For example, a short-term project risk might involve the inability of certain people on the project to perform as expected. Those kinds of projects can be identified and managed during the project.
But suppose the project is to build a new HR review process or technology interface for handling registration. Might there be a longer-term risk that adoption is not as predicted? How should you manage that kind of a risk after the project finishes and your project team has been disbanded? Do you need a process for managing adoption issues or training concerns long after the project has finished? Probably…
Where are you cataloging your risks?
Does your project management software provide a risk management module? If not, you can set up a simple spreadsheet. But the best spreadsheet in the world is no good if people aren’t paying regular attention to it. You have to build risk management into your project disciplines.
Who should be involved in your risk management process?
Risk management is not something that can or should be delegated to one person. It needs to be done with the team, as all of the different perspectives are critical. It needs to start at the beginning of your project and become a regular discipline that involves the entire team (and, perhaps representatives from senior management) during the project. At the end of the project, the management of long-term risks related to the project result will become a responsibility of the larger organization.
This concept of longer-term risk management can include a discussion of how you want to measure long-term benefits, which I will cover in an upcoming blog.
Looking for more project tips or business insights? Sign up for my weekly newsletter, where I offer a link to my blog and a book review.
