Risk Management
Site: | Saylor Academy |
Course: | BUS402: Project Management |
Book: | Risk Management |
Printed by: | Guest user |
Date: | Saturday, September 7, 2024, 7:47 PM |
Description
Read this article, and pay attention to the section on attitudes toward risk. Think about your industry. Is it risk-averse or open to taking smart risks? What about you, personally?
Risk Management
What is risk management?
Risk management is an essential part of good management practice and features prominently on the agendas of senior managers and education bodies. Whilst risk management applies to all areas of organisational activity its relevance is particularly clear in relation to projects, particularly projects with an IT or systems component. It is probably fair to say that risk management is the single most important component of project management.
Why is risk management important?
Risk management is fundamentally about making better decisions. In education, as in any other environment, you can't decide not to take risks: that simply isn't an option in today's world. All of us take risks and it's a question of which risks we take. This guide will help you evaluate your own approach to risk and give you some practical suggestions on how to manage the risks you do take.
How can we manage risk?
By understanding what 'risk' means, the spectrum of differing attitudes towards risk, and a basic process framework for managing risk, we can not only mitigate against unwanted risks but turn challenges to opportunities. This resource covers some basic ground rules and approaches, and provides some templates to get you started and enable you to tailor the approach to be fit for your purposes.
Definitions of risk
In most project management methodologies, risk tends to be viewed in a very negative sense. It is generally defined in terms of something that might occur to adversely affect you achieving your goals. Here we'd like to broaden that definition out a little and suggest that risk may not always have an adverse impact.
Let's just say that risk is not necessarily something going wrong – it is simply something turning out differently to how you expected or planned for. This view allows the possibility that risks can be turned into opportunities if managed effectively.
To be a bit more specific, risk is: 'A future event (or series of events) with a probability of occurrence and the potential for (a) loss or (b) impact on objectives that can be either positive or negative.' It is therefore more accurate to say that this guide is not just about risk management rather it is concerned with risk and opportunity management.
Source: Jisc, http://web.archive.org/web/20160201194134/https://www.jisc.ac.uk/full-guide/risk-management This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 2.0 License.
Attitudes to risk
The concept of risk is essentially a modern one. In ancient and mediaeval societies the idea of risk management would never have arisen and fortune was attributed to luck, fate or 'acts of God'. Giddens has demonstrated that the concept of risk is now central to our society and he defines risk as being different to danger or hazard in that it is related to our impact on our environment and stems directly from the consequences of our actions on the world.
The term risk was introduced by Portuguese explorers who identified uncharted areas of sea as 'risky'. The term has gone from having a spatial meaning to its current temporal meaning whereby risk relates to future events.
Such a concept could only have arisen in a society bent on controlling the future. Giddens also stresses that the notion of risk is positive as well as negative and cites the example that the whole rationale behind western capitalism is based on the calculation of future risk.
We will look at some simple mathematical concepts that can help you introduce a certain amount of objectivity into the risk management process but first it is important to think about how we perceive risk as individuals and organisations. Risk management is about taking decisions and, however much we may formalise the process, decision-making is a very emotional business.
Our approach always stresses that projects are about people and nowhere is this more evident than in approaches to risk. Whenever someone is required to take a decision their evaluation of the options open to them is coloured in terms of:
- Personal/corporate wealth
- Attitude toward risk taking (risk taker/risk averse)
- Previous experience.
We are also affected by whether the decision is likely to result in a major gain or loss. The possibility of gaining increases a person's appetite for risk taking eg, someone may bet on a horse or buy a lottery ticket because their emphasis is on winning. Anxiety about suffering a loss, on the other hand, increases risk aversion but this may not always result in the anticipated behaviour.
A model known as 'Prospect Theory' states that you are likely to take a risk rather than suffer a sure loss. An example of this is investors in the stock market who continue to gamble in a falling market rather than take a sure loss immediately.
In determining which option an individual will take the concept of utility (u) is a useful one. Let's take the simple example of buying a lottery ticket (option A) or not buying a ticket (option B). Someone badly in need of money will have a high u value for option A which may result in a win and a low u value for option B where they have little to gain other than the sure £1 in their pocket.
We do of course view risks differently depending on how directly the consequences affect us. Somebody contemplating laser surgery to correct their vision is likely to focus on the downside risks whereas their friends may focus on the opportunities and encourage them to go for it. To take another example what would be the u value to you of a decision that resulted in your pet project being scrapped?
The emotional element in decision-making is highlighted by a famous mathematical problem known as the Monty Hall dilemma. Monty Hall was the host of an American game show where the winning contestant had to select their prize from behind one of three closed doors. Behind one of the doors was a car and behind the other two were goats. The contestant would pick a door and Monty Hall (who knew what was behind each door) would open a different door to reveal a goat.
At this point the contestant would be offered the chance to stick with the door s/he had chosen or to switch. What should they do?
The answer to the Monty Hall dilemma is that, based on purely logical, mathematical reasoning, it is better for the contestant to switch doors (assuming of course that they want to win the car). The contestant initially had a one in three chance of picking a car. If they stick with the same door those odds don't change. However, now that one goat has been revealed, if they switch doors there is a two in three chance that their second choice will win them a car.
Human nature however encourages us to stick with the first choice. This is for the simple reason that we don't want to look foolish. If you have changed your mind and then selected the wrong option the embarrassment factor is far greater than if you simply chose wrongly in the first place.
The emotion and politics involved is compounded when it comes to organisational decision-making. Making choices exposes you but committee structures can mask this and help avoid individual responsibility. Of course the situation is compounded by the fact that not all of the players involved will have the same utility value for each option.
It pays to have an overall understanding of your organisation's culture and attitude to risk. The risk tolerance of an organisation will lie somewhere on this spectrum from risk-averse to actively risk-seeking.
![](https://learn.saylor.org/pluginfile.php/5749370/mod_book/chapter/58483/risk-attitudes.png)
Many organisations lie towards the risk-averse end of the spectrum and view risk as something to be avoided at all cost whereas leading edge and entrepreneurial companies see the opportunities to be found in a high-risk environment. The risk-averse mind set often results in the expectation from senior management that a Project Manager's role is to remove risk. This is not the case. Managing risk is not the same as removing it and risk management is undoubtedly easier in the right type of supporting culture.
Management attitudes and principles
Let's take a look at some of the management attitudes that run counter to effective risk management and indeed themselves introduce risk to a project.
Attituse | Impact |
---|---|
Extreme risk aversion | Procrastination in decision making. This often means that some possible options/opportunities are no longer feasible. Setting risk threshold of acceptable activities so low that the organisation is incapable of change. |
Pass the buck | Related to the above. Inability to reach closure on difficult decisions. Issues discussed regularly by a range of committees without progress. Decisions not documented and followed through. |
No news is good news | The belief that a project manager causes a risk or an issue simply by reporting it. Encourages people to report only good news. Often risks/issues aren't noted until it is too late to deal with them effectively. |
Knee-jerk reaction | Tendency to deal with symptoms rather than causes and to deal with the immediate and specific rather than the systemic.* |
My minds is made up | Inability to review or reverse past decisions in the light of changing circumstances. |
Shoot the messenger | The 'Don't bring me problems' approach. Inability to cope with the identification of risks that don't have an obvious solution. |
Make it so | 'Don't be so negative'. The belief that a poorly conceived or inadequately resourced project can be made to succeed by sheer force of will. |
*There is a mathematical phenomenon known as 'regression to the mean' that is relevant to the management of change and hence the sort of situations we are looking at here. It states that in any change situation, such as a project, there will be ups and downs. This could be represented as a graph.
Where the project reaches its lowest ebb, as indicated on the diagram, management often takes a reactive 'knee-jerk' decision. This invariably addresses a symptom not the root causes of the problem. For a while it may look as if the 'decisive action' has worked as the graph starts to go up again. What is actually happening is simply regression to the mean. The situation had got as bad as it was going to get and would have begun to level out whatever happened.
We will look in more detail at how to build risk or 'real world' scenarios into plans, suffice to say here that mature organisations must accept risk as an integral part of project activity. Risks must be identified and managed and we must accept that this takes time and costs money.
We can't simply blame 'bad luck' when things happen unexpectedly, at the worst possible moment and cost money we don't have. Risk management is about identifying what could occur and developing a planned response that is factored into the project plan and budget.
Essential management principles
Carnegie Mellon University Software Engineering Institute has a useful website on risk. It has identified seven management principles essential to effective risk management and the following table is adapted from those principles:
Corporate perspective
- Viewing developments within the context of strategic goals
- Recognizing both the potential value of opportunity and the potential impact of adverse effects
Forward-looking view
- Thinking toward tomorrow, identifying uncertainties, anticipating potential outcomes
- Managing project resources and activities while anticipating uncertainties
Open communication
- Encouraging free-flowing information at and between all project levels
- Enabling formal, informal and impromptu communication
- Using processes that value the individual voice (bringing unique knowledge and insight to identifying and managing risk)
Integrated management
- Making risk management an integral and vital part of project management
- Adapting risk management methods and tools to a project's infrastructure and culture
Continuous process
- Sustaining constant vigilance
- Identifying and managing risks routinely through all phases of the project's lifecycle
Shared vision
- Mutual vision based on common purpose, shared ownership and collective communication
- Focusing on results
Teamwork
- Working co-operatively to achieve common goals
- Pooling talent, skills and knowledge
In considering the above principles it is interesting to note the observation from Carnegie Mellon University (op cit) that
While there are no prerequisites to performing risk management, it is more effectively practiced by organizations or projects which have acquired some degree of maturity.
A five step risk management model
'Risk management is a systematic process of identifying, analysing and responding to project risk'. This may be broken down into a number of sub-processes are used as the basis for the five-stage model in this guide:
- Risk identification
- Qualitative risk analysis
- Quantitative risk assessment
- Risk response planning
- Risk monitoring and control
A precursor to all of this is risk management planning in which you identify the overall approach to be taken to risk management. Where you have a developed project management framework you may have an organisation-wide approach that is adapted as necessary for each project.
We stated earlier that risk is inherent in everything that we do and that risk management is simply helping us to take better decisions. In plain terms risk management is helping us run projects in the 'real' world. Too often plans are formulated on the basis of an ideal situation where everything goes according to plan. This may be a result of naivety, optimism or what we term 'macho management'.
By this we mean a push for what a manager sees as the ideal without taking account of the risks involved. This manifests itself in pressure to prepare and 'freeze' plans too quickly and pressure to deliver too early. This usually means skimping on the analysis and planning phases of the project.
Senior managers may push project managers to have a more 'can do' attitude but this is merely shifting responsibility. If a project manager undertakes an analysis and comes up with a justifiable and realistic estimate of timescale and costs then one or other is cut, the senior manager responsible must bear the blame when the budget is exceeded or the project overruns. Similarly any project requires adequate scoping and definition but organisations don't like this overhead.
As learning organisations we are notoriously reluctant to fund thinking and planning time. Once again, senior management must take responsibility for project failure where the initiative was poorly conceived in the first place.
Identifying risk
Identifying risk
Risk identification is of course the first step in managing risk but it is an area that brings to the fore all of the emotional baggage discussed earlier. The very mention of risk can raise senior managers' blood pressure by a few points.
It is obvious that if you don't think about the possibility of something occurring you can't act on it and plan for it but risk identification is a good example of the 'shooting the messenger' syndrome we noted earlier. In immature organisations, or those where a 'blame culture' is prevalent, a project manager can be treated as if s/he caused a risk just because they highlight its existence.
At the risk of labouring a very obvious point you don't create risks by identifying them. You are simply revealing them so that you can do something about them. In many cases the risks may relate to organisational strategy, to key decisions already taken or to other things that are going on within the organisation and it may be uncomfortable for senior managers to see some of these issues brought into the open. There is no way round this.
We need to raise awareness of risk management techniques and create risk robust cultures within our organisations if we are to run successful projects. It is assumed that you are using a structured project management methodology and this will provide a range of information sources to help you identify areas of risk.
If you are unsure about any of the terminology used here you should consult the project management guide. Risk identification and analysis should be ongoing throughout the project but particularly at project start-up and stage boundaries. You are likely to start looking for risks relating to:
- The project plan
- Stakeholders
- Resources
- The organisational environment
- The external environment.
The risk profile will change as you move through the project so risk identification and review should be an ongoing task rather than a one-off event. All too often risks are logged at the start of a project then never updated.
Project plan
The project plan is one of your key sources for identifying risk. You should understand the importance of the critical path through the plan (the shortest time needed to complete the project) and the nature of task interdependencies. The following are areas which are likely to have associated risks:
- Tasks that rely on the completion of other work before they can begin
- Tasks that none of the project team has ever done before
- Use of unfamiliar technologies
- Tasks that involve third parties
- Migration of data from one system to another
- Reliance on suppliers to deliver software upgrades at a specific time
- Availability of key decision makers at critical points
- Decisions that involved more than one department/team
- Resources/staff that are outside your direct control
- Any component of the plan based on assumption rather than fact.
If you are following our advice you will be using the concept of the 'sliding planning window'. This means only planning ahead so far as is feasible and sensible at the time. At the start of the project there will be much that you don't yet know. Once again senior managers and key stakeholders must understand the nature of the uncertainties because of course uncertainty means risk.
A major problem in many projects is the desire of senior managers to see a detailed plan at the start of the project and to 'freeze' that plan at too early a stage. This is not intended to provide any kind of justification for poorly planned projects where scope creeps and timescales drift; it is simply stating that, in the real world, even the best planned and managed projects will have to cope with uncertainties and changes.
In addition to risks associated with your particular plan there are a range of risks that tend to beset any project in the education sector. These risks need to be addressed in the early stages of planning.
- Recruitment and retention of project staff
- Space and facilities for project team
- Part-time project staff who are distracted by the 'day job'
- Decision making processes unclear or very slow
- Involvement of consultants who are not familiar with the education sector.
Stakeholders
You should by now have identified who are the stakeholders in your project or initiative and undertaken an analysis of their likely perceptions of the project and attitudes to it. A stakeholder analysis template is available.
In any undertaking involving a substantial amount of change there will undoubtedly be people who are adversely affected or who fear they will be disadvantaged by the change. These people can be termed adverse stakeholders and they may present a risk to your project. The risk may be in terms of direct opposition to the project at the initiation stage or a 'war of attrition' during the course of the project.
Here are some examples of people who are likely to be adverse stakeholders are people who:
- Fear loss of their jobs
- Will require retraining
- May be moved to a different department/team
- May be required to commit resources to the project
- Fear loss of control over a function or resources
- Will have to do their job in a different way
- Will have to carry out new or additional functions
- Will have to use a new technology.
In thinking about adverse stakeholders don't forget your own project team if they are overworked or under resourced. The risk presented by any of these individuals depends on their authority within the organisation and their influence on the project. The stakeholder analysis template will help you identify this and help plan the involvement of, and communication with, key stakeholders.
Organisational environment
Risks associated with the organisational environment may be general or specific. General risks relate to the organisational culture, eg, are you trying to introduce innovative change into a bureaucratic or reactionary organisation? This background information should be known and planned for although it may take a project manager new to the organisation some time to get to grips with the complexities of its structures and power centres.
Specific risks are associated with the organisation's mood at this point in time. For instance are you trying to undertake a system implementation shortly after a similar project has gone badly wrong or trying to introduce process change at a time when organisational restructuring is causing concern about potential job losses?
This situation needs regular review because the successes or failures of initiatives elsewhere in the organisation can impact on your chances of success. Here are some typical examples of circumstances that may cause risk to your project:
- A similar project has failed in the past
- The organisation is being restructured whilst the project is in progress
- You have funds to spend while others are being forced to make cuts
- Many related projects are going on without effective programme management
- Your require resources/action from people over whom you have no authority
- There is about to be a new postholder in one or more senior management positions
- One or more core IT systems is changing
- Expansion/merger/location moves are taking place
- Your organisation is involved in an OFSTED inspection, quality review or compilation of data for the Research Excellence Framework whilst the project is going on.
External environment
The larger and more complex your project or initiative is, the greater the risk that changes in the external environment may affect it. Senior managers and those responsible for organisational strategies and plans should of course be scanning the external environment routinely. The sorts of external factors that may cause risk to individual projects or prompt changes in strategy are:
- A change in government
- A change in the funding model
- New legislation eg, relating to Data Protection, Freedom of Information, Disability, Health and Safety
- A change in the market for particular subjects
- Economic recession in a country that provides a large proportion of your overseas students
- A competitor merges with another or changes its course portfolio
- A major system supplier goes out of business.
There are of course risks that fall outside these categories specifically the risk of a major disaster. Disaster planning, or business continuity planning, falls outside the scope of this guide although many of the principles of risk management outlined here are essential in preparing an effective business continuity plan.
It is advisable to involve as many people as possible in the risk identification process and to have some form of external validation of the outcome. Remember if you are the project manager then your evaluation will be emotionally coloured to the same extent as anyone else's. In practical terms this means you may be inclined to 'downgrade' serious risks because you want the project to go ahead.
Staff not directly involved in the project can often act a 'devil's advocate' to question your assumptions.
The suggestions above can be used to help you develop a checklist for risk identification but you also need to think about what is unique about your project. The danger of generic checklists is that you go through ticking the boxes in a formulaic way and fail to do enough thinking. This project may be similar to others you have done but you need to focus on the differences – what makes this one unique?
It is sometimes better to use the generic checklist to review your answers at the end of the exercise ie, after you have thought about the project in unique terms.
Cause and effect
By now you will probably have a list of potential risks as long as your arm and be wishing you'd never thought of the project in the first place. The next step is to consider the root causes of the risks you have identified. If at this stage your list includes risk such as 'project may overspend against budget' or 'project overruns expected timescale' you will have to go back to the drawing board. Neither of these is a risk in itself: they are consequences of something else having gone wrong.
Similarly if you were to write there is a risk that 'The project team is inexperienced' what you are actually describing is a pre-existing condition that may go on to cause a variety of effects.
A risk should be documented in the form:
- Condition
- Cause
- Consequence
- Context.
A disciplined approach to how you document risks makes the rest of the management process very much easier.
After each of the risks you have listed try adding the word 'caused by' then complete the sentence eg, staff may leave before the end of the project caused by…
This is a very typical project risk and there could be a variety of different endings to that sentence but unless you know which of them is applicable in your case you are not likely to be able to do anything about it. The next step is to look at what are the consequences of the risk occurring. You need to add the words 'resulting in' then complete a new end to the sentence.
- Condition – 'There is a risk that'
- Cause – 'caused by'
- Consequence – 'resulting in'
Context is also important for instance in selecting and implementing a new IT system certain risks may be associated with one or more potential suppliers but not with others. If you state risks in a poor or sloppy way then risk management becomes a platitude. You will reveal nothing that is unique about your project and will not have the information you need to take effective action.
Good description also help you to filter out things that shouldn't be in there ie, things that fall into the category of general management concerns rather than risks specific to your project.
The risk log
An essential tool in any project management methodology is the risk log or risk register. This provides a means of recording the identified risks, the analysis of their severity and the necessary management actions to be taken.
The risk log can be a simple document or spreadsheet and as a general guide any risk log should contain the following fields:
Unique ID | This may be simply a title but some kind of alphanumeric coding may be useful where you are dealing with a large number of risks. |
Risk (description) | Presented in a structured format: Condition – 'There is a risk that' Cause – 'Caused by' Consequence – 'Resulting in' |
Likelihood (probability) | What is the likelihood of the risk occurring? It would be helpful to record the justification behind this analysis. |
Impact | What will the impact be if the risk occurs? It would be helpful to record the justification behind this analysis. |
RAG status | Red, Amber, Green (RAG) status, based on the product of the probability and impact – this is explained further in the section on quantitative risk analysis |
Timescale | What is the 'risk window' when this risk may occur and when do you start to lose options as to how you respond? |
Cost | What will the risk cost if it does occur? NB. You can't assess this unless you know what your response action will be. |
Owner | There should be a person nominated to 'own' the risk which means monitoring the situation and ensuring that necessary management actions are carried out. In a project situation this should be somebody within the project team and in all cases it should be somebody who will be impacted by the risk and who has a vested interest in addressing it. |
Risk management approach/ Mitigating actions | What are the agreed response actions? These may be broken into:
|
Residual risk | This is the expected level of risk once all the mitigating actions are complete. |
Early warning signs | What 'trigger' might alert you to the fact that the risk is about to occur? In some cases you may only choose to spend money on a response action once the trigger occurs. |
You may also want to note any interdependencies between risks ie where one risk occurring impacts on another risk. This is sometimes known as 'risk coupling'. This cross-reference alerts you to the fact that when one risk occurs a related risk also requires reviewing.
Our basic template gives you a starting point. This is an expanded version of the preliminary 'risk assessment' template used within our project management guide (both the full risk log and the cut-down initial risk assessment can be viewed in the same template, one on each tab). Merely having logged the risks and possibly assigned them a probability and impact (often very subjectively) can give you a warm glow and the feeling that 'that's that sorted!'.
Actually that's when the real work starts. We've covered the risk log at this point because it is a tool for you to record the identified risks as a first step in managing them. In all probability, having identified a risk, you will have to do a lot more analysis and planning before you can fill in all of the fields with any degree of confidence and start to turn the unknown into the planned.
You may wish to add 'progress logs' for each risk – these could be all under one tab/sheet, or for more complex projects a single progress sheet per risk (and example is given in our template for the risk ID 'EXAMPLE1').
Qualitative risk analysis
Having identified a range of risks we now need to consider which are the most serious in order to determine where to focus our attention and resources. We need to understand both their relative priority and absolute significance.
People are not generally good at analysing risk. We tend to take decisions swayed by our emotional response to a situation rather than an objective assessment of relative risk. Given half a chance most of us will believe what we want to believe and selectively filter out information that does not support our case.
We are similarly bad at looking at probability in a holistic way. People generally focus on risks that have occurred recently even though another risk may have happened exactly the same number of times over the last five years.
We must nonetheless accept that most of the risk analysis done in our environment will be of a qualitative nature. Few of us have the skills, time or resources to undertake the kind of quantitative modelling that goes on in major projects in the commercial sector. This section aims to show that by taking a disciplined and structured approach it is possible to improve the objectivity of your analysis without getting into complex calculations or needing specialist software tools.
We have already said that it pays to involve a range of people in the identification and analysis of risk. Each will of course bring their own bias to the analysis but if you understand your organisation and stakeholders it ought to be possible to separate out the valuable experience from the personal agendas eg, 'Fred always emphasises hardware security as he's been in three colleges that have suffered major break-ins' or 'Fred always emphasises hardware security as he's been after funding to move the machine room for the last five years'.
One technique that is sometimes used to keep politics out of this type of discussion is the Delphi Technique. Using this technique opinions are gathered anonymously then cross-checked with a range of experts. The experts are simply looking at the data presented rather than dealing with the personalities involved.
Delphi technique - gathering opinions anonymously
The Delphi technique has been defined by Linstone and Turoff as:
…a method for structuring a group communication process so that the process is effective in allowing a group of individuals as a whole to deal with a complex problem.
Linstone, Harold A and Murray Turoff (EDS) (1975) - 'The Delphi Method: Technicques and Applications' - Addison-Wesley, p3
It was originally developed as a technique for the US Department of Defense. The development occurred during the early part of the Cold War in the 1950s when the Rand Corporation was charged with finding a way to establish reliable consensus of opinion among a group of experts about potential Soviet military attacks.
Half a century later the technique is still widely used, but usually in much more peaceful endeavours. The underlying rationale continues to be:
to establish as objectively as possible a consensus on a complex problem, in circumstances where accurate information does not exist or is impossible to obtain economically, or inputs to conventional decision making for example by a committee meeting face to face are so subjective that they risk drowning out individuals' critical judgements.
British Council
The approach tends to be a group of techniques rather than an individual procedure. Typically the approach will involve an expert panel; a number of information gathering rounds each of which ends with an analysis process and feedback into subsequent rounds. Individuals are given the opportunity to revise judgements as a result of feedback. The number of iterations can vary (the more rounds the closer the consensus is likely to be) as can the size of the panel – from a handful to several hundred participants.
The process has the following features – anonymity (to a greater or lesser extent, depending on how the exercise is structured), iteration, controlled feedback and statistical aggregation of group response.
Examples of practical applications of the technique can be found at Henley Delphi Research Tool website.
In deciding how serious a risk is we tend to look at two parameters:
- Probability – the likelihood of the risk occurring
- Impact – the consequences if the risk does occur.
Impact can be assessed in terms of its effect on:
- Time
- Cost
- Quality.
There is also a third parameter that needs to be considered:
- Risk proximity – when will the risk occur?
Proximity is an important factor yet it is one that is often ignored. Certain risks may have a window of time during which they will impact. A natural tendency is to focus on risks that are immediate when in reality it is often too late to do anything about them and we remain in 'fire-fighting' mode. By thinking now about risks that are 18 months away we may be able to manage them at a fraction of the impact cost.
Another critical factor relating to risk proximity is the point at which we start to lose options. At the start of a project there may be a variety of approaches that could be taken and as time goes on those options narrow down. We said earlier that risk management is about making better decisions. Very often in the education sector we put off taking decisions until the options disappear and there is only one way forward.
Assessment of both probability and impact is subjective but your definitions need to be at an appropriate level of detail for your project. The scale for measuring probability and impact can be numeric or qualitative but either way you must understand what those definitions mean. Very often the scale used is high, medium and low. This is probably too vague for most projects. On the other hand a percentage scale from 1-100 is probably too detailed.
Use enough categories so that you can be specific but not so many that you waste time arguing about details that won't actually affect your actions. Experience suggests that a five-point scale works well for most projects. A suggested scale is:
Scale | Probability | Impact |
---|---|---|
Very low | Unlikely to occur | Negligible impact |
Low | May occur occasionally | Minor impact on time, cost, or quality |
Medium | Is as likely as not to occur | Substantial impact on time, cost or quality |
High | Is likely to occur | Substantial impact on time, cost or quality |
Very high | Is almost certain to occur | Threatens the success of the project |
Assigning numeric scales
To move from qualitative to quantitative risk assessment, you can assign a numeric scale and, by using a 'traffic light' system – assigning red, amber or green against pre-determined value range – break the risks into groups requiring different response strategies. The red, amber, green designation is known as a 'RAG status' and was referred to in the risk log section.
This table uses the same linear scale for both axes:
The next table doubles the numeric value each time on the impact scale. This is perhaps a more useful model as it gives more weight to risks with a high impact. A risk with a low probability but a high impact is thus viewed as much more severe than a risk with a high probability and a low impact. This avoids any 'averaging out' of serious risks.
It is questionable whether the amber risks warrant separate classification in terms of your response strategy and it is suggested that you examine each in turn and either 'promote' or 'demote' them to red or green. This can be important in assessing the overall level of risk especially if you opt for the straightforward linear scale in the first table. This means particularly being clear about what you mean by a 'medium' level of probability.
Suppose a risk has a 50% likelihood of occurring and may cost you £20k. This is as likely to happen as not yet people often tend to ignore risks labelled 'medium'. There is an argument for saying that it is hardly worth breaking down categories of probability over 50%. Once a risk is as likely to happen as not you should plan for it.
The diagram below shows the previous example with the amber risks demoted or promoted (here those risks with a value of 10 or above have been promoted to red, below 10 demoted to green).
Cutting your risk categories down in this way leaves you with two sets of risks requiring a response strategy:
Red risks = unacceptable. We must spend time, money and effort on a response. This is likely to be at the level of the individual risk. Green risks = acceptable. This does not mean they can be ignored. We will cover them by means of contingency. This means setting aside a sum of money to cover this group of risks. We will look at how you calculate contingency in the section on costing risk.
In the above example, progressing with the project itself may be called into question given that more than half the risks are now indicated in red.
Quantitative risk assessment
The previous qualitative definition of risk is one with which most project managers will be both familiar and comfortable. However, at the risk of introducing a degree of circularity into the reasoning, none of this means anything at all in real terms unless you have set some kind of thresholds for your qualitative definitions.
What do we mean by a medium risk? If a risk is likely to cause a five-week delay to your project or cost you £10k where does that sit on the scale of 'very low' to 'very high' in relation to your particular project? You must do these threshold definitions and understand what are high cost and time implications for your project before you can assess risks in a meaningful way.
The following table suggests a general measure of impact in the education environment.
Impact | Cost | Time | Quality |
---|---|---|---|
Very low | Variations manageable by virement against internal budget headings | Slight slippage against internal targets | Slight reduction in quality/scope with no overall impact on usability/standards |
Low | Requires some additional funding from organisation | Slight slippage against key milestones or published targets | Failure to include certain 'nice to have' elements or 'bells and whistles' promised to stakeholders |
Medium | Requires significant additional funding from organisation | Delay affects key stakeholders and causes loss of confidence in the project | Significant elements of scope or functionality will be unavailable |
High | Requires significant reallocation of organisation funds (or borrowing) to meet project objectives | Failure to meet key deadlines in relation to the academic year or strategic plan | Failure to meet the needs of a large proportion of stakeholders |
Very high | Increases threaten viability of project | Delay jeopardises viability of project | Project outcomes effectively unusable |
There are many variations on this table. In the commercial world percentage scales are often used for the cost and time components. The scale frequently goes from less than 5% variation (low) to greater than 20% variation (very high).
You may also see the term 'insignificant' variation used in the definition of 'very low'. Here we contend that a 'risk' with an 'insignificant' impact does not warrant your time in monitoring and managing it. That is not to say that in your first trawl for identified risks you will not come up with suggestions of this nature that on analysis turn out to be not worth including.
Some purists would say that all of these suggestions should be logged and constantly reviewed but experience shows that the larger and more intimidating the risk log the harder it is to take effective action about the risks that matter. If you are doing your monitoring and horizon scanning thoroughly then changes in the risk situation will become evident to you.
It may be worth taking the above table and putting in specific figures relating to your project eg, a very low risk is one costing up to £500 on our scale and a very high risk is one over £15K or a very low risk is one causing a delay of less than a week whereas a very high risk causes a delay of three months or more etc.
Costing risk
It's time to get down to hard facts now – risks cost money and we need to be able to plan for this and set realistic budgets. We introduce a little bit of accounting jargon in this section but it contains some useful ideas that could save your career.
In the education environment it is often the case that time delays are viewed less seriously than obvious cost increases. It is of course possible to put a cost figure on a time delay simply by calculating the cost of staff working on the project for the extra time.
The argument that 'We have the staff anyway' retains little credibility these days. If the time delay was unacceptable you may also need to think about the cost of overtime or extra staff to get the project back on track.
Let's look at an example of how this might affect project cost. Say you have a project budget of £10k and the project is due to last 10 weeks. Just to keep things simple we'll say that the only cost of this project to the organisation is staff time amounting to £1k per week. Suppose there is a 50/50 chance of a risk occurring that will delay your project by two weeks. What will this project cost?
The answer is that it will cost either £10k or £12k and if you aren't ready to spend £12k then you aren't ready to do the project.
Expected Monetary Value (EMV)
An accountant may give a slightly different answer to the previous question by looking at the 'actuarial' cost of the project using the Expected Monetary Value (EMV) of the risk. EMV is a mathematical formula that can help make comparisons between a range of uncertain outcomes.
EMV = probability x outcome
For example a risk has a 75% chance of occurring and may cost £1k.
The EMV of the risk is 0.75 x £1,000 = £750
Using the concept of EMV for comparative purposes, suppose someone were to offer you two envelopes. Envelope A contains £1,000 and envelope B has a 50/50 chance of containing £2,500. Which would you choose?
Looking at the EMV of each:
A is 100% certain so has a probability of 1 therefore, EMV (A) = 1 x £1,000 = £1,000
B has only a 50% chance of occurring therefore, EMV (B) = 0.5 x £2,500 = £1,250
In theory you should take envelope B as the EMV is higher. In practice your decision will depend on how badly you need the £1,000 and whether you are prepared to take a gamble. This goes back to the concept of utility we discussed earlier.
Going back to our earlier example of the 10 week project, an accountant might say the expected cost of the project was Project budget + EMV of risk.
Hence the project would cost £10k (project budget) plus (0.5 x £2,000 = £1,000) (EMV) i.e. a total of £11k.
This is fine in theory but in practice, if the risk occurred and you had a budget of £11k, you still wouldn't have enough to meet the cost of the risk.
Spending to save
The concept of EMV becomes more useful when you consider the fact that you could spend some money to remove the risk. Suppose the risk is that another organisation is supplying you with some data but they can't guarantee to deliver on time.
Let's say you could pay that organisation £500 and they would guarantee to deliver. You would now need a budget of £10.5k which would save you £500 on the actuarial cost of the project and £1.5k on the potential cost if you did nothing about the risk. This is about spending to save.
You do of course need to be confident in your assessment that the risk is 50% likely and will cause a 2 week delay in order to justify the spend. If you've gone through a generic risk checklist and just ticked off 'low, medium, high' you won't be able to do this. If you've done a thorough analysis of the real risks to your project you will be well equipped to set a budget that is realistic and justifiable.
To take another example suppose you have identified a risk (75% likely) that your key technical person will leave because you aren't paying market rates. This could cause a three-month delay whilst you recruit to the post and will incur recruitment costs and cost in terms of decreased productivity and delay to the project.
Offering the person a bonus to stay till the end of the project or offering staff development incentives eg, an expensive training course or conference could be cost effective in the long run. In order to justify this you will have to cost the consequential impact of the risk.
Calculating contingency
The concepts of EMV and actuarial cost really come into their own when you start to plan for the risks that fall into your green or acceptable category. You won't have a detailed response plan for each of the individual risks but you will need a contingency sum set aside to deal with those risks that do occur.
Suppose you have 10 green risks identified and each is 50% likely to occur and each will cost £2k if it does occur:
The EMV of each risk = 0.5 x £2,000 = £1k so the total for 10 risks = £10k
The project needs a contingency of £10k to cover these risks.
Of course EMV doesn't equal reality what it is saying is that half of the time you will need £2k per risk and the other half won't occur. Looked at another way the £10k contingency will only be enough to cover costs half of the time. You can be 50% confident that the project can cover its risks.
Contingency for high impact risks
Let's look at another example. Suppose you have a risk that is only 5% likely to occur but if it does it will cost you £250k:
EMV = 0.05 x £250,000 = £12,500
It is pointless having £12.5k in your contingency if this risk actually occurs. A risk with this level of impact would have to be viewed individually and the necessary contingency would need to exist at the organisational, rather than project, level.
At the risk of stating the obvious, averages only work with a range of numbers. EMV is useful for looking at groups of similar risks. EMV doesn't make sense if you are looking at a single risk with high impact or probability.
Contingency for high probability risks
Let's say you have 5 risks each with an 80% probability of occurring and they will each cost you £4k:
EMV = 5 x 0.8 x £4,000 = £16k
Rather than ask for the £16k EMV you should ask for the full £20k that is needed should all of the risks occur. With a probability of 80% you are saying that it is much more likely than not that the risks will occur – so plan for them. What this is really giving you is an opportunity to make savings against a realistic budget. If only 3 of the risks occur you will have saved £8k.
In summary actuarial cost based on the EMV of groups of similar risks can give you a guide as to how much contingency a project requires. Not all of the risks will occur but the contingency should cover those that do. Special arrangements will need to be made where a single risk could have a very high impact. Unless the probability of such a risk is very low it may undermine the business case for the project.
This technique can also be useful in helping you plan your budget when you are bidding for a research or other contract. Contingency is not a 'slush fund' or 'padding' to cover for poor project management: it should be justifiable and reviewable. The contingency is there for specific risks and should only be released if a risk occurs. The project steering board or its equivalent should authorise the release of contingency funds.
Budgeting in the real world
Having calculated the cost of both red and green risks the project budget can be seen to be made up of:
A project with all of these elements in the budget is funded to survive in the real world. If the project manager only gets A then the organisation is accepting the possibility that it will ultimately meet the full cost of all the unfactored risks. (NB. Factored risk exposure is the estimate based on average EMV. Unfactored risk exposure is the worst-case scenario if all the risks happen). This isn't just theory it's the real world.
Failure to include risk response costs and contingency for risk in the project budget is a failing at the most senior level. This spend always occurs but in immature organisations it is either invisible or appears as project overspend.
It is usually the case that spending money up front to address the risks results in lower overall cost. However many organisations can't cope with spending money now to save in future and simply take their chances when the risks occur.
You can see from this that a lot of work has to go into setting a realistic budget. You can't work it out on the back of an envelope ten minutes after you've been given a rough brief. You may be able to give an indicative budget at an early stage when the business case for the project is being considered but there is much more work to be done as part of the project initiation before a detailed budget can be prepared.
At this stage you may need to revisit the business case if analysis shows the project to be riskier and more costly than first thought.
Opportunity costing
There are a couple of other accounting terms worth looking at in considering how risk affects budgeting:
- Sunk cost – this is money already expended that can't be recovered
- Opportunity cost – this is forecast earnings from the project. This figure may change as we go through the project.
A risk occurring at some point in the project may alter your opportunity cost but it can't affect the money that is already sunk eg, you have invested in developing new courses, buying equipment and appointing new staff expecting to win an NHS contract worth £10 million. The total project cost was expected to be £4 million (making your opportunity cost £6 million) and you have already invested £3 million when the NHS pulls the plug on the deal. You are however offered a contract worth £3 million by a pharmaceutical company. What do you do?
Managing an organisation's budget is a bit like being a fighter pilot – you can't afford to dwell on past mistakes. You may have made a massive mistake in getting to where you are but you need to decide how to move forward. At this point in time your choice is either to stop now and lose £3 million or accept the new contract and invest a further £1 million thus reducing your overall loss at the end of the project to £1 million.
Planning in the real world
Much the same goes for creating real world plans. In planning, perhaps more than in any other project activity, we tend to exhibit an optimism that verges on delusion. After all when was the last time you had a good surprise in a project? Time and time again we see planned deadlines based on an absolute best-case scenario.
A common scenario is that the absolute deadline is set before any scoping work is done. Very often you will be told there is a budget of X for you to deliver by Y then you are left to go away and work out how it can be done. Don't accept this – ask to see the analysis. If you accept the aspiration at this point this is effectively your 'point of commitment'. If you later deliver to more realistic estimates you will be seen as a failure.
Reactive project managers react to 'bad luck'. 'The plan was fine but we kept getting nasty surprises'. This is indicative of a fragile baseline plan that didn't take account of the risks. Proactive project managers create a robust and resilient plan by identifying and planning for risk.
The role of the project manager is to deliver against the plan so it is essential that the baseline, against which you will be judged, is realistic. Again the concept of risk and opportunity management is an important one.
To take another example let's say you have a 40 week plan and have identified a risk that is 80% likely to occur and will delay the project by 10 weeks. What do you do?
The answer is that you must build that delay into the plan. If it is 80% likely you are saying it is almost certain to occur so it would be totally unrealistic to plan as if it would never happen. What you end up with is a 50 week plan and you are giving yourself a 20% opportunity to improve on the baseline. Our organisations are becoming more aware of risk but we are still poor at creating processes to deal with opportunity.
Plans are of course based on estimates. We cover the topic of estimating in our project management guide but it is worth saying a little bit about it here just to draw out the relationship to risk. One way of looking at uncertain tasks is to use three-point estimates. For each uncertain task you estimate:
- The most optimistic timescale = MO
- The most likely timescale = ML and
- The most pessimistic timescale = MP
People using project management software often use this approach. The software can calculate the standard deviation of each of the estimates to show the relative uncertainty in the overall plan. This allows you to come up with statistical confidence limits e.g. you can be 50% certain that the project can finish within 100 days and 85% confident that the project can finish within 130 days etc.
This is not something you are likely to do manually but the concept of three-point estimates can be helpful in identifying bias in team members' estimates. If you ask a range of people how long various tasks will take they may all give different answers. If you then go back and ask for three-point estimates you may be able to tell who consistently goes for the most optimistic figure and who always 'pads' their estimates.
Another feature of many software tools is the ability to run Monte Carlo simulations. This uses three-point estimates for each of the tasks in a plan and assigns a random number of days to each task from within the given distribution. This is then repeated many times. Say a task has values of:
MO = 2
ML = 4
MP = 6
The simulation may estimate three days in the first pass, then four days, then two days, the six days etc, etc. The numbers generated are random but based on the distribution of the actual estimates. Running the model many times gives you an indication of how long the project may take in the real world. What is interesting about such simulations is that the answer equates to the most likely schedule (ML) for the overall project only about one time in 20.
Let's look at why this is:
Say we have tasks A, B and C that are all predecessors to task D. The chances of A, B or C meeting their ML estimate are 50% (one in two) in each case but when we look at the chances of them all being on time to feed into D the figure goes down to 12.5% (1 in 8).
The aim of this is not to encourage you to throw in the towel right now but simply to highlight the issue of overall uncertainty in the plan. The answer to this isn't to 'pad' every task with additional time but once again to allow an overall contingency to be used when required. You also need to be aware that the critical path through your project may change depending in which, if any, of the identified risks occur.
Risk response planning
Having identified 'green' and 'red' risks you now need to look at what your response will be to each of the red risks. There are a number of fairly standard definitions of response types that can be summed up as follows:
Response and Description | Examples |
---|---|
Risk avoidance Also known as risk removal and risk prevention. Altering the plan so that the circumstances which may give rise to the risk no longer exist. |
Risk: You plan to build a new sports centre on a green field site but there is a risk that the council will refuse planning permission and delay the project. Response: You decide to build on brown field site on a former industrial estate. This incurs additional cost in terms of demolishing old buildings and removing hazardous waste. |
Risk mitigation Also known as risk reduction. Reducing the probability or impact of the risk. |
Risk: You won't be able to attract technical staff for the project. Response: Offer a salary supplement to project staff. |
Risk transference Moving the impact (and ownership) of the risk to a third party. |
Risk:You are aware that colleges are the target of an organised gang stealing hardware. Response: You decide to outsource some of your servers to a hosting company. |
Risk deferral Deferring aspects of the plan to a date when the risk is less likely to occur. |
Risk: You are undertaking a major review of student administration processes and a new head of the organisation wants to implement an immediate re-structure. There is a risk that staffing resources won't be aligned with the new process. Response: Postpone the organisational restructure until the process review is complete and staffing requirements are known. NB Apologies to those who know this scenario is unrealistic and the opposite always happens – we can but try… |
Risk acceptance | Dealing with the risk via contingency rather than altering the plan. |
Even from these very basic examples we can see that, in all cases, the risk response costs money. This stage of the process can be quite iterative because until you know how you are going to respond to a risk you can't be sure what it will cost you in terms of time or money.
For example you may decide 'Losing a programmer won't lose us as much time as we thought. We don't need to take three months to recruit another because we can use a recruitment agency with a pool of programmers on their books if we are prepared to pay their 20% finder's fee'.
Risk response actions don't only occur when a risk happens – some of the above responses are preventative measures that are taken as soon as you identify the risk. At this point you may revisit your risk log to assess the status of a risk once the preventative or mitigating actions are complete. This is sometimes known as residual risk.
Risk monitoring and control
Of course the best risk planning in the world isn't any use unless you have a clear picture of how the situation in your project is developing in reality. You need to keep track of the identified risks, monitor the effectiveness of your risk responses and identify new or changed risks. This means having effective reporting mechanisms in place and ensuring that risk is covered in all key reports and reviews.
Most of the key issues are covered in the section on managing project phases in the project management guide.
You need to be on the lookout for the early warning signs or 'triggers' you identified. The classic project risk trigger scenario is of course your most casual employee coming to work in a suit and asking for the afternoon off…
Effective monitoring and control also involves creating the right conditions for openness and transparency in the project. If you have a tendency to 'shoot the messenger' then people will try to hide problems until the last possible minute by which time your range of response options may have narrowed.
A key role of the project managers is also to communicate risk to the stakeholders. Senior managers hate surprises so you need to keep reminding them 'these are the top five risks we are facing at the moment…' so that when one of the risks occurs they are prepared for it.
When a risk does occur – and it will – 'don't panic!' Implement your planned response and communicate the fact that the risk was anticipated and plans were in place. Those of us who dislike documentation be warned – the details in your risk log may be of critical importance if you are called to account for your assessment of, or response to, the risk. This should have been reviewed by your steering group or equivalent so you are able to say ‘this is what we agreed'.
On the upside your review may reveal risks whose time has been and gone without them ever occurring. In these cases you may be able to hand back contingency funds to the organisation.
Business case
At various points in this guide we have returned to the business case behind the project. Risk analysis and management is an important part of assessing whether the business case for a project really stacks up. Your risk identification may show more serious risks than had been anticipated – this means the business case must be reviewed.
The emotional or subjective element in decision-making comes to the fore here. As a project manager you may be pushing your organisation to undertake a risky project because otherwise you won't have a job. Conversely the organisation may be so risk averse that it is missing opportunities.
Your analysis of acceptable and unacceptable risks may reveal one or more potential ‘show stoppers' in the unacceptable risks. In this situation the project shouldn't go ahead until the risk has been addressed.
You may also need to review the business case in the event of a lot of risks being realised. Say you have assumed that one in five of the identified risks will occur but in practice most of them are happening – maybe external factors have changed and the business case doesn't stack up any more. You mustn't lose sight of the bigger picture for organisational risk management.
Creating a risk-robust culture
Changing our organisational cultures to be more risk-robust isn't going to happen overnight. However the more we talk about risk in relation to projects and try to give concrete examples of how risks will impact then the more likely it is that our stakeholders will begin to have more realistic expectations of real world projects.
Risk won't go away simply because we choose to ignore it or fail to plan for it. If we can start to create plans and budgets with risk factored into them then our organisations will develop a greater degree of confidence in their own abilities to manage projects and will be in a better position to evaluate their own risk tolerance.
We must not lose sight of the fact that risks can be turned into opportunities and a proactive approach to risk management is a first step in creating new opportunities as an organisation.
Wider application
The advice given here for project managers applies equally to the management of risk at the organisation level. The same process of planning, identification, evaluation and control should take place in relation to the organisation's strategic plans. HEFCE has produced some useful good practice guidance.
Risk management for developing employer-led training
Engaging with the provision of demand-led higher level skills courses is a high risk activity. Between 2006 and 2011, three regional HEFCE-funded higher level skills pathfinder projects enabled significant course development in this area by mitigating the financial risk for HEIs through the provision of funding.
This provided a test bed to trial the demand and response processes in a manner that encouraged the activity to become embedded more firmly in the region's HEI strategies.
Research led by Universities South West focused on key lessons learned through the pathfinder projects and other higher skills initiatives in respect of identifying and exploring failure and success factors for engaging in the development of new employer led training courses. In particular, it explored the inherent common risks, their indicators, their financial and reputational impact and the probability of occurrence through the provision of an exemplar risk register.
As well as this detailed exemplar risk register, the project also produced a blank risk register template (with various algorithms and transformations embedded within) and detailed guidance notes on how to use it. These resources, along with a final report, are all available to download from the case study wiki.