Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Categories: risk
This article is part seven of my look into project risk management, and today the topic is project risk identification.
Read part 1 here: An introduction to risk management
Read part 2 here: Trends and Emerging Practices in Project Risk Management (Part A)
Read part 3 here: Trends and Emerging Practices in Project Risk Management (Part B)
Read part 4 here: Tailoring Risk Management
Read part 5 here: Planning Risk Management
Read part 6 here: The Risk Management Plan
Identify Risks is the second process in the Risk Management Knowledge Area. It’s where we work out what risks might befell the project.
In the process we look for overall project risk and also individual project risks – things that might affect one particular area of the project.
Typically, risk identification is done at the beginning of the project to work out what existing risks there are facing the project. However, it should be an ongoing activity, and you’ll revisit it from time to time during the project. Especially as you start to spend the risk budget or work out the cost of risk management activities – I think risk identification and management tends to spawn new risks. Perhaps that’s just because you get better at spotting them once you get started!
Inputs
There are loads of inputs to this process.
- The project management plan
- Project documents like the lessons learned log, duration estimates and requirements documentation
- Agreements, for example for procurement of external resources, because there is likely to be some risk in entering into any deal outside of your company’s immediate control
- Procurement documentation – check out what this has to say on seller performance reports, how changes will be managed, inspections and so on
- Enterprise environmental factors like benchmarking studies, commercial risk databases if you have access to them
- Organisational process assets like actual risks from past projects, checklists from past projects etc.
The project management plan has lots of areas that could give you useful information for the risk identification exercise including the requirements management plan because that might reference particular at risk deliverables.
The schedule management plan probably talks about areas of the schedule that aren’t yet fully known, and that is another area of risk.
The cost management plan may identify budget areas that haven’t been fully costed or understood, or areas of contingency that might warrant raising a risk to keep them on the radar. Cost estimates are a project document that might also be useful, because the cost may be expressed as a range and that implies a risk to the budget as you don’t know what the cost is going to be.
And so on.
Tools and Techniques
There are also quite a lot of tools and techniques, although most of them will be familiar, I’m sure:
- Expert judgement
- Data gathering including brainstorming (as you would do in a risk identification workshop), checklists and interviews
- Data analysis
- Interpersonal and team skills especially facilitation for your risk workshops
- Prompt lists (these are a list of categories against which to brainstorm – start with PESTLE if you don’t have any of your own)
- Meetings.
The data analysis you might want to do could include root cause analysis to uncover the underlying reasons for a risk – because knowing those will help you develop a better action plan.
You could also do a SWOT analysis, or look back on previous SWOT analyses. We used to do these annually as part of the department’s strategic planning, and there were often useful overarching risks in there that would translate to a project.
Outputs
The end result of this process is the risk register. The risk register will include the initial risk responses if you already know what it is you are going to do.
There’s also the beginnings of the risk report and the updates you do to various project documents like the assumptions log, issue log and the lessons learned register – if you find anything worth putting in those.
Who gets involved?
Pretty much anyone who is working on the project can get involved in risk identification. That includes you as the project manager, the sponsor, team members, the risk management team from your company if you have one, any other subject matter experts, customers and end users… basically anyone who has any interest or influence over the project or knows anything about the work you are doing.
Risk identification is everyone’s job. Set that expectation at the beginning of the project and you’ll be fine!
Next time I’ll look at qualitative risk analysis – in other words, what to do with those risks now you’ve identified them.
Pin for later reading:
Posted on: September 26, 2020 12:41 PM |
Permalink