Message to Som Gollakota

Please Enter All Requested Information Below
Your Name
Email Address
Leave this Blank:
Woodinville, WA
Risk Management - Identifying Risks
November 4, 2009
Is the process of determining which risks may affect the project and documenting their characteristics.
-Identify Risks, PMBOK 4
hile the previous section talked about the future (how we would manage risks in our project), this section, Identify Risks, is the first piece of groundwork we do (soon after, or even during, the risk management planning). And I would go even a step further than PMBOK and say, it is an ongoing process of actively seeking out all plausible risks related to the operating environment of the project, determining which of them may actually affect the project, and documenting their characteristics.
Identifying risks is not a one-time-at-the-start-of-the-project affair. It is an ongoing effort through the entire timeline of the project. Risk identification must occur in every process and every meeting.
Inputs to the process
All project artifacts including, but not limited to, all management plans (PM, RM, Scope, Schedule, Cost, Budget, Quality etc.), Stakeholder list, environmental factors, Master List of Assumptions, and organizational process assets, serve as inputs to the risk identification.
Identifying Risks - Techniques
  1. Reviews: Risks may be identified while the project artifacts are reviewed. While some of these may be reviewed at or soon after their creation, many would have to be reviewed on periodic basis to verify if any new risks have come up (can be identified) around these plans and artifact statements. Each assumption (noted in the Project Master Assumptions List) would have one or more risks associated with it.
    Risks to the project that come up due to quality of these documents may be easily mitigated. However, the content of these artifacts (such as plans, scope, requirements, schedule) etc., may have inherent risks outside just the quality of such documents. These may come out during such reviews.
  2. Information Gathering: PMBOK identifies four techniques - Brainstorming (group of people discussing), Delphi (reaching consensus by seeking anonymous participation and summarization), Interviewing (experienced participants, experts and stakeholders), and Root Cause Analysis (identifying underlying causes of the problem and formulating solutions). My personal favorite is Brainstorming for the reasons explained below.
    1. It encourages what is arguably the best form of communication - face to face interaction, builds team spirit, and trust.
    2. I can use it any time any place where my team has gathered (team status meetings, document reviews, informal gatherings, hallway conversations).
    3. This, while assumes existence of high professionalism, trust, and maturity among team members, also fosters those qualities in a team.
    4. Has the potential to wrap up in one session, rather than back-and-forth electronic communication
  3. SWOT Analysis: This is my personal favorite - blends right in with my Brainstorming technique. Identify Strengths and Weaknesses (team dynamics play a big factor in a project's success or failure; and brainstorming is an excellent way to identify and cash them). Identify Opportunities and Threats within a project (as well as the project's operating environment). Treat weaknesses as potential threats (to mitigate or marginalize) and strengths as potential opportunities (to maximize). All of these (threats and opportunities) will then become your risks (see definition of a Risk in Introduction page).
  4. Assumption Analysis: Every assumption made by the team (or the stakeholders) at every phase of the project, before the project is even born and beyond the project, must be collected/documented in the Master Assumptions List. An assumption is made either due to lack of or insufficient information, or environmental conditions, and hence are subject to change. Therefore, analyzing assumptions is an excellent way of identifying associated risks for each assumption made. Personally, I list at least one risk for each assumption (If the assumption proves false, then...).
  5. Checklist Analysis: Involves working up an RBS (if nothing else is available) and building a checklist based on historical information and knowledge. It could be built easily/quickly, but could also be tedious or time-consuming in many cases where no such information is available. Further, it does not allow for a comprehensive list or even a good, well-rounded list. Plainly put, I don't like this method.
  6. Diagramming Techniques: Such as Cause and Effect, or Fishbone, or Ishikawa (to identify causes), Flow diagrams (to depict process/system flows and interrelations), and Influence Diagrams.
The most important output of this process is a list of Risk Statements compiled into a Risk Register (or Log). Each risk statement must be a self-contained one clearly articulating the risk and impact. I typically use a simple structure of "If cause, then event may occur, resulting in impact".
Bad Example: Due to lack of clearly documented requirements/detailed scope for the project, success of delivery cannot be quantified.
It sounds more like an Issue than a Risk. Further, it does not include the affect the above risk (issue) would have on the project.
Good Example If the infrastructure/hardware procurement is not complete in 2009 Calendar Year, the vendor will not be able to offer 2009 discounts, resulting in an additional $50,000 to the project procurement cost.
It outlines a possible situation (we would not receive discounts if we don't procure in 2009), and outlines a specific budget impact due to higher procurement cost.
Personally, I prefer using a combination of Reviews, SWOT Analysis and Assumptions Analysis (or all three) for Risk Identification and Brainstorming for Information Gathering. They yielded maximum results in minimum time, because they involve individuals from various groups (the team). They have the potential for identification, articulation and verification of the risks in one go.
Regardless of the structure you choose to use, remember that if a future event is a certainty (and not a possibility), it is not a risk; it is an issue. For a future event to qualify as a risk, there must be certain amount of uncertainty (may or many not occur depending on the cause) and a possibility of avoidance or mitigation.