UCISA Toolkit - Effective Risk Management for Business Change and IT Projects

GOODPRACTICEGUIDE
Effective Risk
Management for
IT and Business
Change Projects

Universities and Colleges
Information Systems Association
University of Oxford
13 Banbury Road
Oxford OX2 6NN
Tel: +44 (0)1865 283425
Fax: +44 (0)1865 283426
Email: admin@ucisa.ac.uk
www.ucisa.ac.uk
Contents
1 Introduction 1
2 Definitions 2
3 Project Risk Management maturity 3
4 Roles and responsibilities 4
4.1 Responsibilities of the Project Manager 4
4.2 Responsibilities of the Project Sponsor and Project Board 4
4.3 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 10
7.1 Risk probability 10
7.2 Risk impact 10
7.3 Overall risk scoring and traffic lighting 11
7.4 Risk charts: probability versus impact 12
8 Risk management and review 13
8.1 Risk management response 13
8.2 Regular risk review 13
8.3 Risk management reporting 14
8.4 What happens when a risk occurs 14
8.5 Project closure 14
9 Budgeting for Risk Management 15
10 Risk management checklist 15
11 Final thoughts 15
Appendix 1: Aligning strategic risk with institutional risk 16
Appendix 2: Risks in an Agile environment 18
Acknowledgements 19

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

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 objectives1
.
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 Manager1
.
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 opportunities1
.
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 1-903494-13-3.

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.

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

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 Notes
The solution delivered by the project will
not be accepted by end users.
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.
The desired scope will not be delivered
within the agreed budget.
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.
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.
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.
The existing IT infrastructure will not
have sufficient capacity to adequately
support the new or updated services
delivered by the project.
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.
The external supplier engaged on the
project will not deliver products of the
required quality.
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.
Key members of the Project Team and
Board leaving.
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.

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.

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.

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.

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-2014
2 Solution components delivered by
Business Process (RE S052) are delayed
High Medium AMBER Open James Thin 13-Oct-2014
5 Solution components delivered by Finance
Integration (RE S054) are delayed
High Medium AMBER Open Jill Nicoll 16-Oct-2014
3 Unacceptable Performance in TEST and/
or LIVE Environments due to scale of
UoE requirements relative to existing
customers
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 2015. Delays of more than two weeks are likely to cause slippage in the go-live date of 16th June 2015.
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:
zz failure to agree business requirements early enough to complete development
zz resourcing challenges for external supplier
zz resourcing challenges for ERI/RGS
zz resourcing challenges for IS
Risk reduction/mitigation strategies will focus on these most likely causes.
Date Identified: 16-Oct-2014
Date of Last Review: 07-Nov-2014
Probability: Medium
Impact: High
Management Approach: Reduce
Risk Owner: Susan Coleman
Contingency:
There is approximately two weeks scheduled contingency in the plan to accommodate delays in delivering components for
system testing in March 2015. Delays of more than two weeks are likely to cause slippage in the go-live date of 16th June 2015.
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.

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
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.
2 – LOW Small chance that this risk will occur –
event is unlikely to happen
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.
3 – MEDIUM There is a moderate chance that this risk
will occur
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.
4 – HIGH There is a strong chance that this risk will
occur
This event is more likely to occur than not, within the lifetime of
the project.
5 – VERY HIGH There is a very strong chance that this
risk will occur i.e. almost certain.
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
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.
3 – MEDIUM Significant impact and potential to
benefits
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.
4 – HIGH Major/severe impact. Potential to
adversely affect overall project costs and
benefits to a significant degree
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.
5 – VERY HIGH Extremely significant impact. Likely to
benefits to a major extent and possibly
lead directly to project failure
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.

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.
8 – 14 UNDESIRABLE AMBER To be avoided if reasonably practicable, investigation
required, monitoring essential and mitigation
recommended. Medium level of risk.
15 –25 UNACCEPTABLE RED Intolerable, must be mitigated or transferred.
15 – 20 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 Recommended Minimum Action
GREEN Project Manager and Risk Owner continue to monitor.
AMBER Project Manager and Risk Owner to review, identify further mitigation actions and escalate if
required.
RED Project Manager and Risk Owner to review, recommend further mitigation actions and escalate to
Project Sponsor and Project Board for further review and approval.

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:
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.
Risk Chart
High
Medium
Low
Likelihood
HighMedium
Impact
Equipment failure
Security breach
User resistance to change

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.

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.

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 In Place (Yes/No)
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?
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”.

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 http://www.ed.ac.uk/
schools-departments/governance-strategic-planning/governance/university-committees/court-committees/risk-
management-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.

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.

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.

Acknowledgements
Simon Geller, Senior Project Manager at the University of Sheffield, is the lead author for this guidance.
The guidance has been greatly improved by the input of colleagues at the University of Sheffield and committee
members of the UCISA Project and Change Management Group. The author would like to acknowledge and thank the
following individuals for their contribution:
Mark Ritchie, Deputy Director and Head of Project Services, University of Edinburgh
Pauline Woods-Wilson, Head of Project Management and Planning, Lancaster University
Sally Jorjani, Project Manager, Edinburgh Napier University
Tricia Hayes, Project Manager, Information and Communication Technology, The University of Bedfordshire

UCISA Toolkit - Effective Risk Management for Business Change and IT Projects

More Related Content

What's hot (20)

Similar to UCISA Toolkit - Effective Risk Management for Business Change and IT Projects (20)

More from Mark Ritchie (15)

Recently uploaded (20)

UCISA Toolkit - Effective Risk Management for Business Change and IT Projects