Risk Management

Identifying risk

Risk identification is of course the first step in managing risk but it is an area that brings to the fore all of the emotional baggage discussed earlier. The very mention of risk can raise senior managers' blood pressure by a few points.

It is obvious that if you don't think about the possibility of something occurring you can't act on it and plan for it but risk identification is a good example of the 'shooting the messenger' syndrome we noted earlier. In immature organisations, or those where a 'blame culture' is prevalent, a project manager can be treated as if s/he caused a risk just because they highlight its existence.

At the risk of labouring a very obvious point you don't create risks by identifying them. You are simply revealing them so that you can do something about them. In many cases the risks may relate to organisational strategy, to key decisions already taken or to other things that are going on within the organisation and it may be uncomfortable for senior managers to see some of these issues brought into the open. There is no way round this.

We need to raise awareness of risk management techniques and create risk robust cultures within our organisations if we are to run successful projects. It is assumed that you are using a structured project management methodology and this will provide a range of information sources to help you identify areas of risk.

If you are unsure about any of the terminology used here you should consult the project management guide. Risk identification and analysis should be ongoing throughout the project but particularly at project start-up and stage boundaries. You are likely to start looking for risks relating to:

The project plan
Stakeholders
Resources
The organisational environment
The external environment.

The risk profile will change as you move through the project so risk identification and review should be an ongoing task rather than a one-off event. All too often risks are logged at the start of a project then never updated.

Project plan

The project plan is one of your key sources for identifying risk. You should understand the importance of the critical path through the plan (the shortest time needed to complete the project) and the nature of task interdependencies. The following are areas which are likely to have associated risks:

Tasks that rely on the completion of other work before they can begin
Tasks that none of the project team has ever done before
Use of unfamiliar technologies
Tasks that involve third parties
Migration of data from one system to another
Reliance on suppliers to deliver software upgrades at a specific time
Availability of key decision makers at critical points
Decisions that involved more than one department/team
Resources/staff that are outside your direct control
Any component of the plan based on assumption rather than fact.

If you are following our advice you will be using the concept of the 'sliding planning window'. This means only planning ahead so far as is feasible and sensible at the time. At the start of the project there will be much that you don't yet know. Once again senior managers and key stakeholders must understand the nature of the uncertainties because of course uncertainty means risk.

A major problem in many projects is the desire of senior managers to see a detailed plan at the start of the project and to 'freeze' that plan at too early a stage. This is not intended to provide any kind of justification for poorly planned projects where scope creeps and timescales drift; it is simply stating that, in the real world, even the best planned and managed projects will have to cope with uncertainties and changes.

In addition to risks associated with your particular plan there are a range of risks that tend to beset any project in the education sector. These risks need to be addressed in the early stages of planning.

Recruitment and retention of project staff
Space and facilities for project team
Part-time project staff who are distracted by the 'day job'
Decision making processes unclear or very slow
Involvement of consultants who are not familiar with the education sector.

Stakeholders

You should by now have identified who are the stakeholders in your project or initiative and undertaken an analysis of their likely perceptions of the project and attitudes to it. A stakeholder analysis template is available.

In any undertaking involving a substantial amount of change there will undoubtedly be people who are adversely affected or who fear they will be disadvantaged by the change. These people can be termed adverse stakeholders and they may present a risk to your project. The risk may be in terms of direct opposition to the project at the initiation stage or a 'war of attrition' during the course of the project.

Here are some examples of people who are likely to be adverse stakeholders are people who:

Fear loss of their jobs
Will require retraining
May be moved to a different department/team
May be required to commit resources to the project
Fear loss of control over a function or resources
Will have to do their job in a different way
Will have to carry out new or additional functions
Will have to use a new technology.

In thinking about adverse stakeholders don't forget your own project team if they are overworked or under resourced. The risk presented by any of these individuals depends on their authority within the organisation and their influence on the project. The stakeholder analysis template will help you identify this and help plan the involvement of, and communication with, key stakeholders.

Organisational environment

Risks associated with the organisational environment may be general or specific. General risks relate to the organisational culture, eg, are you trying to introduce innovative change into a bureaucratic or reactionary organisation? This background information should be known and planned for although it may take a project manager new to the organisation some time to get to grips with the complexities of its structures and power centres.

Specific risks are associated with the organisation's mood at this point in time. For instance are you trying to undertake a system implementation shortly after a similar project has gone badly wrong or trying to introduce process change at a time when organisational restructuring is causing concern about potential job losses?

This situation needs regular review because the successes or failures of initiatives elsewhere in the organisation can impact on your chances of success. Here are some typical examples of circumstances that may cause risk to your project:

A similar project has failed in the past
The organisation is being restructured whilst the project is in progress
You have funds to spend while others are being forced to make cuts
Many related projects are going on without effective programme management
Your require resources/action from people over whom you have no authority
There is about to be a new postholder in one or more senior management positions
One or more core IT systems is changing
Expansion/merger/location moves are taking place
Your organisation is involved in an OFSTED inspection, quality review or compilation of data for the Research Excellence Framework whilst the project is going on.

External environment

The larger and more complex your project or initiative is, the greater the risk that changes in the external environment may affect it. Senior managers and those responsible for organisational strategies and plans should of course be scanning the external environment routinely. The sorts of external factors that may cause risk to individual projects or prompt changes in strategy are:

A change in government
A change in the funding model
New legislation eg, relating to Data Protection, Freedom of Information, Disability, Health and Safety
A change in the market for particular subjects
Economic recession in a country that provides a large proportion of your overseas students
A competitor merges with another or changes its course portfolio
A major system supplier goes out of business.

There are of course risks that fall outside these categories specifically the risk of a major disaster. Disaster planning, or business continuity planning, falls outside the scope of this guide although many of the principles of risk management outlined here are essential in preparing an effective business continuity plan.

It is advisable to involve as many people as possible in the risk identification process and to have some form of external validation of the outcome. Remember if you are the project manager then your evaluation will be emotionally coloured to the same extent as anyone else's. In practical terms this means you may be inclined to 'downgrade' serious risks because you want the project to go ahead.

Staff not directly involved in the project can often act a 'devil's advocate' to question your assumptions.

The suggestions above can be used to help you develop a checklist for risk identification but you also need to think about what is unique about your project. The danger of generic checklists is that you go through ticking the boxes in a formulaic way and fail to do enough thinking. This project may be similar to others you have done but you need to focus on the differences – what makes this one unique?

It is sometimes better to use the generic checklist to review your answers at the end of the exercise ie, after you have thought about the project in unique terms.