Project Risk and Risk Management

October 15, 2009 | Author: PM Hut | Filed under: Risk Identification, Risk Management, Risk Quantification & Analysis, Risk Response & Control

Project Risk and Risk Management
By David Litten

Whenever we undertake a project, risk is inevitable, since projects enable change - and whenever you have change, it introduces uncertainty and hence risk.

A risk is defined as an uncertain event which should it occur, will have an effect on the project meeting its objectives. These uncertain events can be positive in which case it would be called an Opportunity, when negative it is called a Threat. Both have the common thread of uncertainty.

When carrying out risk management, the purpose is to reduce the probability and impact of threats and to increase the probability of opportunities and/or their positive impact. It is helpful to consider that risk is “an event that may all may not occur in the future, but if it does occur it will have an impact on the project objectives“.

The Business Case will contain information weighing project cost and risk against the business benefits. Put simply, that the aggregated project risk is worth the benefits. If this is so, then the Business Case remains viable, desirable, and achievable. This one fact highlights the importance of proper risk management. Whenever a new risk is identified, an existing risk changes its characteristics, an issue is identified, or at important control points such as end stage assessments — the Business Case should be checked for viability — and this includes the aggregated value of all of the risks.

Effective risk management entails clearly identifying each risk, and estimating it in terms of its probability and impact and controlling it by taking appropriate action and ensuring such actions have, and continue to have, the desired effect.

Before getting into the details of risks, a project must determine the Risk Management Strategy which describes how risk management will be both used and implemented within the project. The risk management strategy should include, amongst other aspects:

  • particular tools and techniques to be used
  • the responsibilities for risk management actions
  • the procedure for risk management, such as Identify, Assess, Countermeasures/actions, implementation and communication
  • the scales to be used for calibrating and estimating probability and impact
  • the reporting and timing of risk management activities, such as at the end of each project stage
  • the risk categories as to be defined, the action categories, definition of risk proximity, and risk trigger indicators
  • for contingency or fallback actions, a risk budget should also be agreed. This budget is used to pay for any such risk actions should they be needed.
  • when using management by exception, the risk tolerance or “risk appetite” should be agreed between the project manager and the project board.

It is worth discussing that last bullet in more detail:

Tolerance is an allowable variation of typically time and cost that the project manager can “use” to allow for small deviations and estimating errors. Should at any point, the project or stage be forecast to exceed this tolerance, the project manager must escalate the situation up to the next level of management - who need to make a decision on what to do next.

However, the tolerance used may be risk tolerance. In such case, discussions should be had between the project board and project manager, about how much risk can be tolerated (”risk appetite”). Factors such as particular risk impacts increasing beyond a particular value, or their probability increasing in the same way. It might be risks under a particular category - such as those affecting corporate image, that may be the escalation triggers.

The Risk Register should be created early in the project, and used to capture all details and the status of each risk identified. The project manager is responsible for ensuring that risks are managed properly but there will be the need for risk owners for all risks, and these owners may be other people involved in the project. They should be chosen as the best person to keep an eye on the risk. The owners may be the person required to implement risk action, or to act as a “forward scout” to report risk status back to the project manager

The first step in the risk management procedure is to identify the risks, and this is normally done within a risk workshop. Other useful sources of possible risk identification, is to review lessons from previous projects. Yet more sources include organisational risk checklists, or the use of industry-wide checklists or tables.

Many people make the mistake of naming risks such as ” there is a risk is that the project may come in late” — but this is a mistake, because the statement is not naming the risk itself, but its impact. This is where “Fish-bone” or Ishikawa Diagrams can be useful in separating the risk event, it’s cause, and the effect (the risk impact)

It is helpful to consider that the source of the risk is called the risk cause (the potential trigger points for each risk), the risk event describes the area of uncertainty, and the risk effect which describes the risk impact on the project objectives.

The next step is to estimate and evaluate each risk, and there are various estimation techniques that may be used:

  • Probability trees. These are diagrammatic representations of possible risk events shown as linked rectangles each with a probability and impact. When linked together, the aggregated value of project risk can be determined. These help the decision-makers to determine possible outcomes, and ensures suitable actions can be implemented.
  • Expected value. This technique multiplies the cost of the risk impact with the probability of the risk occurring. For example, if the cost of a risk was £10,000, and the probability equal to 40%, then the expected value would be £ 4000. Summing all of these expected values together will give the aggregated risk expected monetary value of the project. This is helpful in determining a potential Risk Budget.

  • Pareto Analysis. This is often called the 80/20 rule, from the observation that 20% of the risks will have the most impact on a project, and allows management to focus their attention on managing and controlling those risks. It gives the best “Risk ROI”.

  • The probability impact grid. This is a table with the vertical axis scaled in probability and the horizontal axis scaled in impact. Suitable scales are determined, typically 10% probability, as very low through to very high between 70 to 90% of ability. The impact scale usually covers from very low to very high. The grid is used to provide an assessment of the severity of a risk and so enable risks to be ranked such that management effort can be prioritised.

  • The summary risk profile. This again is a grid of probability against impact, but instead of measuring the severity of each risk (probability times impact), it plots each risk as a number much like a scatter diagram so that the spread and severity of risks can be directly seen. For example any risks which have a very high impact and probability would be seen as severe threats and this will enable appropriate actions or counter measures to be determined.

The next step is to plan the appropriate responses, both for threats and opportunities. There are many ways to describe such actions, but the following are most often used:

For Threats:

  • Avoid. An action is planned for the project to do something different, such that the threat can either no longer have an impact on the project and/or its probability is zero.
  • Reduce. An action is planned to either reduce the probability of the risk occurring, and/or to reduce the impact of the event should it occur.

  • Fallback (often called Contingency). An action is planned but only implemented should of the linked risk occur.

  • Transfer. An action is planned that reduces the financial impact of the threat. Usually, the action is via some form of insurance, or an appropriate clause in a contract so that the other party bears the financial pain.

  • Accept. This is the “take no action” option. The threat should still be continuously monitored to ensure that it remains tolerable. This action is often chosen because the risk has a low probability and/or a low impact, or that the costs and effort of any actions outweigh the severity of the threat.

Threat or Opportunity:

  • Share. Often carried out within contracts using third parties, where a pain/gain formula is agreed should the threat or opportunity occur

Opportunities:

  • Exploit. Taking action to ensure that the opportunity will happen and that the positive impact will be realized.
  • Enhance. Taking proactive actions which either enhance the probability and/or the impact of the event.

  • Reject. A decision taken not to exploit or enhance the opportunity.

All of the above actions are captured and entered within the risk register, and project or stage level plans have the above activities and resources added.

It is helpful to include the proximity for each risk. This is the time frame of the risk event occurring from the present day. This is helpful in focusing resources on actions for risks in the near future. But it is also helpful in determining when each risk event will occur, as this will have an effect on the severity of the impact.

Throughout a project, new risks can be identified, and existing risks can change their status — for this reason risk management should be seen as an ongoing activity throughout the entire project. It should also be remembered that as issues arise, these can in themselves impact existing risks or cause new risks.

At the end of each stage of a project, the total risk situation needs to be calculated, and used as part of the data for management to make an informed decision as to whether to proceed with the project or not. At the end of a project, as part of closure, any outstanding risks which would therefore have an impact on the end product’s operational life should be found a new owner, so that such risks can continue to be successfully managed and controlled.

Dave Litten’s got more great information like this. If you need, “Preparation For Prince2 Exams“, Dave’s site is the place to be. His Prince2 Primer comes free with both a full strength Foundation Exam and Practitioner Exam - and is taking the world by storm. Grab your FREE copy of his PRINCE2 Flash File Summaries today… and you’ll be on the Fast-Track to a successful Exam Pass Grade!

Share this article:
  • Facebook
  • LinkedIn
  • TwitThis

1 person has left a comment

My experience suggests one of the primary reasons for these continued poor project results is the lack of formal, aggressive IT project complexity and risk assessment and management – a responsibility of the IT project sponsor and project manager.

Software development is a process – a process with varying degrees of complexity. A process’s complexity, therefore, defines, qualitatively and quantitatively, the relative difficulty, time consumption, resource requirements and skill requirements necessary to successfully complete. The more complex the process – the more difficult, time consuming, resources intensive and more experienced skills are required. Many project managers use complexity and risk synonymously – but they are not. Project risks are qualitative and quantitative issues or events which could lead to negative consequences. Risks can be prevented, repaired if they become an issue or mitigated. Complexity is not an event and is harder or impossible to prevent, repair or mitigate once the IT project begins.

So why do most IT sponsors and project managers do a lousy job of complexity and risk assessment and management? A few reasons are:

1.Lack of skills – training and/or experience
2.Internal politics
3.Lack of formal assessment and management process that is consistent and repeatable
4.Lack of assessment, management and reporting tools
5.Lack of emphasis in CMM, ITIL and other methodologies

Ross Holman wrote on January 29, 2010 - 2:30 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories