GOOD PRACTICE GUIDE. Effective Risk Management for IT and Business Change Projects

Transcription

1 GOOD PRACTICE GUIDE Effective Risk Management for IT and Business Change Projects

2 Contents 1 Introduction 1 2 Definitions 2 3 Project Risk Management maturity 3 4 Roles and responsibilities Responsibilities of the Project Manager Responsibilities of the Project Sponsor and Project Board Responsibilities of the Risk Owner 4 5 Identifying project risks 5 6 Creating and maintaining the Project Risk Log 8 7 Analysing and evaluating risk Risk probability Risk impact Overall risk scoring and traffic lighting Risk charts: probability versus impact 12 8 Risk management and review Risk management response Regular risk review Risk management reporting What happens when a risk occurs Project closure 14 9 Budgeting for Risk Management Risk management checklist Final thoughts 15 Universities and Colleges Information Systems Association University of Oxford 13 Banbury Road Oxford OX2 6NN Appendix 1: Aligning strategic risk with institutional risk 16 Appendix 2: Risks in an Agile environment 18 Acknowledgements 19 Tel: +44 (0) Fax: +44 (0) admin@ucisa.ac.uk

3 1 Introduction Risk is the uncertainty that comes from making any change. Every project has risks associated with it. A Project Risk is any uncertain event that may or may not happen but which if it occurs will have a material impact on the success of the project. A Project Risk usually cannot be entirely eliminated, however it can be managed. Risk impacts can be positive opportunities but threats are more common. Risk Management is Project Management for adults Tom DeMarco and Timothy Lister... there are known knowns; there are things we know that we know. There are known unknowns; that is to say, there are things that we now know we don t know. But there are also unknown unknowns there are things we do not know we don t know. Donald Rumsfeld These two quotes perhaps sum up what Project Risk Management is all about. Risk Management is one of the most important tools available to the Project Manager to help successfully deliver complex projects. Yet, at the same time, Risk Management can be difficult to understand and if used without insight and expertise will be confusing and ineffective. Too often stakeholders regard Risk Management as providing a list of reasons not to do something. This is a profound misunderstanding. By properly assessing and managing risk you are demonstrating that you are aware of what could happen and have taken steps to either prevent it or mitigate the effects if it does happen. Effective Risk Management greatly increases your chances of project success. Not all risks are bad however much some Project Managers and workers may fear them. This guidance has been developed to assist staff who are managing or participating in IT and business change projects. It has been developed by the UCISA Project and Change Management Group and is based on best practice guidance provided by PRINCE2 and experience of delivering major IT and business change projects at the University of Sheffield, Lancaster University, the University of Edinburgh and Edinburgh Napier University. The guidance is relevant for projects being managed and delivered using any methodology and is complementary to the UCISA Major Project Governance Assessment Toolkit. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 1

4 2 Definitions What is a risk? Put simply, a risk is something that might happen but hasn t happened yet: An uncertain event or set of events that should it or they occur would have an impact on the achievement of one or more of the project objectives 1. What is an issue? A risk becomes an issue once it has happened: A threat to the Project Objectives that cannot be resolved by the Project Manager 1. What is Project Risk Management? Project Risk Management is the identification, assessment, and prioritisation of risks followed by coordinated and economical application of resources to minimise, monitor, and control the probability and/or impact of unfortunate events or to maximise the realisation of opportunities: Risk Management is a process that allows individual risk events and overall risk to be understood and managed proactively, optimising success by minimising threats and maximising opportunities 1. What is risk probability and impact? Probability is the likelihood of the risk actually occurring. Generally we will consider two types of risk probability the inherent probability, which is the original starting probability of the risk occurring and the residual probability, which is the probability of the risk occurring after the identified risk reduction/mitigation actions have been put in place. Impact is the effect on the project when the risk actually occurs. As with probability we will consider two types of risk impact the inherent impact, which is the original starting impact of the risk occurring and the residual impact, which is the impact of the risk occurring after the identified risk reduction/mitigation actions have been put in place. Often risk impact and probability are scored using a predefined range and the two values are multiplied to give an overall assessment score for the risk. What is a risk log? A Risk Log or Risk Register acts as a central repository for all risks identified by the project and, for each risk, includes information such as probability, impact, countermeasures, Risk Owner and so on. The Risk Log document should be brief and to the point. It is a practical working document. What is a Risk Owner? A Risk Owner is a person or entity that has been given the authority to manage a particular risk and is accountable for doing so. In practical terms the Risk Owner should be someone who can monitor the risk and ensure that required mitigation actions are progressed. The Risk Owner will often have direct responsibility for the organisational unit, technology area or business activity that is the source of the risk. Alternatively the Risk Owner may be a senior manager with authority to monitor the progress of risk mitigation actions. Where a Project Board has been established it can be helpful for someone on the Project Board to monitor each risk, in addition to the Project Sponsor and Project Manager. The Project Board member may in fact be designated as the Risk Owner, but this is not essential. In this role they need to keep an eye on the risk, ensure the agreed risk mitigation actions happen and alert the Project Board if there is a change. 1 APM Body of Knowledge, 5th Edition, 2006, ISBN B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 2

5 3 Project Risk Management maturity The benefits of Project Risk Management are maximised where there is a mature approach to managing risk across the institution. In the last few years we have started to see signs of this maturity in many of our own institutions. The overall environment however remains patchy and even organisations with a mature approach to managing business risk have not necessarily updated their approach to Project Risk Management and vice versa. In developing your approach to Project Risk Management aim to achieve as many as possible of the following signs of Project Risk Management maturity: 1. Project governance bodies and senior management engage with and promote effective Project Risk Management and accept the time and resource implications of required mitigation actions; 2. The benefits of effective Risk Management are understood and accepted by all staff engaged in project and change management activities; 3. Effective Risk Management is fully embedded in institutional Project Management processes; 4. There is a clear and structured approach to Risk Management that is adopted for all IT and business change projects; 5. There are clear and well understood mechanisms for escalating risks that have implications beyond the project boundaries, i.e. which threaten the achievement of programme or business objectives; 6. Project and Service Risk Management are aligned with wider institutional policy with key IT Projects and Services often featuring on the current institutional Risk Register; 7. As projects progress the adverse impacts from key risks diminish and project delivery becomes more consistently successful. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 3

6 4 Roles and responsibilities Effective Risk Management requires that: Project risks and impacts are defined in business terms that are readily understandable to stakeholders; Project risks are identified and recorded in a Risk Log by the Project Board and Team; Reliable and up to date information is maintained on project risks throughout the lifetime of the project; Project Sponsors, Risk Owners and other project stakeholders are engaged with Risk Management and accept the time and resource implications of required mitigation and contingency actions; There are appropriate reporting processes to ensure that project governance bodies can monitor risk status and deal proactively and effectively with project risks; Project decision making processes are fully informed by risk evaluation. A well managed approach to risk will greatly improve the ability of the project to succeed. 4.1 Responsibilities of the Project Manager The Project Manager has two key responsibilities with regard to risk: to monitor risks and to ensure that actions are taken when a risk occurs or the likelihood of a risk occurring becomes imminent. Project Managers must control risks to maximise the chances of successful project delivery. The purpose of Risk Management is to limit project exposure to risk by taking action, in a proportionate and cost effective way, to keep risk at an acceptable level. The Project Manager, in conjunction with the Project Team, is responsible for ensuring that all risks are identified and regularly reviewed. The Project Manager must ensure that agreed actions, including monitoring by the Risk Owner, are taking place and have the desired effect. It is recommended that the Project Manager reviews project risks at least monthly with the Team. The Project Manager must ensure that the highest priority risks are highlighted to the Project Sponsor and Risk Owners with recommendations of any additional mitigation actions required. The Project Manager should report on the most significant risks as part of the Highlight Report to the Project Board and in monthly project reports. The Project Manager should review risks at the end of a stage as part of the stage signoff process. If a risk actually occurs the Project Manager has responsibility for instigating the contingency action and/or dealing with the resulting project issue using the Project Issue and Change Control (PICCL) process. 4.2 Responsibilities of the Project Sponsor and Project Board The Project Sponsor and Project Board have a number of important responsibilities within the Risk Management process: Providing overall ownership for the Risk Management process; Regularly reviewing project risks (this review should be a standing agenda item at every Project Board meeting); Making decisions on the Project Manager s recommended mitigation/countermeasure actions; Striking a balance between the cost of risk mitigation and the threat to project delivery and benefit realisation; Notifying the Project Manager of any external risks that may impact on the project; Escalating to business or programme management any risks that have implications beyond the project, i.e. which threaten programme or business objectives. 4.3 Responsibilities of the Risk Owner Each risk must have a Risk Owner who has responsibility for monitoring the risk. The Risk Owner has ultimate responsibility for monitoring each risk that they own. The task of monitoring the risk may be delegated but responsibility stays with the owner. The Risk Owner will have the responsibility of monitoring each risk assigned to them. However, overall responsibility for the Risk Management process lies with the Project Sponsor. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 4

7 5 Identifying project risks The first step in Risk Management is risk identification. This should take place during the project initiation phase and be led by the Project Manager and supported by the Project Sponsor and other key stakeholders. It is a good idea to run this as a workshop so that all are involved in the discussion about risks and what should be done to mitigate them. Normally some of the risks associated with a project are obvious at the project initiation. Others will take more work to identify. Some typical risks are identified in the table below. However, beware of having solely template based risks. Risk The solution delivered by the project will not be accepted by end users. The desired scope will not be delivered within the agreed budget. The staff resources required from an internal team or business unit to successfully deliver the project will not be made available at the required quality or quantity. The existing IT infrastructure will not have sufficient capacity to adequately support the new or updated services delivered by the project. The external supplier engaged on the project will not deliver products of the required quality. Key members of the Project Team and Board leaving. Notes This risk is absolutely critical in most IT and business change projects. To mitigate this risk, try to involve users in specifying the solution and focus on how you are going deliver effective communication that wins hearts and minds support from the user community. This risk is particularly relevant where there is a fixed or very limited budget. The probability that this risk will occur is related, at least in part, to the quality of the business case for the project and the resulting budget allocation. In a typical matrix management structure found in universities and colleges, this risk will be owned by the line manager/resource manager for the team or business unit in question. Where there are several business units involved there should be multiple risks identified. This risk will typically be owned by the manager with responsibility for the IT infrastructure. Where there are several IT infrastructures (and managers) involved, e.g. in a hybrid on premises/cloud implementation, there should be multiple risks identified. In many projects we are dependent on external suppliers and there may be a number of risks associated with this dependency. Effective mitigation actions may include defining checkpoints for supplier progress, ensuring low turnover of staff and transfer of knowledge between personnel when changes do take place, establishing payment schedules tied to project progress and engaging a senior member of the supplier management team on the Project Board. These could be institutional or external consultancy or contract staff. PRINCE2 identifies other areas of risk that may be relevant for your project. These include: Strategic/Commercial, e.g. collapse of external suppliers; Economic/Financial/Market, e.g. Shortage of working capital or failure to meet projected revenue targets; Legal and Regulatory, e.g. New or changed legislation; Organisational/Management/Human Factors, e.g. inadequate policies or lack of clarity over roles and responsibilities; Environmental, e.g. adverse weather conditions, building estate; Political, e.g. bad publicity, reputational damage; Technical/Operational/Infrastructure, e.g. capacity or performance failure, scope creep, technical capability. These categories fit broadly under the PESTLE acronym Political, Economic, Social, Technical, Legal and Environmental. Another way of identifying possible risks is to use the areas identified below. Use either or both the main thing is to think widely about possible problems. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 5

8 External (to the Project) Environment Legislative, statutory or political changes, affecting the reason for the project, its scope or content; Funding changes for the institution or relevant business units; Technology changes, either externally or within the institutional IT infrastructure, that affect the reason for the project, its scope or content; Changes in direction or priorities; Re-organisation, affecting the reason for the project, its scope or content; Personnel changes, e.g. losing a key supporter for the project; Delay or failure of projects on which this project depends; Withdrawal of resources. Project Content Unclear aims and objectives; No adequate solution exists for the business needs that the project aims to address; Failure to engage key stakeholder groups including end users or senior management; Selected solution proves over the budget; Implementation issues; Dislocation of institutional activities; Serious delays affecting key delivery dates; Unexpected difficulties shifting cost-benefit balance against the project. There are a number of useful ways of identifying risks at the outset of a project: Hold a risk identification session leave nothing out. A good way to do this is to go round the table with your Project Sponsor and key stakeholders at the start of the project, asking them to state one risk at a time. If someone starts with a second risk when it s their turn, ask them to save it and write it on a post-it note. It can be used next time round if someone has run out of risks; Consider previous projects if you maintain a project Lessons Learned Log or other project repository and use this to review projects you have done in the past, are any of the risks identified in the past valid for this project? In reality, very few risks are entirely unexpected. As Project and Risk Management capability grows in maturity in your organisation, you will become better able to review risks from previous projects and pick out the ones that are most relevant to the current situation. However, you cannot just rely on former risk assessments project circumstances and risks change; Review Project assumptions there may be assumptions that underpin the project, e.g. the current contract allows users to roll out the solution to a wider audience, the business partner has the skills and capacity to deliver their project responsibilities. If there is any chance that any of these assumptions is incorrect or uncertain then this should be identified and managed through the risk process; Consider people as risks in a University or other complex business, people are generally one of your greatest risks. As well as including risks associated with groups of people in the institution, you should conduct a Stakeholder Management/Engagement exercise this, however, is outside the scope of this document; Look for hidden risks these are risks that may be referred to indirectly in documents and in verbal and written communications between project stakeholders. These risks often have strong emotional underpinnings and can greatly impact on your project if not carefully managed; Remember positive risks progress can be better than expected. Will other services be ready for you? Risks can become benefits. Risks occurring may force you to improve the outcomes or find better ways of doing things as workarounds that you hadn t considered; Refer to your institutional risk register a sensible step, particularly for major projects, is to align Project Risk Management and actions to the wider corporate policy. The institutional risk register may be useful in helping identify some of the most important business risks for your project. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 6

9 At this initial stage it is more important to try to identify all of the most important risks for the project rather than attempting to judge probability, impact, contingency, Risk Owners and mitigation steps. Inevitably these areas will be discussed and all useful information should be recorded in the Risk Log as part of the initial risk identification. Always try to avoid conflated risks where the risk is so imprecisely stated that that it cannot be readily understood by stakeholders or effectively managed by the Project Manager and Risk Owner. Risks, such as Project will be late or Project will be over budget, are much too broad to be useful instead look for the root cause of schedule or cost overruns and define each of these root causes as a risk. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 7

10 6 Creating and maintaining the Project Risk Log The Risk Log should be brief and to the point. It is a practical working document. The Risk Log is normally initially filled in for the first time during Project start up with a risk identification session involving the Project Sponsor and a few key stakeholders. The Project Manager might like to put in a few entries for starters based on knowledge of the project and previous experience but beware of people saying the risks are all in there! The most common entries in the Risk Log include: 1. Reference Number needed when referring to risks in other project documentation; 2. Description a short description of the risk normally completing the sentence There is a risk that... ; 3. Probability this is the risk likelihood of the risk actually occurring. Generally we ll consider two types of risk probability: the inherent probability, which is the original starting probability of the risk occurring and the residual probability, which is the probability of the risk occurring after the identified risk reduction/ mitigation actions have been put in place. In general, the risk log will have both of these entries for each risk but sometimes only the residual probability will be displayed in risk reports see Section 7 for more detailed information on assessing risk probability; 4. Impact this is the effect on the project if the risk actually occurs. Generally we ll consider two types of risk impact: the inherent impact, which is the original starting impact of the risk occurring and the residual impact, which is the impact of the risk occurring after the identified risk reduction/mitigation actions have been put in place. In general the risk log will have both of these entries for each risk but sometimes only the residual impact will be displayed in risk reports see Section 7 for more detailed information on assessing risk impact; 5. RAG (Red, Amber, Green) status this is the current traffic light status for the risk based on the residual impact and probability - see Section 7 for more detailed information on risk traffic lighting; 6. Risk Owner this is the person or entity that has been given the authority to manage a particular risk and is accountable for doing so; 7. Risk Management Response this is the approach taken to manage the risk, typically either Remove, Reduce, Transfer or Monitor see Section 8 for more details on choosing an appropriate Risk Management response; 8. Risk Actions these are the actions taken to manage the risk in line with the agreed Risk Management response; 9. Triggers How do we know this risk may be starting to happen? This is sometimes obvious, but often is not. It may also be worth noting who on the team, other than the Risk Owner, is responsible for monitoring this and alerting the Project Manager; 10. Contingency Actions this is what you will do if the risk does happen. It is useful to consider these at the start of the project as you may need to make preparations or alert people in advance; 11. Date of Last Review this is the date the risk was last reviewed by the Risk Owner; 12. Risk Status normally just a flag to indicate whether the risk is open, transferred to the issue log or closed. This can be used to stop closed risks cluttering up the risk log without losing a record of them altogether; 13. Date Risk Logged date when the risk was added to the log; 14. Business Impact and Probability Scores whilst the risks belong to the Project they also can belong to the institution. Therefore, they should have their own score and be reported to an appropriate institutional committee as it is possible that what is an amber risk for the project might be a red risk for the institution; 15. Escalated to the Project Board Yes or No, along with date; 16. Project Board Decision a description of the action or comment from the Project Board to the risk. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 8

11 You can read each risk from the risk log using the following sentence construction: There is a risk <reference no description> which, if it occurs, will impact on the Project costs, delivery and/or benefits realisation. The Risk Owner is <Risk Owner> and our Risk Management response is <Risk Management response>. To manage and contain the risk the following actions <risk actions> have been agreed and implemented. Taking into account the <risk actions> currently in place the probability that the risk will occur is <(residual) probability> and the overall impact of the occurrence is <residual impact>. Should the risk occur the following contingency measures may be adopted <contingency actions>. The risk was reviewed by the Project Manager and <Risk Owner> on <date of last review>. If reading this from the risk log does not make sense the risk has probably been incorrectly specified. The actions, triggers and contingency actions columns should be considered carefully for higher impact/probability risks, but obviously less effort need be put in for low probability/impact risks. You could even leave these columns blank for low impact/probability risks on smaller projects. Use of these fields is illustrated in an extract from a risk log provided by the University of Edinburgh: Risk Log Ref Title Impact Probability Risk Status Risk Owner Date of Last Review 8 Solution components delivered by Data Integration and Reporting (RE S056) are delayed High Medium AMBER Open Susan Coleman 07-Nov Solution components delivered by Business Process (RE S052) are delayed 5 Solution components delivered by Finance Integration (RE S054) are delayed 3 Unacceptable Performance in TEST and/ or LIVE Environments due to scale of UoE requirements relative to existing customers High Medium AMBER Open James Thin 13-Oct-2014 High Medium AMBER Open Jill Nicoll 16-Oct-2014 High Low GREEN Open Tom Price 14-Oct-2014 Log Reference: 8 There is approximately two weeks scheduled contingency in the plan to accommodate delays in delivering components for system testing in March Delays of more than two weeks are likely to cause slippage in the go-live date of 16th June As this date is already sensitive due to its close proximity with the summer holiday period this is to be avoided if at all possible. There are a number of possible reasons why this risk should occur. The most significant are: z failure to agree business requirements early enough to complete development z resourcing challenges for external supplier z resourcing challenges for ERI/RGS z resourcing challenges for IS Risk reduction/mitigation strategies will focus on these most likely causes. Date Identified: Date of Last Review: Probability: Impact: Management Approach: Risk Owner: Contingency: 16-Oct Nov-2014 Medium High Reduce Susan Coleman There is approximately two weeks scheduled contingency in the plan to accommodate delays in delivering components for system testing in March Delays of more than two weeks are likely to cause slippage in the go-live date of 16th June As this date is already sensitive due to its close proximity with the summer holiday period this is to be avoided if at all possible. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 9

12 7 Analysing and evaluating risk Analysing the risk is about assessing the probability and impact of individual risks. Probability is the likelihood of the risk actually occurring, and Impact is the effect of the risk on the project when it actually occurs. In most cases risk impact and probability are scored using a predefined range and the two values are multiplied to give an overall assessment score for the risk. Different institutions will use different scoring approaches for risk probability and impact. For example, the table below illustrates the approach used by the University of Lancaster for IT projects. 7.1 Risk probability Score Interpretation Guidance (IT specific) 1 VERY LOW Remote chance that this risk will occur event is highly unlikely to happen 2 LOW Small chance that this risk will occur event is unlikely to happen 3 MEDIUM There is a moderate chance that this risk will occur 4 HIGH There is a strong chance that this risk will occur 5 VERY HIGH There is a very strong chance that this risk will occur i.e. almost certain. Risk is unlikely to ever happen within the lifetime of the project. Remember that an appropriate timeframe, generally the lifetime of the project, must be used to determine probability. For example, all key members of the Project Team leave the organisation within a short period and without warning. Risks of this nature do occur from time to time but are considered rare. For example the external supplier goes out of business and withdraws support for the project at short notice. Within the lifetime of the project there is a 50:50 chance of occurrence, i.e. neither likely nor unlikely. For example, the project suffers from the departure of a key project team member. This event is more likely to occur than not, within the lifetime of the project. During the lifetime of the project it is likely that the risk will happen at least once. For example, during the lifetime of a student records implementation project new government legislation may be introduced that impacts on the required functionality of the new system. 7.2 Risk impact Score Interpretation Guidance (IT specific) 1 VERY LOW Minor impact, insignificant risk. Negligible potential to adversely affect overall project costs or benefits Category intended to capture risks the occurrence of which would not present urgent problems for the project. For example, a small cost or schedule overrun that is unlikely to jeopardize a project or impact other University business goals. 2 LOW Low impact limited potential to adversely affect overall project costs or benefits 3 MEDIUM Significant impact and potential to adversely affect overall project costs or benefits 4 HIGH Major/severe impact. Potential to adversely affect overall project costs and benefits to a significant degree 5 VERY HIGH Extremely significant impact. Likely to adversely affect overall project costs or benefits to a major extent and possibly lead directly to project failure Risks with small but problematic consequences. Issue does not necessarily prompt response. Delay may be acceptable. For example the project may need to recruit additional personnel or extend timelines but have little impact on the University more widely. If this risk occurred a prompt and effective response would be required. For example, the project needs to add additional resources or change priorities to continue successfully. Effects may negatively impact on other projects or services. The occurrence of these risks would require immediate emergency response. For example, project budget or time overruns that cannot be accommodated without serious business impact. If this risk occurred escalation to the top levels of University management would be required immediately. All other project activities would become secondary to implementing the defined contingency. For example, unplanned loss of business critical application for a prolonged period due to project activity. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 10

13 In practice these scores can be difficult if not impossible to fix with any degree of precision. As a rule of thumb consider the overall ranking (see below) and reflect upon whether the chosen scores, when multiplied, achieve the traffic light colour that you think the risk ought to attract. The exact value of an impact, in terms of cost or disruption, or a probability is a matter of individual judgement and you are not expected to achieve a precise evaluation. Getting the risk in the appropriate range is more important. Disagreements about risk probabilities or impacts can be a positive indication that a healthy risk culture is developing! You can adopt as many levels as you need for scoring risk impact and probability. The simplest is a three level LOW, MEDIUM, HIGH but some areas can use as many as nine levels. It is important to find a balance between analysing risk and using effective Risk Management to successfully deliver the project. 7.3 Overall risk scoring and traffic lighting Once the probability and impact scores are determined these can be multiplied together to give an overall score for the risk. The resulting scores can be used to provide a traffic light or RAG (RED/AMBER/GREEN) assessment of each risk. The traffic light assessment provides a clearly visible indication of the relative ranking of each risk. The table below illustrates the approach used by University of Lancaster for IT projects. Overall Risk Score Label RAG Colour Code Description 1 7 ACCEPTABLE GREEN Can be accepted if risk is managed. Low level of risk, should not require much attention. Negative outcomes from risks or lost opportunities that are unlikely to have a permanent or significant effect on reputation or performance UNDESIRABLE AMBER To be avoided if reasonably practicable, investigation required, monitoring essential and mitigation recommended. Medium level of risk UNACCEPTABLE RED Intolerable, must be mitigated or transferred High level of risk, should be constantly monitored and reviewed. Possibly escalate beyond project to the senior management team. Over 20 Top level of risk, should be constantly monitored and reviewed monthly. Escalate to the senior management team. In general terms you can apply the following guidance for management of risk based on the current risk profile RAG status: RAG Status GREEN AMBER RED Recommended Minimum Action Project Manager and Risk Owner continue to monitor. Project Manager and Risk Owner to review, identify further mitigation actions and escalate if required. Project Manager and Risk Owner to review, recommend further mitigation actions and escalate to Project Sponsor and Project Board for further review and approval. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 11

14 7.4 Risk charts: probability versus impact You will need to balance the probability and impact of each risk. If a risk is low probability and low impact you may decide not to spend any time on it. You need to ensure that you spend your time and resources managing the most important risks. If a risk is highly likely to occur but has a low impact you should not expend a large proportion of your limited resources on it. Having identified probability and impact using the matrices above, these can be mapped out using a Risk Chart such as the one provided by the University of Sheffield below: High Risk Chart Equipment failure Likelihood Medium Security breach User resistance to change Low Medium Impact High In a Risk Chart the risks in the top right quadrant have the highest risk and impact and are the ones you need to pay the most attention to. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 12

15 8 Risk management and review It is not enough to carry out a risk assessment at the start of the project, put the results away in a folder and forget about it. Risks must be reviewed regularly, at least monthly, by the Project Manager, Risk Owner and Project Team. Have new risks emerged? Has the impact or probability of existing risks changed? Have some risks expired and now be closed? As the project progresses the impact from your key risks should diminish and that in itself is a sign of effective Risk Management and increasing chance of project success. 8.1 Risk management response You can decide to respond to, or manage, a risk in a number of ways, depending on its probability and likelihood. You can simply accept it. You can put in measures to reduce/mitigate the risk or really ramp up your response and try to ensure that the risk simply cannot happen. Suitable Risk Management responses are aimed at reducing the impact, probability or both. Typical responses break into broadly four types. These are: Remove/Prevent/Avoid terminate the risk by putting in place countermeasures which stop the risk from occurring or prevent it from having any impact, e.g. by doing things differently, using different resources etc.; Reduce take action to control the risk by reducing the probability or limiting the impact to acceptable levels; Transfer transfer the risk to a third party, e.g. via a specialist insurance arrangement with a third party. This response is relatively rare in practice; Retain/Accept/Monitor tolerate the risk, e.g. because nothing cost effective can be done to mitigate, or the probability and impact are already at an acceptable level. Risk Logs often state a single Risk Management response type representing the dominant or most important approach for the individual risk. The actions associated with this Risk Management response type may fall into any of the above response types but are not, typically, individually classified as such. For all Risk Management response types other than Retain/Accept/Monitor at least one action must be stated. Denial of risk is not a strategy that should ever be used. 8.2 Regular risk review All risks must be monitored monthly by the Project Manager and Risk Owner. The Project Manager should also review risks at the end of a stage as part of the stage sign off process. Monitoring risks enable the Project Manager to: check that the agreed mitigation/countermeasure actions are in place and are having the desired effect; identify, initiate and record any additional mitigation/countermeasure actions that are required; watch for early warning signs that a risk is developing, i.e. the probability and/or impact is increasing; identify and record new risks; identify and update risks that can now be closed. The result of this review may be to change the probability or impact of individual risks and therefore change a risk s overall score. Whenever an individual risk is reviewed the Last Review Date should be updated by the Project Manager. In addition to reviewing individual risks with Risk Owners the Project Manager should also review the Risk Log in its entirety with the Project Sponsor to ensure that the overall management of risk is being applied effectively. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 13

16 8.3 Risk management reporting Progress on Risk Management must be reported to Project Boards or other Governance groups as part of the regular reporting cycle. Typically Project Boards will be most interested in: RED risks where further action is required; AMBER risks where further action may be required; Risks owned by Project Board members; New risks; Risks that have changed since the previous report. The Project Manager should report on the most significant risks, generally those that are RED or AMBER, as part of the Highlight Report to the Project Board and in monthly Project reports. It is also good practice to ensure that Project Boards have ready access to the full Risk Log and can check this for themselves at any time to gain further assurance on the effectiveness of the Risk Management process. Often Project Boards will require a Risk Chart or other easy to use diagram which provides an overview of the current Risk Log if you can regularly update the Risk Chart or even automate its creation from the current Risk Log, it will be a valuable resource for Project Board members. 8.4 What happens when a risk occurs For each risk we must also define the contingency actions, i.e. those intended to come into force if and when the risk occurs. These can range from relatively simple measures, e.g. delay the project and/or hire additional resources, to a full blown contingency plan. If a risk occurs then it has become an issue for the project. In these cases the Project Manager must: Consult with the Risk Owner to determine the current situation (to help determine what subsequent actions may be appropriate; Inform and consult with the Project Sponsor; Review the contingency measures previously identified and determine, with the Project Sponsor and Risk Owner, whether these should now be invoked; Review the probability and impact of the risk recurring and reset these (if the risk can never now happen again the risk may be closed); For a risk that remains open, revise the mitigation/countermeasure actions and contingency actions; Re-plan the project taking into account the new issue. 8.5 Project closure At the end of a project all Risks must be closed or transferred either to the next phase of the project or to the standing Departmental Risk Register. At the final Project Board and Project Team meeting, agreement on the status of risks should be sought. Also, if relevant, these risks should be added to the Lessons Learned and Recommendations Report. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 14

17 9 Budgeting for Risk Management The project should allocate an appropriate budget, time and resources for effective Risk Management. It is particularly important that this is embedded into the Project Management process. This is best achieved by allowing sufficient time and effort for risk identification and assessment in the early stages of the project. PRINCE2 suggests that as much as 5% of project effort should be allocated to risk 3% for the initial identification and assessment and 2% for the ongoing management of risk. Although it is difficult in HE to find sufficient data to support this estimate, it is clear that many institutions underinvest in Project Risk Management particularly in risk identification and assessment. 10 Risk management checklist The following checklist can be used by the Project Manager and other stakeholders to review whether effective Risk Management is in place for a project: Item 1. Are overall roles and responsibilities with respect to risk defined and understood by the Project Manager, Project Sponsor and Project Board (or other governance group)? 2. Are the roles and responsibilities associated with Risk Ownership defined and understood by Risk Owners? 3. Is the Risk Log complete and credible taking into account the current status of the project? 4. Is each individual risk credible in terms of the probability and impact on project delivery and/or benefits? 5. For each individual risk, is the risk clearly owned by an empowered individual who has the authority in practice to progress the actions required to manage the risk? 6. For each individual risk, are mitigation/countermeasure actions clearly identified and likely to have the desired effect on the risk? Are the responsibilities for these actions allocated to appropriate and empowered individuals? 7. Are there contingency actions identified for each risk and are these credible? 8. Is the current impact and probability of each risk credibly assessed taking into account current mitigation/ countermeasures? 9. Are there any current RED or AMBER risks with no (or insufficient) assessment or contingency and/or countermeasures/mitigation actions? 10. Is there clear evidence that all risks are being regularly reviewed (at least monthly) by the Project Manager and Project Sponsor? 11. Are there hidden risks (or issues) that may be referred to in other project documentation or communications between project stakeholders which have not yet been moved into the Risk Management framework? Also review project estimates and look out for large variances in individual line estimates which may be due to unstated risks. These risks will remain unmanaged until they are formally recognised and recorded in the Risk Log. 12. At the end of the project are all risks closed? If not, who are they handed over to? In Place (Yes/No) 11 Final thoughts However hard you try, issues may arise that you had not allowed for. The important thing then is to take swift action to mitigate the impact. Having a risk aware culture and Risk Management infrastructure in place will assist you to do this. Example: A University recently implemented a new system for access to services. Shortly afterwards a phishing attempt was launched using a clone of the new system. The University quickly assessed the impact of this event and put in enhanced security measures to stop this happening again. Mark Twain had a riposte for Donald Rumsfeld: It ain t what you don t know that gets you into trouble. It s what you know for sure that just ain t so. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 15

18 Appendix 1: Aligning strategic risk with institutional risk It helps to achieve senior management buy in if Risk Management for IT projects and services is aligned to the wider institutional policy. Institutional documents and policies relating to risk, such as the institutional risk register, can be helpful in setting out a clear Risk Management framework for IT and change projects within the institution. For example, consider the Corporate or Institutional Risk Register. If the institution uses a 5*5 risk matrix for scoring impact and probability on corporate risks, it would make a lot of sense to use the same 5*5 risk matrix, with amendments to the category definitions where required, for IT and business change projects; The risk register may include explicit IT/IS related risks, e.g. on availability or information security. It makes sense to be aware of these when planning your own Risk Management strategy; If you are delivering a major or strategic project for the institution perhaps the project itself should feature on the risk register. Some institutional risk registers include a catch all risk relating to the governance and execution of major change projects then when these major projects come along they are added to the corporate risk register. The University of Edinburgh has published a number of its risk related resources online at schools-departments/governance-strategic-planning/governance/university-committees/court-committees/riskmanagement-committee These resources can be used to further illustrate the importance of aligning risk to institutional policy. The institutional Risk Management strategy or Risk Management policy, if one exists, can effectively underpin your Project Risk Management efforts. For example, the University of Edinburgh Risk Management Strategy: emphasises the importance of effective Risk Management for the institution; defines key roles and responsibilities for managing risk; sets a framework for Risk Management including actions and regular risk reviews. The institutional risk appetite or tolerance, which is usually part of the institutional risk policy, specifies the amount of risk the institution is willing to accept in the pursuit of its longer term objectives. The risk appetite indicates the parameters within which the University would want to conduct its activities. Risk appetite is normally stated at a granular level related to the nature of activities in the organisation. For example, the University of Edinburgh states its appetite for risk across the following activities: Reputation; Compliance; Financial; Research; Education and student experience; Knowledge Exchange; International development; Major change activities; Environment and Social Responsibility; People and culture. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 16

19 and states: In terms of priorities, the need to avoid reputational, compliance and overall financial risk will take priority over other factors e.g. it will be acceptable to undertake risks in research activities; Providing they do not expose the University to undue reputational, compliance or financial risk; A balanced assessment has to be taken of risks in many cases there are risks attached to both doing something and doing nothing; The University s approach is to minimise its exposure to reputational, compliance and financial risk, whilst accepting and encouraging an increased degree of risk in pursuit of its mission and objectives. It recognises that its appetite for risk varies according to the activity undertaken, and that its acceptance of risk is subject always to ensuring that potential benefits and risks are fully understood before developments are authorised, and that sensible measures to mitigate risk are established. Statements such as these are very helpful in clarifying the overall institutional approach to risk and provide a framework for establishing effective risk management for major IT and business change projects. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 17

20 Appendix 2: Risks in an Agile environment Risk management in an Agile Project is fundamentally the same as in an conventional Waterfall approach. However, Agile practitioners claim that using an Agile approach reduces many risks. With willingness to accept change within the Agile approach means that such risks as initial uncertainty about the required solution, the customers changing their minds and lack of clarity about the detail of the final product, are accommodated. Also, as the business accepts the evolving solution incrementally, reluctance to sign-off on the final product becomes less risky. However, certain other risks are introduced to the project approach. Agile requires consistent input from the business to which there may be a reluctance to commit. There may already be a detailed specification and a clear expectation of the shape of the final solution which is not compatible with the iterative and flexible nature of the Agile approach. This may be linked to the expectation that 100% of the solution can be delivered which the Agile approach, with its embrace of MoSCoW prioritisation, fundamentally rejects as it is seen as a key cause of project failure. There is likely to be swapping of resources in and out of an Agile Solution Development Team and it is important that key knowledge and expertise is not lost as a result of this the use of a Knowledge Management tool can help mitigate this risk. Agile practitioners advertise the use of Project Approach Questionnaires to identify risks to the process. Agile is an evolving methodology and adopters are advised to consult with fellow practitioners in the sector to ensure that they are taking appropriate steps to manage risk. B E S T P R A C T I S E G U I D E E F F E C T I V E R I S K M A N A G E M E N T 18