Example Project risks – good and bad practice:
Firstly, poor examples: taken from page 1 of the world’s favourite search engine
Projects always carry risk. If you search online for “example project risks” there are many extremely poor examples especially 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 part of this statement is “if it occurs”. In other words, true project risk carries uncertainty. If you review the content of risk registers in many businesses you will see lots of items that do not fit this definition. For example: if we do something poorly and its results are ‘unfit for purpose’, that is not uncertainty, it’s simply poor execution. Items like ‘requirements don’t match the user’s needs’ should never be in a risk register, as it’s an issue not a risk. Another example is if we have poor confidence in any process, we must fix it, not issue warnings about it in a risk register. Later in this post we describe valid risks.
Actual Poor Examples: (all taken from page 1 of Google in Dec 2015)
The following are typical 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. Every item of risk must identify the uncertainty that gives rise to risk. This example is an issue, not a risk.
- “The project may be late”. This example may seem to get closer 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 an un-qualified statement. Period.
The above examples are 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 an event that may occur in the future which would be a problem if it does.
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 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.
Basic definition of risk: “chance of danger” are the key words
So let’s look a little closer at what risk should be. The Oxford Dictionary definition of the word “risk” is “exposure to the chance of danger “. There are two key words in this statement: “chance” and “danger”. “Chance” in the context of projects means significant uncertainty and “danger” is negative – some form of negative impact which brings us to another key distinction. Opportunities should be recognised but should never be classified as risk, as the PMI’s PMBoK also declared in its 2013 update (1). Risk is negative and opportunity is positive. Mixing them together in the same discussion confuses people – a great deal.
Good examples of 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 a 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 are 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 management of risk on projects.
Want to improve how risk is managed on your projects?
- Footnote – PMBoK backing-out of 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”.
Contact Us Now
Email us today to find out more on how we can help you.