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?

  • Related question: how do you measure risk?
    – Mchl
    Commented Feb 7, 2011 at 22:25
  • @Mchl - then go post it... You're right, it's a good question, let's get some answers. Commented Feb 7, 2011 at 22:26
  • Book recommendation - read Waltzing with Bears by Tom DeMarco and Timothy Lister
    – Kris C
    Commented Mar 4, 2012 at 19:18
  • You may find this blog post of mine relevant and useful: 0rsk.com: Cause + Risk + Effect
    – yegor256
    Commented May 16, 2019 at 8:52

7 Answers 7


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.

  • I find very hard to calculate the likelihood of certain events
    – yoda
    Commented Feb 7, 2011 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. Commented Feb 7, 2011 at 22:21
  • 6
    what yoda meant to say was "always in motion, the future is" Commented Feb 8, 2011 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 incorrect 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.

  • 1
    Found the last phrase a very true statement. PM should cover step-by-step all those requirements even, or specially, when ommited.
    – yoda
    Commented Feb 7, 2011 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.

  • 2
    +1 - But can you cite your reference and show the PMI definition. Thanks!
    – jmort253
    Commented Feb 7, 2011 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
    Commented Feb 7, 2011 at 22:18

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.


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!

  • +1 - I like how you eliminate blame in the Consequence section and focus on core reasons why it's a risk.
    – jmort253
    Commented Mar 3, 2012 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.


I define a 'risk' in terms of the 'cause' of an adverse 'impact' to your objective (which may be a project objective or measure of success) which has not happened yet. I can only manage down the scale or likelihood of the 'impact' by 'action' on the 'cause' = mitigating action or mitigation plan. People 'buy in' when they understand - so keep it simple and clear.

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.