Founded in 1807, JohnWiley & Sons is the oldest independent publishing company in

Start Pgr
1
Gross and net loss severity
reduction at group level 
F I G U R E 1 6 . 1
Severity reduction – group level
This simple study shows why impact assessments of risk management activ-
ities are easy, useful and recommended.
(
Continued
)

---

178
RISK MONITORING
Start of PGR
2
Overall decrease of loss frequency
F I G U R E 1 6 . 2
Average loss frequency

---

PART
Five
Rising Operational Risks
“Nothing novel or interesting happens unless it is on the border between
order and chaos.”
R.A. Delmonico
Operational Risk Management: Best Practices in the Financial Services Industry, First Edition.
Ariane Chapelle.
© 2019 John Wiley & Sons Ltd. Published 2019 by John Wiley & Sons Ltd.

---

CHAPTER
17
Project Risk Management
C O N T E X T
Projects and change are some of the most commonly cited sources of risks in organiza-
tions. Beyond the multitude of risks brought by new processes, new technologies, lack
of familiarity and resistance to change, we have all experienced projects overrunning
and exceeding budget, if not failing completely due to causes such as weak governance,
unrealistic deadlines, short-sighted budgeting, poor synergies, lack of internal skills or
team stamina, and conflicted interests.
PRINCE 2 lists the most common causes of project failure (Table 17.1). Each
project failure can cost an organization thousands or millions in wasted resources and
untapped future revenues. Yet these sums are usually overlooked and not recorded as
what they are: severe crystallizations of operational risk.
It is therefore good practice for the risk function to be involved at the start of a
project and to remain present throughout the project life cycle, right through to debrief-
ing. The actual level of involvement should depend on the risk exposure and criticality
of the project.
This chapter is based on my experience of assisting firms in framing or improving
collaboration between the operational risk function and the project teams.
S T A G E O F I N V O L V E M E N T O F T H E R I S K F U N C T I O N
I N P R O J E C T M A N A G E M E N T
I n i t i a l S t a g e , B e f o r e K i c k- o f f
Although the project decision-making and stage-gate processes are well established in
many organizations, they are not as embedded and rigorous as they should in some tier
2 or tier 3 firms. In these instances, risk management should play the role of gatekeeper
and enforce a sound decision-making process prior to each non-trivial project launch.
Even in firms where project decision-making and governance are well established, the
181
Operational Risk Management: Best Practices in the Financial Services Industry, First Edition.
Ariane Chapelle.
© 2019 John Wiley & Sons Ltd. Published 2019 by John Wiley & Sons Ltd.

---

182
RISING OPERATIONAL RISKS
T A B L E 1 7 . 1
Common causes of project failures (PRINCE 2)
1
1. Invalid business case.
2. Insufficient attention to quality at the outset and during development.
3. Insufficient definition of the required outcomes, creating confusion.
4. Lack of communication with stakeholders and interested parties.
5. Poor definition or acceptance of roles and responsibilities, resulting in lack of direction.
6. Poor estimation of duration and cost.
7. Inadequate planning and coordination of resources.
8. Insufficient measurables and lack of control over progress.
project team or the business don’t always dedicate sufficient attention to the additional
risks generated by a new project beyond the project delivery risks themselves. What is
missing is proper involvement of the second line of defense. When project risk man-
agement matures, the role of the risk team is to help the project team with project and
execution risk identification and assessment. This includes mitigation action plans and
regular assurance and reporting, much like an RCSA. The RAU here is the project itself
and its consequences for the day-to-day business operations.
When this is absent, the risk team should establish a full project approval process
(Table 17.2), much like a new product approval process. Indeed, launching a product
is a particular type of project.
The risk level of the project will dictate the degree to which the risk function is
involved and the extent of the mitigation requirements. This risk-based approach can
typically follow a risk-rating methodology common to non-financial risks. Examples
of risk-rating scales and criteria are detailed in the next section.
P r o j e c t L i f e : M o n i t o r i n g a n d R i s k U p d a t e
The monitoring structure introduced at the beginning of the project should remain dur-
ing the project life – again, much like RCSA monitoring and updates. There should be
quarterly or six-monthly updates of the risk identification and assessment workshop
with the risk team and the project team, which amongst other things will cover project
risks that may affect business as usual operations. The project team itself usually man-
ages the typical project risks of time, budget and delivery quality, without intervention
from the risk function. A regular project report on both execution risks and project risks
is sent to all project stakeholders, including the risk function.
1
Modified table from PRINCE 2, cited in Chapman, R. (2014)
The Rules of Project Risk
Management
, Gower.

---

Project Risk Management
183
T A B L E 1 7 . 2
Information requirements before project approval, from a risk management
perspective
1. Project motivation
and objectives
Qualitative and quantitative assessment of expected benefits
2. Budget
Expected external costs (third-party fees and equipment)
Internal costs (man-days from existing resources)
3. Cost-benefit analysis
From the analysis above
4. Impact scope (direct
and indirect)
People (staff, customers, stakeholders) and processes impacted
directly and indirectly by the project
5. Top risks for the
outcome of the
project
What could go wrong?
Scenarios with likelihood scale
(H – M – L in a simpler form)
+
quantified approximated impact
for all
important
and
critical
projects (see rating scale further
below)
6. Planned mitigating
actions for top risks
E.g., internal controls, insurance policy, backup plan and/or exit
strategies
7. Reporting to the risk
function and the
business
■
Evolution of risks
■
Mitigating actions
■
Action owner and timeline
■
Milestones and deliverables
■
Benefits expected or produced
■
User satisfaction
8. Reporting to project
team
■
Timing, delays and contingencies
■
Spending against budget
■
Rules of descoping/rescoping and reporting of breaches
■
Progress report
9. Steering committee,
sponsor and
designated project
manager
Risk-based rule, e.g.:
■
Fully dedicated (100%), professional and experienced
project manager (with relevant experience) for
critical
and
important
projects
■