How to Identify Major Risks Present In Your Project
By Glen D. Ford
Risk and risk management is part of the game when running projects. That’s why risk management is so important to project managers. And why so much time is spent identifying the potentials and their effects. And so much time is spent making plans for things that might happen — and might not.
So how do you identify major risks present in your project?
First off, let’s correct some terminology. You don’t identify major risks. You identify major risk events. Risk is another word for probability or uncertainty. Specifically, it means that the event is not a certainty. You don’t know that it won’t happen, but equally you don’t know that it won’t happen.
This uncertainty means that as a seer you are faced with a difficulty. When do you spend money to avoid or encourage what may not happen? It’s hard enough predicting what you need to do. Predicting what you might have to do and then predicting what you should do because of that, can get a little mind-bending. Especially when you realize that disruption can be positive or negative. Having a new release with all your custom enhancements is extremely disruptive to an implementation plan. Especially when it happens in the middle of your customization efforts.
In this article, I’m going to focus on the 5 major ways to identify major risk events in your project.
- Past History
Every time you work on a project, you should be reviewing the lessons learned. This includes a list of the risks encountered. Of course, every once in a while you will encounter projects that you or your organization have never encountered before. That’s when you need to rely on others’ experience. Google can point you to risk event lists prepared by others. Project management texts also often contain risk lists. Consultants can also be a source of risk lists.
Work Breakdown Review
I originally called this brainstorming. Brainstorming is a technique of generating ideas and then reviewing them afterwards. It is one of the most popular methods of identifying major risk events. But even if you’re not using brainstorming, there is one common thread. You are starting from the work breakdown structure or list of tasks and identifying where things could occur.
Dr. Kaoru Ishikawa was a Japanese professor and quality management innovator. He is most remembered for his fishbone diagram which assists in cause and effect analysis. A cause and effect analysis begins by identifying the possible sources of problems and opportunities. And then progresses to identifying the possible risk events. The result is a logical list of risk events. This is unlike a work breakdown review which begins from the tasks and uses random idea generation. Each method tends to fill in the risk events the other misses.
So far, we’ve talked about formal techniques based on history or analysis. However, there is another possible source of ideas. Ask your sponsor and stakeholders. Often, people who are involved in the identification of the project can provide a different viewpoint. They will spot major risk events that are not spotted by analytical techniques.
Keep your eyes open
This is also known as the stumble-upon method. As we work through a project, the randomness of uncertainty disappears. As a result, uncertain or risk events also appear with greater clarity. One source that no project manager can afford to ignore is the team working on the project. I’m not talking about the managing team. I’m talking about the actual producing team. Their feedback and observations on potential risk events is critical. It should be included in every team meeting.
Glen Ford is an accomplished project management consultant, trainer and writer. He has over 20 years experience as a project manager in such diverse projects as Construction, IT, Software Development, Marketing and Business Startup. He is a serial entrepreneur who quite literally learned to be an entrepreneur at his great-grandfather’s knee.
Check out his newest book available on Amazon at http://vproz.ca/books/how-to-document-a-project-plan. You can read more from Glen on his blog.