Category Archives: Identifying Risk

Four Types of Risk

I have been reading an old blog about “Epistemic, Ontological and Aleatory Risk” on Mathhew Squair’s blog, Critical Uncertainties.  I doubt I am alone in having to think hard to get my head around the definitions.  So, to help myself, I made a diagram.

There is a lot to think about in Matthew’s article and it stimulated a lot of parallel thoughts. The summaries and interpretations in this diagram are all mine, but it owes a lot to Matthew’s article.

Four Types of Risk

Advertisements

The Ten Strategic Risks that Cause Projects to Fail

Project failure seems to be almost endemic at the moment. There are frequent press reports of massively over-spent Government projects, and major commercial project delayed or cancelled. Anyone who works in a big organisation will have seen it up close, so let’s look at ten of the commonest reasons why projects fail. Each one is strategic, predictable and, most important can be avoided.

Risk 1.

The project goal and objectives are either unclear, or are disconnected from the organisation’s other priorities, leading to a weak case for change. This is really two reasons for the price of one.
Strategy: Invest time up front getting a strong definition signed off by strategic level managers.

Risk 2.

People have unrealistic expectations, leading to a determination of failure despite the project meeting its goal and objectives. Stakeholders will always have the last word on success or failure.
Strategy: Prioritise stakeholder management at all stages of your project.

Risk 3.

Senior people in leadership roles fail to accept responsibility for the project, and do not give it the support, commitment and leadership it needs. This often leads to an over-reliance on consultants or contractors.
Strategy: Unless you have clear and committed sponsorship, fold the project now.

Risk 4.

People resist the changes that the project brings or resist participating in the process, often because their role in the project’s success is under-valued by the team. Rule 1: people resist change. So what will you do about it.
Strategy: Plan time into your programme to engage positively with the inevitable resistance.

Risk 5.

Project management, change management, stakeholder management and risk management skills are lacking. Often, functional managers are co-opted into project management roles with little or no preparation.
Strategy: If you can’t secure experienced project managers, provide high levels of training and support.

Risk 6.

The project is poorly planned, without a sound basis for estimates of schedule and resources, leading to unrealistic deadlines or budget. And worse still, project managers believe their plans too early, with little or no supporting evidence.
Strategy: Stress-test your plans and never consider them complete without full risk mitigation and contingency plans included.

Risk 7.

Key elements of the project are not controlled effectively, such as changes to scope or functionality, delivery or quality of products, or deviations from plan.
Strategy: A robust change control process is necessary in all but the simplest projects.

Risk 8.

There is too much focus on cost – or price of contracts – and not enough on the balance between cost and risk/value. Value for money means understanding the risks and benefits, not just the costs.
Strategy: Always ask why low prices are as low as they are. If it seems too good to be true, then it probably is.

Risk 9.

A project solution is defined before adequate research has validated that is technically possible, organisationally desirable, and free of unintended consequences. We are too often seduced by the lure of the novel and innovative. New plus original equals big risk.
Strategy: Prototypes, pilots and extensive testing are not gimmicks but sound risk management tools.

Risk 10.

Project overload – the organisation is simply trying to do too much with the resources and attention that it has available. Many organisations don’t fail because they don’t manage projects well, but because they try to manage too many.
Strategy: Ruthlessly prioritise your initiatives and cull those which offer poorest value.


Risk Happens! by Mike ClaytonEach of these threats is fully addressed
in Dr Mike Clayton’s new book,
Risk Happens!

See www.riskhappens.co.uk for details.

Buy it in paperback from Amazon here,
or in Kindle format, here.

Risk Potential Assessment

The UK Government’s Major Projects Authority (MPA) has published its Assurance Toolkit with a particularly useful risk management tool.

Risk Potential Review

A Risk Potential Review (RPR) is a structured analysis across the various aspects of your project, to gain an overall measure of the risk involved.  It is a valuable part of the first, definition stage of your project.  Typically, bigger, more complex, higher impact projects carry more risk than smaller, incremental, operational projects.

Table 4.2 of Risk Happens! offers you a checklist of typical considerations for a Risk Potential Review.  It covers things like:

  • Sponsorship
  • Requirements
  • Scale
  • Impacts
  • Constraints
  • Dependencies
  • Capacity
  • Capability
  • Novelty
  • Stakeholders

Assigning threat levels against each question in my checklist will give you a simple numerical assessment of the potential threat level of your project.  You can download a copy of the Risk Potential Review checklist here.

Risk Potential Assessment

If you need a more thorough evaluation of the impact of project failure, and the complexity of your project, the MPA’s Risk Potential Assessment worksheet in Word format is a great tool for your project toolkit.  And, you can re-use it free of charge.  You may disagree with the final assessment categories in Table C, but the questions are useful at the start of any project.

MPA Risk Potential Assessment (© Crown Copyright, May 2011)

The “so what?”

I recommend you download this tool, adapt it to your own domain, and have it ready for the start of your next project.

PM Student

Josh Nankivel is running a competition to win a copy of Risk Happens! at PMStudent.com, where you can read my article: “Why every Project Manager Needs to Understand Risk” 

Sign up for my monthly newsletter

Just let me know your name and email address, and I’ll send you valuable extra tips and thoughts every month.

 

Conduct a Pre-mortem

Gary KleinOne of the most interesting areas of management performance to me is decision-making.  And one of the most interesting writers on the subject is Gary Klein.

His principle research interest is in how to use intuition effectively, which led to some of his work being described in Malcolm Gladwell’s huge-selling book, “Blink”.

One of the tools that Klein has developed is what he calls the “pre-mortem” exercise.  This is a technique that should be familiar to all project managers.

The Pre-Mortem

In a post-mortem, we look at the tattered remains of a failed project and try to figure out what went wrong.  In a pre-mortem, Gary Klein suggests, we should imagine that our as-yet un-started project has failed failed spectacularly.  With this assumption as a starting point, we then proceed to figure out what might have caused it.

A Shift in Perspective

This is different from the more familiar risk identification process, where we try and think of all of the things that can go wrong.  Notice what this shift in perspective from “what could go wrong?” to “what has gone wrong?” does.  One of the biggest sources of failure of a project is over-confidence.  We have too much faith in our team, our assumptions, our planning, our execution capability.  This blinds us to many potential sources of failure.

In the pre-mortem process, we can skip past this by starting with the presumption that the project will fail.  It team members can be made to think that this has happened, then they will work hard to find explanations for the failure and, in so doing, will unearth all sorts of risks.  By now it is too late to say: “but that could never happen” because we have entertained the real possibility that it might.

Risk Happens!

Risk Happens! by Mike ClaytonAccessing personal experience is one of six approaches I offer for identifying risk, in “Risk Happens!”  The pre-mortem is one the techniques under that heading.

To learn more about the pre-mortem, read Klein’s book The Power of Intuition”.  Fast Company and Harvard Business Review carry articles that discuss Klein’s work and the technique, on their websites.

The “so what?”

Break the cycle of assuming your project will succeed and thinking risk management is just about dealing with the frustrations along the way.  Start looking for the hidden “unknown knowns” that will cause it to fail, if you don’t find them and tackle them.

Sign-up for my free email newsletter

Try it out… you can always unsubscribe later.

The DCMA 14 Point Schedule Assessment

I like checklists.  Well constructed, they give confidence and a logical structure to our analysis.

So I thank Glen Alleman (again) for making me aware of the Defense Contract Management Agency (DCMA) 14 Point Schedule Assessment.  The DCMA is a Division of the US Department of Defense (DoD) and their assessment is a checklist of 14 components of a project schedule, with criteria to indicate where that schedule may be weak or strong.

It is clearly well thought-out for theDCMA’s domain, and may not be wholly apporpriate to other project contexts.  For your project, it may miss some checks, some of the checks may be less valuable, or some of the levels at which the assessment fails may be inappropriate.

But surely, a rigorous assessment of your schedule using an assessment tool like this is of great value to any project.  I commend it to you.

The 14 Points of Assessment

I am indebted to Ron Winter Consulting and Mohamed Hegab writing on the ICPM Blog for getting me up to speed on this.  Refer to the links below for more information.  This is my summary of what I learned from them:

Review your project schedule against these 14 items:

  1. Logic Check
    Dependency relationships
  2. Leads Check
    DCMA deprecates leads (negative lags) you may want simply to assess each on its own merits
  3. Lags Check
    Too many lags (5%) flags a risk
  4. Relationship Types Check
    Expect most dependencies to be “finish-to-start”
  5. Hard Constraints Check
    Too many fixed dates in your schedule creates risk
  6. High Float Check
    Too many tasks with high (DCMA uses 44 days) float suggests poor logic or control
  7. Negative Float Check
    Ron Winter’s paper gives examples of when, counter-intuitively, negative float may be appropriate, but DCMA deprecates it and it must, at the very least, ring big alarm bells
  8. High Duration Check
    Long duration tasks and the risk they pose is a hobby horse of mine.  DCMA again choose 44 days.  I deprecate any task exceeding 10% of remaining project duration (except, of course, in the final months!)
  9. Invalid Dates Check
    A simple logic check on stated dates
  10. Resources Check
    Are the tasks properly resourced (and budgeted, I would add)
  11. Missed Tasks Check
    Have tasks been dropped from one version of your schedule to another?  If so, this could suggest erroneous omission.
  12. Critical Path Test Check
    Does the software correctly handle extensions to critical path activities?
  13. Critical Path Length Index (CPLI)
    My reading of this is that it is another check that remaining float on the CP is positive
  14. Baseline Execution Index (BEI)
    This is a check on progress to date against baseline

For far better informed discussions, see:

The “so what?”

If you are not reviewing all elements of your planning critically, then as a project manager, you are subjecting yourself to hubris, you are exposing your project to additional risk, and you are, arguably, falling down on your job.  Adapt the principles of this check to your needs, but do carry out a review.

Risk Happens! by Mike Clayton“Risk Happens! Managing Risk and Avoiding Failure in Business Projects” is published on 15 July.  Learn more, on the Risk Happens! website.

Sign up for Mike’s monthly newsletter

Just let me know your name and email address, and I’ll send you valuable extra tips and thoughts every month.


The Project Risk versus A Project Risk

“How risky is this project?”

Well, it’s…  you know, there are lots of risks.

A Gap in our Methods

I am not convinced that we have a satisfactory way to answer the question “how risky is this project?” We can evaluate all of the project risks and add them up and, without a doubt, this gives us a measure of a project’s risk.  The problems with this approach, however, are legion.  Let’s just pick two of the most obvious:

  1. If there is an estimating error in our assessment of each project risk (and there will be), then what is the chance that these errors will cancel each other out?  Probably quite low – we might expect a random walk away from the true answer, as long as our estimating errors are truly random, rather than systematic.  A lot of “ifs”.
  2. Where do we stop.  We have an infinite series of finite risks.  Some are small, but where do we set the cut-off?

Continue reading

A Fishy Approach to Risk

One of the joys of my working life is doing something innovative.  So to be asked to develop a three module course on Problem Solving and Decision Making was great, and our client, SAP, is a great company.

But it’s better. This work gave me a chance to learn how to develop training for a virtual classroom.  Up to 16 participants around the world, learning with one facilitator, using great technology.

This is all beside the point

The point is this: running today’s module, on analytical methods, we covered a great problem solving tool which I also use for risk management.  I suspect many change leaders, and project and risk managers will have heard of it – but never thought to use it in their risk management process.

I am talking about Fishbone Diagrams

AngryFishSkeleton

Photo by Johnath

.

.


.

Fishbone diagrams are used to find root causes and are formally known as the Ishikawa Method.  This tool is ideal for getting to causes.

We draw a fishbone diagram, putting the problem at the head of the fish.  We then identify all of the possible causes and place each onto a “rib”. In the example below, here are eight typical sources of a problem.

Fishbone Diagram

We might then break each one down further, identifying different reasons why the hardware, data, processes or skills might cause the problem.  With “skills”, for example, the cause could be lack of training, inappropriate training, poor workplace support for developing skills, or poor motivation to use the skills.

How does this apply to Risk Management?

When we are identifying our risks, we often end up with a load of risks that are hard to manage, because they are poorly specified.  They are big and nebulous, because they are really not one risk at all: they are a basket of other, more specific risks.

Here are some examples:

  • When we move HQ building, there is a risk we won’t be able to sell the old property
  • There may be a technical problem with the AV equipment at the conference we are organising
  • Our new product launch could be delayed by problems with the point of sale materials

All of these are real concerns, but each is the outcome of many individual risks.  By writing the concern into the fish head, you can then use your fishbone diagram to identify potential causes of the outcome.

Each of these causes is a risk that you can manage: each will have its own likelihood, impact, proximity and mitigating strategies.

The “so what?”

Don’t accept risks onto your risk register that you cannot manage, because they are too woolly or general; focus your risk management on causes, not outcomes; try out the fishbone method as a way to find causes in your risk analysis.

Kaoru Ishikawa

.

Read more about Kaoru Ishikawa,
inventor of the Fishbone Diagram.

.