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?
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 consider three kinds of risks:
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.
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.
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...
Best risk reference I've ever encountered is the SEI's Continuous Risk Management Guidebook tough to find, but a great reference book!
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.
Project risk refers to any event or situation that might happen during the course of a project that could impact its success, either in a positive or negative way. Risks can come from many different areas, such as changes in the market, unexpected costs, delays in the project timeline, or even new opportunities that arise. The key is to identify these risks early on so you can be better prepared.
The first step in managing project risk is recognizing potential issues that could affect the project's goals. These can be things like a delay in receiving materials, changes in customer requirements, or new technology that could disrupt the project. Once the risks are identified, the next step is to estimate how likely these events are to happen and what impact they could have on the project if they do occur.
By understanding the risks, you can plan strategies to handle them. If the risk is negative, like a potential delay, you can take steps to minimize its effect, such as having backup plans or adjusting the timeline. If the risk is positive, like an opportunity to use new technology, you can plan how to take advantage of it to benefit the project.
In short, managing project risks involves being aware of both potential problems and opportunities, planning ahead, and taking action to keep the project on track for success.
