Example Project risks – good and bad practice:
Firstly, poor examples: from page 1 of the world’s favourite search engine
Projects always carry risk. 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 key words 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 possible 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 – not a risk. This example is 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; 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 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 for 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 likelihoods of the risk occurring (where possible), and (always) its consequences should it still occur. That is real management of risk on projects.
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?
- 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”.