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 exhibits uncertainty.  If you review the content of risk registers in many businesses you will see lots of items that don’t fit this definition.  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 risk.

Later in this post, we share multiple valid risks.

Project Risk Management Process

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):

  1. 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.
  2. 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.
  3. Project estimates are very optimistic”.  Once again, this is a statement.  Assuming it is true, it is an issue, not a risk.
  4. Poor data quality”. This is no more than a totally unqualified statement. Period.

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 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 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.

Basic definition of risk: “chance of danger” are the key words

So let’s look a little closer at what risk acutally is.  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 – 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 confuses people – a great deal.  The term ‘positive risk’ is a 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 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 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 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?


  1. 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”.

Share this:

  1. Bill Bagins on March 13, 2018 at 3:45 pm

    “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?

    • Kevin Lonergan on March 13, 2018 at 4:01 pm

      Bill – this is a classic risk that cannot simply be accepted (or even worse ignored). If this is a genuine risk, a contingency plan may be required. I do not see how “business as usual” solves the issue that would occur. The aim of risk management must (partly) be to enable the project to continue, as far as possible, should known risks occur. With regards 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. This may not be possible in all cases but there would be many where it would.

  2. Joe Yuna on June 28, 2018 at 6:24 pm

    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.

Leave a Comment

Contact Us Now

Email us today to find out more on how we can help you.

Invalid Email
Invalid Number

Subscribe to Blog via Email

Enter your email to subscribe to our blog and get notifications of new posts by email. (We don't SPAM - ever.)

We use cookies to give you the best experience on our website. We do not store or collect any user data.