What risk identification methods you recommend to use? If a project manager needs to build a raw list of risks containing, say, 100 items, how would he/she do it? As I understand, brain storming is not the best mechanism here.

PS. I finally managed to create my own system for that: 0rsk.com: Cause + Risk + Effect

  • What about What-if scenario analysis?
    – Draco
    Commented Mar 2, 2011 at 11:48
  • What-If Analysis (also called Sensitivity Analysis) is used after risks are identified, during risk response planning process (according to PMBOK)
    – yegor256
    Commented Mar 2, 2011 at 17:35

10 Answers 10


According to PMBOK, there are a lot of activities involved in Risk Management, but there are definitely some specific tools and techniques for identifying risk. Some of my favorites are:

  • Brainstorming - I know you indicate it might not be the best, but I think there are some projects where this technique can be valuable.
  • Interviewing - Talk to experienced team members, stakeholders, and SMEs
  • Root cause analysis - My favorite technique here is to ask "why" 5 times to get to the true root cause, and then to develop preventive action.
  • Checklists - based on historical knowledge and documentation. This is why historical project documentation is important, even though many people hate doing it. "Those who cannot learn from history are doomed to repeat it." (George Santayana)
  • SWOT (Strengths, Weaknesses, Opportunities, Threats)

It's important to remember that identifying risk is an iterative process, and the entire project team should be involved.


Not sure what you mean with a "raw list of a 100 risks". I assume you want to use this as some kind of checklist for similar projects? I would certainly question a list of a 100 risks on a single project, and if they are all genuine risks, than I would question the project ...

Nevertheless, my tool is the WBS!

Print it out on a large format, then plow through it with your team, questioning each and every element on it for possible mischief. If you have a large team, you can split them up in small groups to do the same, then discuss all findings in a plenary session. Try to get some representatives of other stakeholders to attend as well.

This will give you a valid list of risks for your project, and as they are connected to the appropriate work packages means you can take better informed decisions for handling them.

Good luck


This article on the Risk identification process (2016 edit: this site is now defunct, an article inspired by it can be found here) shows Brainstorming as a key method, the following two methods look to me just like brainstorming in a different attire, but then the author shows two analytical methods.

Wikipedia shows a more comprehensive picture.

You have not said what type of risks you want to analyse. Are you talking about project risks (i.e. the risks of not completing on schedule, on budget and to specified resources)? Or are you talking about business risks (i.e. risks that the project will not deliver the expected benefits).

I have not conducted a formal risk analysis session, but I believe no single method is good enough on its own. It all depends on how critical the project or system is. Are you talking about air traffic control, building a sky-scraper or making changes to a word processing piece of software? The consequences of errors for each of those are not quite the same, to say the least.

Some highly analytical approaches might be just too expensive in some situations, while the pure brainstorm might be too little in other situations.

Personally I would favour two different analytical techniques for systems (business) risks:

  1. Start from the business / systems requirements and evaluate what could cause them not to be met and what the consequence would be if they were not.
  2. Start from the system detailed architecture and evaluate the consequence of a component failure or the failure of the interface between two components.

As to project risks, a similar approach can be taken:

  1. Start from the expected benefits of the project and work back to what can cause them not to be met.
  2. Start from the project plan and evaluate which points of coordination and which tasks can go wrong.
  • The Risk identification process link is not working
    – Jyotirup
    Commented Apr 2, 2016 at 6:57
  • Sorry the whole website seems to have gone. 5 years down the road, I do not remember the specifics of the article, however I found another article seemingly inspired by the one I referred to, it might be helpful.
    – asoundmove
    Commented Apr 2, 2016 at 8:21

Pretty much all the risk will come from things the team has not done before (and every project has some aspect of that, unless you're experts in the particular field, in which case it isn't a 'project' so much as a 'job' - rolling out SAP in yet another enterprise, for example).

So, assuming you've got some things that the team has never done, first you need to find those things. Here's my step-by-step.

Find the stakeholders and their goals. There'll be some championing stakeholder for the project, but also a bunch of people who need to be kept happy in order to make it succeed - legal, audit, etc.

Divide the project into capabilities. The capabilities will be those that can help the business, or users, to achieve the stakeholder's goals. For instance, a software project might provide the capability to book a certain type of trade, calculate a particular aspect of risk, limit exposure to any one customer. A mobile phone has the capability to receive calls. Note that I am not referring to any concrete features here - the capability could be delivered through filling in paper forms, for instance.

Ask the team to identify which things they've never done before. For instance, while the ability to make and receive calls on a mobile is pretty standard, maybe the particular type of camera you're using is new. You can also look at which stakeholders have never been considered before. It could be that you're going to be delivering a capability in a new way - with a new UI, etc. - in which case, you probably have a new capability like "do X faster" as part of that.

Identify which things have been done before by someone else. These are things which require expertise you simply don't have. They're lower risk than the other things which have never been done before by anyone.

Identify things which have never been done by anyone. This is where your highest risks are.

By identifying things that the team has never done, you're bounding your ignorance. Brainstorming and other techniques tend to bring up things which are known or have been considered, but the biggest risks are in the things which haven't been considered. Pretty much those happen in the places where new stuff is occurring.

For good reading around this, I recommend Waltzing with Bears, and Dan North's post on Deliberate Discovery, which is written from a software perspective but IMO has some lessons for all walks of life.


If you build it, they (risks) will come

Craig and Stephan have great answers about the different tools and methods you and your team should use to identify an initial set of risks and that you should use periodically to refresh the list.

But just coming up with a list of risks is kind of pointless unless it's the first step in a risk management process, which is the mechanism to keep the pressure on until the risk has passed (lucky you), mitigated (nice work), or realized (sad).

Luckily, merely having a risk management structure in place will--over time--generate risks; this is because the best (meaning most insightful) risks often come to people during their normal daily work. Without a home for these thoughts they either linger as nagging worry beads in their minds, are actively neglected because people don't know how to deal with them (where they fester into nasty surprises), or are straight-up forgotten.

However, if your team knows that a risk management process is in place then these potential risks find their home in the process, where they can be properly dispositioned, watched, mitigated, etc. And as long as people perceive risk management as value-added, they'll keep using the process to track risks as they think of them.


Asking the team would be my first action. They may have idea of what risks are in their part of the work. Plus you can ask them about overall project risks they see. They may also know if they aren't done with another project or their time is being split across projects.

  • Why the down vote? Commented Mar 4, 2011 at 16:15
  • 1
    I don't find anything bad about it. But I believe is Determine risk process comes before building team process in PMBOK. How could you ask your team memeber when you just don't know who is in your team.
    – Chris
    Commented Aug 9, 2011 at 13:39
  • 1
    @Chris: "But I believe is Determine risk process comes before building team process in PMBOK" -- risk management should be continuous, that is, it is used throughout the entire life of the project. It sounds like you are taking PMBOK too literally.
    – Michael
    Commented May 25, 2012 at 14:07
  • 1
    @BrianCarlton I think you'll get more upvotes if you included a bit more detail. Have you tried this? What happened? Why do you think this is as or more beneficial than others' suggestions? As it is, this has been auto-flagged as a "low-quality answer", and I'm afraid I agree. Please consider editing!
    – Lunivore
    Commented Oct 8, 2012 at 23:02

Using the WBS is a great way. All of the subject matter experts, project owners, and participants should contribute in brain storming sessions to identify risks. This not only brings out the risks, but starts to show people how they will be relying on each other for the projects.

Also, man power should be addressed as a risk if it is one, but just head count. A previous poster talked about saying that certain people are under paid and might leave. Bringing this up is bad in any organization. It's also bad to discuss whether certain people are good at their jobs or not. Stick to the amount of people you need to do the work and the specific skills needed to complete the work, like specific software languages etc.


Practice. After you've done some risk analysis, you'll find that it is a learned skill. I believe this to be the most accurate answer to the question, but I acknowledge that it is not perhaps the most useful.

WBS - I'd like to second @aarom's answer. This is, in my opinion, the best way to build actionable risks. Some risk analysis techniques lead to quagmires. Focus on the WBS rarely does in my experience.

Structured questions. Imagine that you're writing the lesson's learned for the WBS task. The task is done and it failed. Why did it fail? What went wrong? That's likely to be your chief risk. You can also apply this at the project level. This obviously merges with @lunivore's answer - you want to consult prior lessons learned/ project closure documents for information.

The last time I consulted NIST Risk Management, it advocated but didn't fully explain an asset based approach. I think there is some merit there. @asoundmove lays out some principles, but the general notion is to identify what is important about the project - the charter/SOW should contain these. Then figure out what could go wrong. You can then descend from the charter to the capabilities, to the deliverables to the tasks asking the same questions throughout. Don't forget the two triangles (scope, schedule, quality) and (Business acumen, technical leadership, Project Manager skillset). What happens if those are compromised? What is the most likely reason for a schedule failure? What is the most likely reason why the end product might not match the business need? What is the most likely reason for stakeholders to lose interest? etc.

If you're in the information risk world You can also consult FAIR or Octave or the excellent resources at SIRA - some of those can be generalized beyond information security. I'm particularly fond of SIRA - they make the additional points that if you can't quantify the risk, it is of low value, and if you can't collect data to quantify the risk, you might need to invest your time/effort elsewhere.

As an aside, I'm not sure that I would value:

a raw list of risks containing, say, 100 items

I've only had one experience where the Risk Manager pursued that approach, and it led to quagmire as the team thrashed about trying to understand the risks and debating abstract details of some poorly expressed risks. Lots of things depend on the size, experience and discipline of the project team, but I'd urge you to strictly timebox any excercise that began that way.


Yea, I'll support using the WBS as a key tool to identify where risks might happen. I tend to do risk identification this way. With the sponsor as we develop the scope statement with the planning team as we develop the WBS With the project team as we approach key milestones/things change.

As to Tangureas's comment. I'm hoping that was a joke. No you can't say someone is underpaid and might leave. What you can do is identify the key risks for specific people leaving the project (not just the company). You can have standard approaches. what happens if the sponsor leaves the project what happens if the pm leaves the project what other key people do we need a plan for?


Risks identification happens before the project commencement, during planning and during execution.

Risks identified before the project commencement are included in the business case, proposal or contract, and given the high level nature of these risks, these are mostly addressed by including assumptions, factoring management reserve or including in the preliminary scope specific controls and milestones to address those risks.

Risks identified during planning are mostly determined by running risk identification workshops with project stakeholders and core delivery team. A Risk Identification Workshop is guided by a Risk Breakdown Structure (RBS) which is pretty much a breakdown of every delivery component. The group of stakeholders should analise and raise risks for each of the RBS items (if a risk exists). Risks should be qualitatively analised and response plans should be defined for the medium-high ranking risks. The response plan activities should be included in the schedule baselined.

Risks identified during the execution are mostly determined by holding meetings with stakeholders and delivery team, tracking the project schedule and the overall delivery. These risks a captured in the risk register and the response plans are included and tracked at the action logs. Risks should be qualitatively analised every fortnight or month, to validate if their likelihood and impact has changed and now requires a response plan.

This is Risk Management 101 and not doing so is a risk by itself.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.