Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

I've had trouble in the past explaining project risk to non-PMs.

For me the key element I struggle to get people to accept is that a risk is something outside the control of those on the project (so "the programmers miss their estimates" (without giving a specific reason) doesn't count as that's just bad estimating).

So how you you define risk and how do you explain it and get buy in?

share|improve this question
1  
+1 for the question –  yoda Feb 7 '11 at 22:00
    
Related question: how do you measure risk? –  Mchl Feb 7 '11 at 22:25
    
@Mchl - then go post it... You're right, it's a good question, let's get some answers. –  Jon Hopkins Feb 7 '11 at 22:26
    
Book recommendation - read Waltzing with Bears by Tom DeMarco and Timothy Lister –  Kris C Mar 4 '12 at 19:18

6 Answers 6

Risk is any uncertain event that can have an impact on the success of a project. Schedule slippage is a risk, even if it's caused by bad estimating. Another example would be a change in requirements.

You can help manage risk by using a risk matrix. By plotting the severity of an event against its likelihood, a risk matrix helps you prioritize which risks to address.

share|improve this answer
    
I find very hard to calculate the likelihood of certain events –  yoda Feb 7 '11 at 22:18
1  
@yoda: So do I. Estimating is one of the hardest parts of my job. As far as risk assessment goes, you normally rank them on a scale of 1-10 relative to each other, rather than trying to come up with an accurate likelihood. –  Bill the Lizard Feb 7 '11 at 22:21
    
good spec, thanks! –  yoda Feb 7 '11 at 22:25
5  
what yoda meant to say was "always in motion, the future is" –  Steven A. Lowe Feb 8 '11 at 1:58

I consider three kinds of risks:

  1. errors and omissions
  2. things that you don't know (including things that you don't know you don't know)
  3. unstated yet incorred assumptions

The first category includes overlooked features, estimation mistakes, and incorrect specifications. There risks are so mundane they're often not considered as risks, but they are still risks because they may adversely (positive or negative) affect the outcome of the project. Careful tracking of relevant metrics (estimation error, team velocity, et al) and use of self-correcting techniques (wideband delphi estimation, evidence-based scheduling, et al) can help.

The second category is large and obvious. Research and prototyping are your friend!

The third category is sneaky, and potentially devastating. A common example is building a software system for a single platform in one language (e.g. Windows 7 and English are assumed but never specified) only to discover far into the process that you also have to deliver on Mac in Chinese. The way to combat this kind of risk is to state the obvious and question all implications in the requirements.

share|improve this answer
    
Found the last phrase a very true statement. PM should cover step-by-step all those requirements even, or specially, when ommited. –  yoda Feb 7 '11 at 22:23

I would define risk as any uncertain event that may or may not happen, that will impact your project. (This is pretty much the PMI definition.) This may mean that risks are within your control.

For example, on a software development project, one risk might be that the programmers don't finish the project on time. It might not be bad estimates, but it could be something within their control, like an inflexible design.

Also, some people include the positive aspects of risks in the definition (something the rest of us call "opportunities") -- like your marketing department does an unexpectedly amazing job and you're now deluged with orders you can't handle.

share|improve this answer
2  
+1 - But can you cite your reference and show the PMI definition. Thanks! –  jmort253 Feb 7 '11 at 22:14
    
I can't reference it. The PMBOK is copyrighted; and it's not always the easiest material to understand. Please take my word for it :) –  ashes999 Feb 7 '11 at 22:18
    
+1 on the comment and the PMBOK comment :) –  Mark Phillips Feb 9 '11 at 2:56

The Prince 2 manual states that "The purpose of the Risk theme is to identify, assess and control uncertainty, and, as a result, improve the ability of the project to succeed". Not a bad description of why Prince 2 focuses heavily on risk. It also makes the point that risk is inevitable in projects as every project is an enabler of change, and change introduces uncertainty, i.e. risk.

I suggest that you should explain that risk is the uncertainty that comes from making any change, and state that a strategy is required to deal with risk (noting that the strategy may validly be to accept at least some individual risks). If you document the strategy and ask your project sponsor to sign off against it, you are more likely to get a response than if you just have a discussion with no evidence that this took place. This may appear to be a bit Machiavellian, but as PM you have to protect yourself as well as giving the project the greatest opportunity to succeed.

share|improve this answer

Definition of Risk is "The possibility of suffering a loss" but that is pretty non-useful (IMHO) better is to describe the key elements of a risk. That is, when you can fill in each of these fields, you have a decent handle on "what is the risk?"

Condition - what is the circumstance, situation or setting that is causing concern, doubt, anxiety or uncertainty

Consequence - what is/are the possible outcomes of the current conditions

From there, additional elements can be attached, but getting each risk into the condition/consequence form helps find the essence and keeps the risks well scoped/managed.

In your example: "the programmers miss their estimates"

I would get the person who raised that to focus first on the condition: "The engineers aren't good at estimating" is different than "We don't understand enough of the system" Get them to be specific about the situation. Also, keep scope small... what is the hardest part to estimate? Is there anything that is less uncertain to estimate? 10 small but manageable risks are better than 1 risk that "the whole project is doomed" After they have the situation, then the consequence can be identified. In general these boil down to "cost, time and quality" (e.g. cost increases) Don't mix these tho. If the programmers miss their estimates, then the schedule is impacted (costs too, but the schedule is the primary impact and is what you will be managing directly)

Getting buy in: A few points...

  • only add risks that can be managed. "The project is doomed" is unmanageable.
  • Use the risk register to build a buffer that you expose and manage visibly
  • review the risk register (top 5-10) periodically (each week/2 week/month period)
  • be relentless about closing risks and asking the team "what can we do about this risk?" the team will care if you care

Best risk reference I've ever encountered is the SEI's Continuous Risk Management Guidebook tough to find, but a great reference book!

share|improve this answer
    
+1 - I like how you eliminate blame in the Consequence section and focus on core reasons why it's a risk. –  jmort253 Mar 3 '12 at 21:48

Taking a risk is making a decision not knowing exactly how it will turn up. A decision that could have an impact on the quality and the results of your project. You can miss money, time, human ressources; you can have to deal with an human mistake, etc. The main risk in managing anykind of projects is bad planning. You realize a little bit too late that you will not respect your deadlines for example or that you do not have the ressources to do it. Some people are better planificators that others. You can witness that in their personal life. Some see the problems comming in advance, others only when they hit their nose. You can try to take a calculated risk, meaning that you have a fair chance of knowing how things will evolve. To my point of view, the critical period in a project is the beginning. Most people do not feel any pressure at the biginning, while other starts organizing and planning every steps of their project. The best way to respect a deadline and avoid risk is to have a precise idea of how to do every steps of your project in the biginning. My personal way is to have a rush at the beginning and not at the end; and evaluate well the complexity of my tasks and what kind of ressources I will need to reach my goals (human, material, etc). Finding that too late, is the biggest risk you can take. Some like to work under pressure, working almost round the clock at the end of their project. They get tired and sometimes make mistake or overevaluate their potential. I prefer to have some over time at the end. Some time that give you an opportunity to innovate and do something not planned that add greatly to the final value of your project.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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