How to Identify Risks In Your Project

Identifty Risks processTodd planned for a weekend camping trip with his friends. They planned the route, camping gear, compass, sleeping bags, food, beer, but overlooked one important risk associated with such trips.

Todd and his friends partied into the night, enjoyed the camp-fire, and went to sleep well after mid-night. And a grizzly bear decided to say hello in the wee hours of morning.

When an unplanned risk materializes, it can cripple the project or bring it to a grounding halt.

Identifying risks is one of the easiest processes, really. Our minds are wired to look for things that can go wrong, and that is what required for this process. Only caution to be exercised is to keep things in the realm of practicality.

Who identifies risks?

It could be the same team that worked on risk planning. Or it can be the team and few more people that know about the project and/or have experience working with similar project. Some organizations have risk management experts to help project teams identify risks.

Involving the team increases a sense of ownership in them. Also, when team actively thinks about risks they develop a mental frame that helps them deal with the risks in case they materialize.

How do we go about identifying risks?

First of all what we need is the Risk management plan.

Now, how do you identify a risk involved with any work that you want to do?

By analyzing that work carefully.

For instance, risks involved with Mount Everest climbing expedition are identified by analyzing climbing techniques, equipment and mountaineering gears used, health of climbers, support systems and weather condition.

On a project, things can go wrong in project costing, its scope, schedule or quality. Hence these must be studied closely, and analyzed carefully to identify risks. Therefore, we need scope baseline, cost, schedule and quality management plans as inputs. There may be risks associated with people hired for the project, either with their availability or skillsets, hence Human resource management plan becomes an input.

Activity cost estimates and duration estimates are to be looked at to see whether they seem sufficient to complete the tasks. If team feels that some of them are not sufficient then they are considered to be risks.

If the team identifies cost or duration estimates of any activity on the critical path to be risky, it heightens overall project risk. This is because if an activity on the critical path slips, entire project slips.

Some of the stakeholders have good knowledge about the project and/or domain, and involving them in risk identification exercise will be beneficial. You would need stakeholders register to identify such stakeholders.

Some of the useful project documents are assumptions log and work performance reports.

Procurement documents describe the work sourced out to another organization. These will help you understand risk involved with that work, based on its complexity and dependability with the work your team is doing. For instance, if deliverable from seller is delayed by a week (if there is no buffer in place) what risk will it pose for project dates?

We already understand from earlier processes why organizational process assets and enterprise environmental factors as important. The former can help you with lessons learned, risk documentation formats and templates, the latter can give you published checklists, commercial risk databases and risk attitude.

How do we do this?

Documentation reviews is about closely reviewing all project documents such as plans, contracts, contracts, written assumptions and so on we considered during inputs. Look for inconsistencies amongst them and if found identify the risks.

  • Brainstorming is a group technique which is done under a facilitator. Multiple groups can brainstorm independently and identify risks. With this exercise risk categories, scale, definitions can also be updated. Nominal group technique, explained as part of Collect requirements process, also can be used to identify risks.
  • Delphi technique is a ‘collective intelligence’ principle based method which means that decisions from a structured group of experts are more accurate than decisions from individuals. It is explained as part of Collect Requirements process.
  • This is driven by a facilitator and need not be done by putting all experts in one room. Often means of communication such as mails are employed by facilitator. She first sends the questions to the group of experts and seeks their feedback. She then collates them, removes everyone’s names against their feedback and circulates back with the group. Once a consensus nears (or based on number of rounds) the narrowed down decision is taken as final. Anonymity is important here to avoid bandwagon effort or halo effect, which may influence each other’s feedback.
  • Interviewing is quite useful as you tap into people’s understanding of the project and issues, and unearth risks.
  • Root cause analysis is about studying a problem, investigating the root causes and identifying preventive actions.

Checklist analysis is about analyzing check lists available in the system. Lowest level of Risk Breakdown Structure can also be considered as a checklist to assess risks. Checklists can never be exhaustive so this approach is a bit limited in this respect.

Assumptions analysis is just that – looking closely at all assumptions made in subsidiary plans, cost and duration estimates and project documents and then checking if they hide any potential risks.

Diagramming techniques represent certain data in the form of diagram helping us unearth hidden risks. These are briefly described here and detailed in the post on Perform Quality Control process.

  • Cause and effect diagrams are also called Ishikawa diagrams or Fishbone diagrams. These are used to identify potential factors causing an effect.

Example: Kathy from Landscaping project analyzed a defect found in the jogging track:

Fishbone diagram
Figure 2: Fishbone diagram

  • System or process flow charts used to identify risks in systems or processes defined.

Workflow chart - Identify Risks tool
Figure 3: Simple flow chart

  • Influence diagrams are decision diagrams used to model a decision situation showing the factors that influence decision. This makes it easy to understand all influencing factors and take informed decision.

Checklist analysis is about analyzing check lists available in the system. Lowest level of Risk Breakdown Structure can also be considered as a checklist to assess risks. Checklists can never be exhaustive so this approach is a bit limited in this respect.

SWOT analysis is a structured planning method making use of Strengths, Weaknesses, Opportunities and Threats involved in an environment, in order to make most of it. While first two are internal factors, last two are external (in the environment) factors. SWOT analysis is done for the entire project from a holistic perspective.

SWOT analysisFigure 2: SWOT analysis. Image courtesy: Wikipedia

What do we get?

Risk register is the sole output of Identify Risks process. This also is the starting point of this document, in the sese the document is created during this process. And during other risk management processes risk information in it gets elaborated. Risk register contains list all identified risks, their root causes and potential responses. These are identified using tools and techniques mentioned earlier such as interviews, brainstorming sessions, SWOT analysis, checklist analysis, expert judgment.

You don’t really need to identify potential responses to risks during this process. It is actually part of Plan Risk Responses process. However, sometimes responses become apparent while analyzing root causes, in which case you just log them.

Simple risk registerFigure 3: Sample risk register, that Kathy may come up with for her Landscaping project

How often are risks identified?

One of the possible risks while driving a car is possibility of an accident. To avoid it we keep checking certain things, consciously or unconsciously, such as speed of the car in relation to traffic, presence of potholes, obstacles or slippery liquids on the road, level of gas in the car, and engine temperature. And we do it throughout the drive.

Similarly, we need to keep revisiting risk register regularly during project execution to assess current risks or identify new ones. As project moves through phases different type of risks may be discovered.

It is best to tag these planning meetings to milestones, such as delivery of module or phase, so that identification of risks become a regular exercise amongst project activities.

Recommended by Google

{ 0 comments… add one }

Leave a Comment