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
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:
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:
As to project risks, a similar approach can be taken:
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.
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.
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.
