HANDLING A MAJOR RISK

A case study for the PRINCE2 Foundation and Practitioner course .

Contents
Introduction .................................................................................................................................................. 2
Challenges ..................................................................................................................................................... 2
The risk approach taken................................................................................................................................ 3
What happened next .................................................................................................................................... 4
Final Outcome ............................................................................................................................................... 5
Critical Success Factor ................................................................................................................................... 6
Benefit of the PRINCE2 approach ............................................................................................................... 6

1|Page

Introduction
A large Government department was conducting a strategically important project
using PRINCE21 to introduce new capability within its existing IT infrastructure.
Specifically, the new capability would enable secure identity management across
the various different systems used by the department, reducing duplication of
effort and the possibility of different information about individual members of
staff being held in different systems. This was a complex and novel approach, and
a specialist external supplier had been appointed to carry out much of the
detailed software development and hardware configuration, while business
processes and training were being developed using internal department staff.

Challenges
Part way into the project, a new risk was identified. It was becoming increasingly
likely that for political reasons there might be a significant restructuring of the
department. Potentially the department could be split into two or more parts,
each of which would become independent of the others.
This would cause a significant problem for the project. The business case had
been prepared on the basis of reduced staff effort, greater accuracy of
information, and a level of cost associated with implementation on a single IT
infrastructure. If the department were to be split, there was no certainty about
whether successor departments would want to continue with the system, and in
any case there would be significant extra cost involved with rolling the system out
across more than one IT infrastructure.
However, in terms of risk management, this was a particularly difficult area, since
decisions would be taken at the most senior political level, no contact was

2|Page

possible, and no reliable information existed about the likelihood, or detailed

nature, of the suggested changes.

The risk approach taken

The risk was formally entered onto the risk register, with an assessment of very
high probability and very high impact. The proximity could not be assessed. The
level of risk was above the projects risk tolerance line so it was immediately
escalated to the project board, using an exception report that set out possible
options for the project board, one of which was to stop the project immediately in
view of the potential for wasted cost and effort.
Risk identified by
Executive and shared
with Project Manager

PM allocated as Risk
Owner to monitor closely
and report

Project Board reviewed

options and chose an
"Accept" risk response

PM assessed the risk and

options

PM immediately
escalated to Project
Board using an exception
report

Figure 1: the PRINCE2 risk cycle as used in this situation

The project board reviewed the situation and considered the options carefully.
Because of the uncertainties, no reasonable fallback plan was feasible. They
therefore decided that on balance, the project should continue since the benefits
of achieving secure identity management were substantial, but that the changing
3|Page

political situation should be carefully monitored to give as much warning as

possible of any change. This was therefore an Accept risk response.

What happened next

Despite the monitoring put in place, with no prior warning the department was
restructured about 2 months later. The announcement was made overnight.
First thing the following morning the project manager met with the Executive to
discuss what needed to be done. Other project board members were remote
from the building, so the Executive set up an immediate telephone conference
call, and advised by the project manager the project board considered options.
Two significant problems had to be addressed. The external supplier was
charging on a time basis, so for the supplier to continue work could mean further
wasted costs. And there was no knowledge about the likely IT infrastructure
approach of one of the successor departments, which would effectively be a
merger with an existing, but different, department.
However, to either terminate or suspend the project immediately would
potentially cause additional costs in other areas, and would also make it difficult
to restart work should that become the correct course of action, since the
suppliers specialist staff would be redeployed elsewhere.

4|Page

Issue identified
PM immediately
escalates to
Executive

Project Board review

exception

Executive escalates
to Corporate Mgt

Options
considered
Level of tolerance
checked

Corporate mgt
consider Project
Board proposals
and approve

Figure 2 Immediate response to the issue

The project board decided the best approach was to continue with work in the
very short term, with weekly reviews of progress, while seeking clarification of the
future IT infrastructure arrangements of the successor departments. Given the
nature of the problem that had occurred, this would take the project outside its
tolerances, so the Executive met with corporate management to explain the
situation, the project boards thinking, and the proposed way forward, which was
approved by corporate management.

Final Outcome
After three weeks, there was still no clarity in some key areas, so the project
board decided that the project should be temporarily suspended. In coming to
this decision they recognised the specific risk that the suppliers specialists might
not be available once a decision to restart the project could be taken. Again, the
Executive met with corporate management to gain agreement to this approach.
5|Page

The project was eventually restarted, successfully delivering the secure identity
management solution to both successor departments.

Critical Success Factor

The critical success factor here was having the PRINCE2 structures for risk
management and for problem handling and escalation in place and understood by
all concerned, then being prepared both to use them and to modify them as
circumstances dictated.

Benefit of the PRINCE2 approach

The PRINCE2 principle of managing by exception provided a clear background to
this situation. It was clear to the project manager, the project board, and to
corporate management what the levels of delegation and flexibility were, and
therefore how decisions needed to be handled and who should be involved.
The risk management approach meant clear and early involvement by the project
board in deciding what to do once the risk had been identified. The decision
taken was the appropriate one given all the circumstances.
Once the risk materialised and became an issue a combination of the
PRINCE2 approach to issue handling and escalation and clarity about levels of
delegation meant that the right people were involved in decision making from the
outset. The decisions taken for a short term continuation of the project and
then later to suspend it were pragmatic given the substantial effect of the
change that had happened.

6|Page