Example Project risks – good and bad practice:
Firstly, poor examples: from page 1 of the world’s favourite search engine
Projects always carry risks. If you search online for “example project risks” there are some extremely poor examples on page 1 of the world’s favourite search engine. Most are very misleading, at best. We see many real risk registers every year and their contents are often unfit for purpose. This post shows why.
The PMI defines project risk as: “an event or condition that, if it occurs, has an effect on project objectives”. The keywords are “if it occurs”. In other words, true project risk always carries uncertainty.
If you review the content of risk registers in many businesses (as we do many times each year) you will see lots of items that don’t belong in the risk register. For example: if we do something poorly and its results are ‘unfit for purpose’, that’s not uncertainty. Items like ‘the requirements don’t match the user’s needs’ should never be in a risk register. They are both issues, not risks.
Later in this post, we share a number of valid example risks.
Actual Poor Examples: (all taken from page 1 of Google in Dec 2015)
The following are examples taken from publications on the internet (and are also typical of what we see in real risk registers):
- “Scope is ill-defined “. This is a statement of fact, not a description of uncertainty. It is therefore an issue, not a risk.
- “The project may be late ”. This example may seem to get close to describing risk but it does not. It is a general statement of outcome relating to the project. It describes no specific risk at all.
- “Project estimates are very optimistic ”. Once again, this is a statement. Assuming it is true, it is an issue, not a risk.
- “Poor data quality ”. This is no more than a totally unqualified statement. Period.
Every item in a risk register must clearly identify the specific uncertainty that gives rise to risk. General statements are of no use at all.
The above examples are very common and demonstrate a poor understanding of the difference between issues and risks. Yes, issues must be managed but they do not belong in the risk register/ process. An issue is a known or existing problem; a risk is a specific event or condition that may occur in the future which will be a problem if it does occur.
Organisations that are good at managing project risk often have few rules, but they are clear about what they classify (or allow to be referred to) as a project risk. This has a number of very positive benefits. For example, it helps people develop skills in identifying and managing risk. It makes the distinction between risk and aspects like poor execution (and issues) much clearer too. The next paragraph also provides some real help in classifying risk more accurately.
The basic definition of risk: “chance of danger” is the key
So let’s look a little closer at what risk actually is. The Oxford Dictionary’s definition of the word “risk” is “exposure to the chance of danger “.
There are two keywords in this statement: “chance” and “danger”. “Chance” in the context of projects means significant uncertainty and “danger” is negative – i.e. some form of negative impact, which brings us to another key distinction.
Opportunities should never be described as ‘positive risk‘, as the PMI’s PMBoK also declared in its 2013 update (1). Risk is negative (danger) and opportunity is positive. Mixing them together in the same discussion, as some people suggest, confuses people – a great deal. The concept of ‘positive risk’ is nonsense.
Risk management is a poorly understood subject and introducing confusing terms only makes things worse.
Good examples of real project risks:
Genuine projects always carry risk – i.e. uncertainty. Probably the biggest indicator of the likelihood of risk is whenever you hear the word “new”, i.e. new supplier, new process, (especially) new technology etc. Those definitely indicate the likely presence of risk. Quite possibly very grave risk in a project environment. The other most common source of risk is dependencies. These are both great sources of potential risk.
Here are some clear examples that could be very specific and very real project risks:
There is a risk that:
- “the export licence may not be granted.”
- “ground conditions may not be suitable for ….”
- “key (specific) system interfaces may not be compatible.”
- “there may not be the physical space for the required equipment.”
- “data rates for required image quality may exceed capacity.”
- “the regulator may introduce new requirements relating to…”
- “severe weather may impact progress.”
- “(the requirement for) full spatial coverage may not be physically possible.”
Assuming any of the above is true, we can identify strategies and actions to mitigate both likelihood of the risk occurring (where possible), and (always) its consequences should it still occur. That is real risk management.
Lastly, what’s the difference between risks and issues?
Risks are in the future; as they carry uncertainty, they may or may not happen at some time in the future. An issue is a matter of fact (no uncertainty) that either is or will cause a problem or a constraint on the project, that needs to be resolved. Also, not every issue that occurs will have been on the risk log; it might be nice to assume that it would, but risk logs are often a long way from ‘perfect’, whatever that may be.
Want to improve how risk is managed on your projects?
Notes:
- Footnote – PMBoK backing out of a recent trend: The PMI’s PMBoK® Edition 5, in 2013 published the following note in relation to its updates on project risk management, in Section X1.19 Section 11: “changes were made to move the emphasis away from the use of the term “positive risk” toward “opportunity” in line with feedback from the Project Management community”.
Share this:
12 Comments
Leave a Comment
Contact Us Now
EMAIL us today.
Or call ++44 (0)1865 784040
“the export licence may not be granted.” If this is to be awarded by a body that you have no influence of, how can you a) define a probability of occurrence and b) apply any mitigation strategy other than Business of As Usual?
Bill – this is a classic risk that cannot simply be accepted (or even worse ignored). If this is a genuine risk, a contingency plan is usually be required, together with sensible actions to mitigate the risk. I do not see how “business as usual” solves the issue that would occur and would likely leave us totally ill-prepared should it actually happen. Risk management is all about mitigating the impact of risk as far as possible, enabling the project to continue, as far as possible, should known risks occur. With regard to this specific risk, the aim of the contingency plan must be to enable the project to progress even if this risk occurs and to minimise the impact on the project schedule at the same time. In other words, to have a realistic “plan B” that you can implement in a timely manner, by not simply waiting until this risk occurs to then work out what you are going to do. I do not call that “business as usual”.
In terms of how you identify the probability, I would talk to the body who grant the licence or if this is not possible I would use whatever information I can find to make the assessment. In terms of this assessment, the probability is useful but impact is far more important.
One cannot write a risk for every milestone and/or parent requirement that may not occur. Risks rather should be written to reflect a new and/or known cause and/or event that is a critical sequential element in a process, say for licensing. In Government contracting, if a license is not granted is too high level a risk. If due to new and/or classified technology a license may not be granted, that results in no license being issued. The risk is truly the cause and/or event, not the outcome.
thanks Joe – I agree the real risk is cause/event and not the outcome. Many people incorrectly describe the outcome (or consequence) as the risk itself. This can cause many risks to go un-managed.
Does the “Threat” part of S.W.O.T . lead into or is related to “Risk” . I have been involved in several projects where we did boths, and there was great overlap – or more accurately every Threat in the SWOT was in the risk register. The way we worked is that each discipline took ownership of risks/threats in there domain – safety, environmental, production, maintenance, personnel and accounting. The VP of operations owned the process of coordination and quality – ensuring that the mitigation of a risk (in one area) did not create a risk (in another area).
Hi Charles and thanks for your comment. Any “model” or thought process that helps to identify risk (threats) is potentially useful. People often find the “identify” stage the hardest to do, so if this works, then great.
You have good information here and this is just my two cents. What I find missing in many risk descriptions and instructions for writing a risk statement is the context for the risk. A line or two that provides background or information needed to understand the circumstances of the risk. This is also important information needed when writing the response to the risk and, for the reader, to help relate the response to the risk. As a risk management practioner, one of my challenges it to help programs to write risks that are clear and can be understood by leadership who will be making decisions about programs. Too often programs are told to write if/then statements and nothing else but the if/then statements alone do not always provide information needed to understand the context of the risk that provides important information.
Hi Pat – many thanks for your comment and I agree it is very common that risks, even when they are real risks, are very often poorly described and defined. This leads to many bad things like: poor understanding of the risk by wider stakeholders; wrong response actions being taken and more.
I assume the answer is no, but should all risk statements be if/then? Also, I can’t get over my confusion of what to assign the probability to. Example (good or bad?): if I define test x, the equipment will not pass the test.
James – I would say the answer is quite possibly yes (“if?”) in that risk should always contain uncertainty. As far as the probability is concerned it should be the best judgement of a group of subject matter experts, saying for example, if we try this 10 times how many times would we expect this (risk) condition or event occur?
Question: 1
how to Develop practicable strategies on the ways in which an organization can assess hazards and risks following changes in an organization’s management, processes or equipment…..?
Your work is generally excellent and I value you and jumping for some more educational posts