Risk & Issue Management

Contents:

1. Overview
2. Standards
3. Differences for Programmes
4. Governance Roles
5. Risk Management Cycle
   1. Identify
   2. Analyse
   3. Plan
   4. Manage
   5. Review
6. Issue Management Cycle
   1. Identify
   2. Analyse
   3. Plan
   4. Manage
   5. Review
7. How2Guides

Failure to scan the horizon for dangers (threats) that could have been foreseen is a major cause of programmes and projects failing.

From the outset, the number and size of potential risks and their individual or aggregating effects should be analysed in the context of whether the programme or project is actually achievable and the chances of failure are acceptable.

• Risks are events that COULD happen and will have a negative impact on the programme or project
• Issues are events that HAVE happened and active management actions are being undertaken to solve the problem.

There needs to be thorough consideration of what the potential Risks are, why they are being affected, their potential impact on the project and how they will be communicated with.

As a minimum, all initiatives will have:

1. Maintain up to date risk & issue registers 2. Undertake and maintain the profile of the overarching level of risk 3. An estimation of the financial impact of the risks 4. Dependencies FROM other initiatives recorded as issues 5. Dependencies ON other initiatives recorded as a risk 6. Have an audit trail of issue resolutions 7. Maintain an audit trail of changes to scope and products

Risk management at programme level is different because:

1. The focus is on strategic and operational risk rather than project risks
2. There is an aggregated effect of risks across projects so requires different techniques
3. The need to focus on threats and opportunities to outcomes and benefits for the client
4. Setting standards and assurance compliance internally

 

Issue management at programme level is different because:

1. It focuses on issues that span a range of projects
2. Dependencies are external or inter project
3. Change control is focused on impacts on outcomes and benefits for the client

Role key:

Accountabilities	"Authorises" - provides the Board endorsement that the activity has been undertaken
	"Approves" - provides business approval of the result of the activity
Responsibilities	"Actions" - responsible for ensuring the activity is undertaken effectively, can be delegated
	"Advises" - provides guidance and help where needed
	"Assurance" - formal independent review

Click the stages in the cycle diagram to go to the relevant page:

Throughout the lifecycle there is guidance on the Risk theme and at each milestone you will find advice on specific areas to check.

There is a recurring cycle that should be followed throughout the lifecycle of the programme or project, this section provides advice to support this.

It is important to differentiate threats, which will always be there and the events that could trigger the cause and the effect.

The risk is a combination of the cause, the risk of it occurring (event) and the effect, i.e. if it happens then what will be the resulting damage that will occur.

 

Identify

It is tempting to create of list of things that could go wrong without standing back and thinking about the bigger picture or the knock on effects.

One of the amazing achievements of mankind is failing to learn the lessons of history, so for your programme or project we are going to do better!

When identifying risks you should consider doing the following:

• Check out what risks other programmes and projects have experienced and how they came about
• Research external organisations to find out what challenges they have faced on similar programmes
• Have a workshop of the key stakeholders to identify what the challenges are
• Ensure that the standard list of threats (see the Risk Breakdown Structure) has been included in the Risk Register

Ensure that any assumptions that are being made about the project and programme are registered as a risk. An assumption infers that there is uncertainty about something happening or being in place, so basically there is a risk that it won't be there.

This step in the cycle should produce the first Risk Register based on the standard template and the initial risk profile assessment can be completed.

This is set out in more detail in the how2guide.

Analyse

When analysing the risks there are a number of things you should consider:

Is this a threat, an event or an effect?  It is common for Risk Registers to be littered with the a mix	What is the probability of the risk happening?
If it happens what will the impact be on the programme or project?	What actions are needed to remove or reduce the probability or impact?
Who will take responsibility for these actions?	What is the time window during which the events could occur (proximity)?
What will the tracking and review arrangements be for each risk?	Check that it is a risk and not an issue, i.e. is it definitely going to happen?

 

The analysis will give you a good understanding of the size of the challenge and the things that could go wrong.  These should all feed into the planning process.

 

Plan

The plans for risk should be about managing risk to acceptable levels.  The last thing you would plan for is building sufficient contingency to react to each of the potential risks occurring. Normally this is established as part of the risk budget, a financial amount that is set aside to cope with a certain level of risks occurring.

The term "risk appetite" reflects the amount of risk you are willing to face and how many additional costs you are willing to incur to achieve the objectives.

For each threat, there should be planning response, these are normally:

Avoidance	Transfer it to someone else- e.g. insurance
Accept	Share it with another organisation or part of the business
Reduce	Prepare contingency plans, the response to take if the original response fails

 

There are different responses for opportunities:

Exploit	Share
Enhance	Accept

 

There should be clear escalation routes for handling risks, so that the plan can be activated rather than triggering panic mode.

One of the areas of planning that should be undertaken is scenario planning. It is very rare for a single risk to de-rail a programme or a project; it is normally a combination of events being triggered which cause the major problems.

There are two scenarios:

1.

The "domino" effect which is one risk developing, and subsequently having a knock on effect on another and so on. This is particularly relevant to programmes where the domino effect could happen across projects.

2.

The "cocktail" effect is where a situation could be the trigger for a number of risks to be activated, having an accumulating effect on the programme which is bigger than the sum of the individual parts.

To plan for this, it is useful to have a risk map which shows the potential relationship between risks.

 

Manage

This would normally involve the programme or project board reviewing an up to date Risk Register each time they meet to make sure the level of risk is containable.

If there are a lot of risks, it may well be that you are trying to manage a mix of threats, events and effects or there are many small risks that could be concentrated under some core risks.

Some areas to focus on when managing risks:

The use of "proximity" to avoid focusing on risks that are a long way off	Identify and track early warning indicators that can alert you to the developing exposure to it happening
Changing levels of likelihood	Changing levels of impact
New issues which could have a knock on effect to the risks

 

Review

A very simple measure of risk management effectiveness is size of the issue register.  If there are lots of issues then it is an indication that risk management is not working very well as at least a proportion of the nasty surprises should have been spotted in advance.

So when reviewing effectiveness some areas to consider are:

- What lessons have been learned?	Are people doing their actions and are they working?
Is the Risk Register becoming inflated by listing things that could go wrong rather than managing risks?	Are there early warning indicators and are they working?
Are the reporting/escalation routes still appropriate?	Is the issue register getting large and if so why?

 

 

 

Throughout the lifecycle there is guidance on the 'Risk and Issue' theme and at each milestone you will find advice on specific areas to check.

There is a recurring cycle that should be followed throughout the lifecycle of the programme or project, this section provides advice to support this.

Unlike 'Risks', which need to be identified and will have much ambiguity about their potential, issues will be turning up unannounced and provide an unwanted distraction at the most inconvenient times.  Therefore, better prediction and identification of issues at the outset will mean less time spent resolving them.

 

Identify

For issue management, it is more a case of ensuring that they are recorded and categorised so that their effect on the programme or project can be assessed.

In a programme, anywhere that there is a dependency between projects or outside of the programme should be managed as an issue.

For programmes and projects the following are the most likely places that issues will arise from.  As such make for useful categories when recording them:

Known issues or constraints at the outset	Stakeholder feedback
Request for change	Technical, e.g. IT or construction
Business process	Poor information
Staff or human resources	Supplier performance
Contract or procurement	Internal team performance or governance

 

Analyse

Once an issue has been identified and recorded the impact on the programme or project will need to be understood as well as the potential actions to resolve it.

There are a few areas that need to be analysed to get a full picture of the significance of the issue and the options for resolution.

There are a number of areas that need to be considered: 

The overall impact on the project or programme	What are the options for resolution?
The effect of the issue on other issues or risks	Priority - how soon does it need to be resolved?
What resources will be needed to resolve it?	What would be the timescales for the resolution option?
What are the knock effects of the resolution?

You can see there are a lot of things to consider when it comes to issue management.

 

Plan

It is very easy for a programme and project to accumulate many issues, particularly if there is a not a plan to manage them.

Planning for resolution of issues is principally focused on ensuring that there is a process in place for capturing, assessing and resolving them.

Ensure that a filtering process is in place to stop the issues register becoming unwieldy.  It may be that a separate change control group is set up to oversee changes or that some specific groups are in a position to take ownership and resolve certain kinds of issues, for example, relating to a business process.

 

Manage

The principle technique for managing issues is change control.  This is a distinct process that evaluates the issues, undertakes impact assessments and organises the changes to be implemented.

It is important that the overall number, type and severity issues remain within acceptable limits otherwise the project or programme's viability will disappear.

There is a danger that managing issues dominates the work of the programme or project team and as such there must be realism about how much can be achieved.

It is really important that all changes are tracked through the issue process - serious problems can occur when minor ad-hoc changes to costs or product specifications are being implemented without formal agreement.  The aggregated effect of minor changes can have a major effect on the functionality and viability of the final solution.

 

Review

This should take place, as a minimum, at each of the milestones.

It is a chance to stand back and take stock of the amount of issues and whether it is viable to continue with the programme or project.

When measuring effectiveness the following questions should be considered:

Are the numbers of issues being raised reflecting inadequate planning or preparation of specifications?	Are risk management processes working effectively to address potential problems before they become issues?
Will the changes impact on the ability to deliver the benefits?	Can business deadlines still be met?
Are there specific root causes that are generating the issues that need to be dealt with?	Are the right resources going to be available to resolve the issues satisfactorily?
Are there any risks that could soon become issues?	How effectively is the change control process working?
What lessons have been learned so far?