A common sense approach to risk identification
I am "CA" Atreya (PMP, MBA), the author of this blog. I help businesses in Atlantic Canada achieve their BHAG successfully. You may subscribe to this blog using a feed reader (RSS).
It is not surprising that the Canadian dollar is marching towards parity to the US Dollar. I researched this in 2005 and was quite confident that the US dollar will need to significantly devalue against major currencies. I did not take into account the market imperfections and government interventions. I still believe that in the medium to long term we will see the US dollar devalue significantly. But we are not here to talk about currency. We are here to talk about the risk identification as part of risk management. I just used the Canadian dollar as an example of a risk. While the currency is definitely one of the major risk items, have you identified the other risks that will impact your business? Without getting into jargons, let’s discuss a common sense approach to identifying risks.
Just as you cannot solve a problem without identifying one, you cannot manage risks without identifying them. So whether you are managing a project, program or business, it is prudent to spend some time identifying the risk drivers. Since a project is a small unit in the project, program, business hierarchy, we’ll focus our attention on project risks. The same tools and techniques can be applied to program and business risks.
What if
If you plan to have any level of success in your risk management strategy, make these two words your buddies. You cannot afford to live without them when undertaking the risk identification exercise. Cultivate that habit of asking - “What if” to every statement, assumption, constraint or other “facts” in your project documentation and design. It will annoy (or amuse) your team members, but it will get the job done.
Identify the “assumption” risks
No doubt you have heard the phrase, “Assumption is the mother of all screw-ups”. But it is so true! The first and most obvious place to start is your assumptions and constraints list in your project documentation. Question you assumptions! I am going to repeat it: Question your assumptions!
Heavy equipment manufacturers are notorious for not adhering to communication standards as outlined by the Society of Automobile Engineers (SAE). We knew this going into the project. After repeated clarifications with the manufacturer’s dealer and the manufacturer themselves we were assured that the equipment we would be working on followed the SAE communication standards. At implementation we found that one of the installs would not work due to incompatible standards. We did not question the expertise level of the individuals we were dealing with. We assumed a product manager would not be incorrect. We got screwed!
You may find that that the probability of occurrence as you dig deeper using the “what-if” analysis decrease. But do not dismiss a risk at this stage just because you or someone else in a room thinks the probability of occurrence is low. This is the identification stage. The more risks you identify the better prepared you are going to be.
On another note, now is also a good time to look up past projects that share some common characteristics, if you have not yet already done so. This is the time to put that “lessons learned” repository into good use. Talk to senior project managers in your organization - leverage their experience and expertise.
Identify the not-so-apparent risks
Once you start questioning your assumptions, use the “what-if” technique to drill down to identify the not-so-apparent risks. “What-if the product manager was wrong and this particular equipment did not follow the SAE standards?” “What-if the equipment was built before the manufacturer adhered to the SAE standards?” We could have included a few thousand dollars into the budget contingent on the risk being triggered. As soon as the risk event was triggered we could have put our risk response plan into action and saved ourselves a bunch of time.
Brainstorm with your project team. It is also important to bring in the subject matter experts and experienced end users either as part of the brainstorming or as separate interviews. They bring in additional insight into the technology or the business process that the project team may not have. Undertake the “what-if” exercise with them. You’ll be surprised at the number of risks they help uncover.
The work breakdown structure is also a good place to identify project risks. It helps the group think through the “what-ifs” in a structured and logical manner.
The-anonymous-expert-identifies-the-risks
Put 4 economists in a room and you’ll find 5 scenarios about the economy. And you cannot get them to arrive at a consensus. Sometimes the same holds true for subject matter experts. If you find yourself in such a situation then it is best to avoid getting all of them in one room. Circulate a questionnaire (usually anonymous to ensure no bias) with some of the risks as a lead in. Let them come back to you with more. You can also use this technique if the experts are geographically spread apart. One good thing about this technique is that each expert is not influenced by another’s opinion. Consider using this technique when the experts do not want to be identified.
Once you, the project manager, are confident that you have identified all possible risks, jot them down for further analysis and risk response planning. Remember at this stage no risk is too small. Also remember that completing this stage means you are not done with risk identification. Risks can be identified in any project phase. Early on in the project life-cycle the sponsor, subject matter experts, end users and other external stakeholders can help identify risks. But as you get closer to the design and production, your project team will help identify more risks than the other stakeholders.
Care to share some real world examples on your experience with the risk identification process?
- How to develop an effective business risk management planIf a risk has already occurred in your business and...
- NB Power Sale - NERC, FERC, NPSS, NBOS - Making sense of it allI was just on the Facebook group that opposes the...
- Guide to successfully delivering IT projectsDid you know that a project’s success or failure is...
- IT METHODOLOGY - A Long and Winding RoadGuest post by Cameron Watson - Though the effort to...
- How to prepare for the PMP certification examI just passed the PMP® exam last week - and...

Thought provoking article.
Thanks Dape.
The key to successful project management is identifying and documenting risks early on in the project and devising a risk mitigation plan. Risk identification might be done in the project planning stage but it is important to continuously define risks in detail as the project progresses.
You are right. The project risk planning must occur in the planning phases. But that does not mean the project manager must stop looking out for risks in later project stages. New information could be uncovered that could negatively impact the project at any stage.
Leave your response!
Twitter Updates
follow me on Twitter
Subscribe via email
Browse Categories
Strategy Marketing CoSBI Leadership Project Management Trade Human Resource CEO Economics Finance Customers Sales Motivation
Recent Posts
Recognition
What is a SOB?
What's popular here
Recent Comments
Small Business Seminars
Post suggestions
Twitter Updates
About
Archives
Powered by WordPress | Entries (RSS) | Arthemia theme by Michael Hutagalung