There are potential events you know about (i.e. known risks). There are potential events that you have no idea about (i.e. unknown risk). It is important to uncover as many known risks (both threats and opportunities) as possible to avoid costing the project time and money. Therefore, risk identification is not a project manager-only role, but rather, it is done best when many are involved. This post covers how risks can be identified and recorded.

Sources for risk identification

To identify as many risks as possible, there are multiple resources to tap into:

  1. Project documents defining the project objectives, requirements, deliverables, constraints, and assumptions. These are generally self-explanatory.  Note, however, any assumptions made may or may not have been the right thing to assume.  Therefore, each assumption must be turned into a risk.
  2. Schedule (including the network diagram). The network diagram is helpful in looking at relationships between activities. The schedule shows date relationships.
  3. Estimates for cost and resources. Aggressive estimates are a problem, and so are ones that are padded.  You want a believable plan; at either extreme, you are putting your reputation as a project manager at risk.
  4. Contract. Review the contract thoroughly if the project was commissioned by an external customer.
  5.  Lessons learned and other historical documents from prior projects. Take advantage to learn what those before you have learned so you do not repeat the same mistakes.
  6. Policies, procedures, regulations, and systems. These can be mandated by your organization, company, customer, industry, or government.
  7. Resource calendars. Check for such things as vacations, sabbaticals, work schedules, and other major deadlines and commitments.
  8. Company calendars. Check for planned shutdowns or holidays. For overseas collaborations, realize countries have different holidays.
  9. Team members. The experts who are going to do the work are critical for identifying risks since they have the best understanding of the work to be done. This is non-negotiable: include your team.
  10. Other stakeholders not on the project team. Many functional managers have a wide-breadth of experience from which to draw.
  11. Experts that have nothing to do with the project but are knowledgeable enough to spot trouble. I learned this from my lean manufacturing training. Sometimes a smart person who is unhindered by the burden of the project can provide a fresh perspective on problems with the plan.

Methods to collect inputs

In order to capture all of the inputs, I love having brainstorming meetings. Make sure to have a constructive, facilitated method of doing brainstorming. Check out the web for brainstorming techniques including fishbone diagrams, affinity diagrams, etc.

Depending on the location of the people and their calendars, it is not always possible to have everyone at a meeting. In this case, consider one-on-one interviews in person, telephone, or email. (I prefer speaking with a person versus an email any day. It is much easier to communicate.)

Recording inputs

Capture all of the risks in a risk log or register. Some details that you commonly find in a risk log are noted below. At this point, you have enough information for the first three.

  1. Risk number
  2. Risk description
  3. Risk category (e.g. technical, product requirements, project management, phases, processes)
  4. Probability
  5. Impact
  6. Probability x Impact
  7. Response plan
  8. Trigger for the response plan
  9. Person responsible
  10. Current status

If your organization has a PMO (Project Management Office), a template may already exist. Otherwise, I typically use a spreadsheet, and the above are my column headings.

More inputs are better than less. So, make sure to capture all the identified risks. Do not discard any at this step. You will have an opportunity for that after you’ve ranked them.

Let me leave you with this: it is better to know as many threats and opportunities upfront in your project than be surprised later.