M a n a g e m e n t o f e n gi n e e r i n g P rojects

Chapter 8 ! overview
Because every project is a unique endeavour, every project contains uncertainties. For project
success those uncertainties that can endanger a project need to be managed. Those uncer-
tainties that matter are called risks. In contrast to the common use of the word ‘risk’, which has
a negative connotation, in projects a risk can either be a threat or an opportunity. Although
most people have some idea of what risk management entails, clear language and processes are
sometimes difficult to understand and/or apply in practice. This is also clearly related to human
factors, subjectivity and interpretation.
The chapter discusses the why, the what and the how of risks and risk management. With tips
and tricks provided throughout the chapter, readers will be able to apply risk management in
their own projects.

Chapter 8 ! outline
8.1 Why risk management?
8.2 What is risk management?
8.3 How to method
8.4 Risks and range estimates
8.5 Getting started
8.6 People are key
8.7 The case for risk management

134

925836-02_152_17-Feb-15_08:42:33_walter
 the scene and money at work

Chapter 8
Project risk
management
by Roald Arkesteijn and Herman Mooi

8.1 ! Why risk management?

Why is risk management crucial for managing projects? The most important reason is related to
the essence of projects. As discussed in Chapter 1, a project is by definition unique and therefore
it comes with many uncertainties. Those uncertainties that matter are referred to as risks and
risk management is about managing those uncertainties that can harm the project outcome. In
that sense risk management contributes to increasing the overall value of the project to its stake-
holders amongst others by maintaining better control of the project.

Hence risk management is strongly related to uncertainties. A clear trend is an increasing com-
plexity in society in general with its related uncertainties (see Chapter 7). This trend also clearly
touches the performance of projects, as can be seen from the huge variety in increasingly com-
plex projects with a higher risk profile. Often risks are not very well evaluated upfront and/or they
are underestimated. This is one of the main reasons for having (so-called) unsuccessful projects.
As a consequence the reputation of projects is not very good. On top of the intrinsic complexity
of projects, the highly complex projects often span multiple years or even decades (especially if
one also includes the operating phase), and they will be subjected to changes in the environ-
ment. This clearly increases the risk profile of the projects.

Although this book is dedicated to engineering projects, it is important to realise that project
risk management can steal a page from other areas where risks play a role. Although they seem
different, there are often many parallels to be taken from these fields. Below a few examples will
be discussed.

The first example is the financial business: most people know that risk management plays or should
play a dominant role. Typically, high risks come with high value and low risks with lower value.
Therefore a balance needs to be made to optimise risk and value. In order to do so, the risk profile
of financial transactions or a financial portfolio is investigated. Due to the quantitative character of
the financial business, one will find a larger focus on quantitative risk management. On the other
hand, engineering projects more often deal with risk management in a qualitative way.

135

925836-02_153_17-Feb-15_08:42:34_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

Another example stems from human healthcare. Although the terminologies of risk management
and human health do not seem to match, while one is more rational than the other, it is com-
mon practice to analyse the balance between healthcare costs and impact on life expectancy.
If a doctor would request a full body scan for every headache or cough, healthcare costs would
be unmanageable. The trend in the human healthcare industry is therefore towards risk screen-
ing studies on specific populations. Known examples are breast cancer and heart and vascular
diseases. In the risk screening approach, doctors also use standard criteria that balance between
accepting the risks versus further diagnosis.

The third well-known example is from the process industry: for all large plants and clearly also
for nuclear power plants extensive risk assessments are performed. Society needs to know that
these plants are safe. Still, everybody realises that they cannot be 100 % harmless. We all accept
that with a certain very small chance a large disaster can happen. Clearly, these risk assessments
are used to minimise the risks for something going wrong at some very low level. The same
holds for the safety of a country like The Netherlands with respect to flooding. All dikes and other
water protection devices are assessed for their risk: the chance that a dike breaks through and
the effect thereof. Still we all accept the risk of our city flooding once every 1000 years (more or
less consciously).

So basically, risk management is very present in our own day-to-day lives. We take risks by rid-
ing to work on our bikes, jumping on trampolines, climbing mountains, etc. Simply avoiding
every risk makes normal life impossible and therefore we (subconsciously) continuously assess
situations, determine the risks and decide on the action required. This is why we have cars with
seatbelts, install antivirus programmes on our PCs and insure our homes against fire. Luckily,
realising this might help us approach risks in a project environment in a more natural way.

8.2 ! What is risk management?

What is a risk?
For risk there are many different views and interpretations, but current definitions more and
more iterate towards each other. The PMBOK (Project Management Body Of Knowledge) provid-
ed the following definition of a project risk:

‘…an uncertain event or condition that, if it occurs, has a positive or a negative effect on
at least one project objective such as time, cost, scope or quality. A risk may have one or
more causes and, if it occurs, one or more impacts.’

The above definition is rather concise, but it still contains all necessary aspects that are discussed
below.
• Positive and negative effect – The formal definition of a risk in most dictionaries is related
to something negative. Therefore, risk management is often seen as a method to prevent
events with negative effects from occurring. If you are managing a project by only focusing
on the uncertainties with negative effects, the value of the project can only be maintained or
decreased. On the other hand, if a risk is seen as an uncertainty that can both have negative
effects (threats) but also positive effects (opportunities), managing risks can lead to increased

136

925836-02_154_17-Feb-15_08:42:36_walter
 the scene and money at work

Cause Event Effect

Circumstance
Result of
or event that exists Possible event
the event which has
today and provides that might or might
an impact on the
uncertainty to not happen.
project objectives.
the project.

Figure 8.1: Cause-Event-Effect structure of a risk

value. Clearly upside and downside risks must be distinguished. This can be done by just call-
ing them upside and downside risks; in practice this is sometimes done by calling them threats
and opportunities.
• Cause – event – effect – The definition refers to an event (or condition) with a related effect
(or impact). The cause is something that exists today that gives rise to uncertainty of an event
happening that has an effect in its turn. This meta-language proves to be very beneficial in risk
management, as can be seen from the fact that this meta-language is seen as a best practice
in larger industries (see Figure 8.1).
• Objective (or value driver) – Every project is undertaken with a certain objective in mind. This
is also often formulated as to create value. The value is then represented by value drivers
(see Chapter 6). For managing the project in general it is important to have the objective in
mind, but also for risk management it is important to be clear on what this objective exactly
is. The reason for that is that only those risks that have an effect on the project objectives
(value drivers) need to be taken into account. Or put differently: risks are those uncertainties
that matter for a project. There are many more other uncertainties, but as long as they do not
influence the objectives or value drivers of a project they do not need to be on the radar of the
project lead. The main objectives or value drivers of projects are:
– Sustainable development ( Health, Security, Safety, Environment, Reputation)
– Scope
– Time
– Cost
– Quality

The objectives or value drivers are used again to rank the impact of a risk in order to better
understand the importance of a project risk, see Paragraph 8.4.2.

Risk or issue
In practice, risks and issues are often confused. Theoretically, the difference is clear: a risk can
or cannot happen and an issue is already there. It is described above that a risk has a chance
of occurring, which means that it might or might not take place, with the chance of occurring
being anywhere between 0 % and 100 %. An issue however, is something that is going to happen
or has happened already. It therefore has a 100 % chance of taking place. The main reason for

137

925836-02_155_17-Feb-15_08:42:36_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

the fact that risks and issues are confused is that they both endanger the project outcomes. To
some extent our brains, apparently, are tempted to throw the two on one pile. Another reason
why they are sometimes interchanged is the fact that the chance of occurring feels different to
different individuals. For some people a 80 % chance of occurrence is almost already a certainty
so that the related risk really ‘feels’ like an issue.
Common project management methods introduce risk registers for filing the project risks and
issue registers for the issues.

Risk or hazard
The difference between a hazard and a risk is more than just a word game. In short, a hazard is
the possibility of causing harm (the cause), while a risk is the event (with a probability) of harm
occurring. Thus a hazard requires exposure before it becomes a risk. For instance, a car has a
chance of becoming involved in car accidents where the other cars – or driving in general – can
be seen as hazards.

International standards
Throughout the industry, the perceived importance of risk management has continuously
increased over the years. This trend has led to the development of several, (very similar) stand-
ards on project risk management. The better known ones are described below.
The International Standard ISO31000 provides principles and generic guidelines on risk manage-
ment. It is not specific to any industry or sector. This standard consists of two parts: an overview
of all risk management aspects in ISO31000 and guidance on 31 different risk identification tech-
niques in ISO31010.

The Project Management Institute (PMI) is a not-for-profit membership association for the
project management profession. They provide globally recognised standards and certification
programmes, academic and market research programmes, communities of practice and pro-
fessional development opportunities. Part of their standards is grouped in the PMBOK guide
(Project Management Body of Knowledge). One of the chapters in this guide is about project risk
management.

PRINCE (PRojects IN Controlled Environments) was originally developed for ICT projects in the
United Kingdom. Later on it was updated to PRINCE2 so it could be used outside the ICT indus-
try as well. PRINCE2 is a set of project management methods that are based on principles like
phased development, the steering group and management by exception. Risk management is
one of the seven themes of PRINCE2.

8.3 ! How to method

While the previous two paragraphs were dedicated to the why and the what, it is time to find out
how risks should be managed. This is explained in this paragraph using a five-step process similar
to the ones used in industry standards (e.g. PRINCE2). The risk management process is shown in
Figure 8.2. The five steps are discussed in the subsequent paragraphs.

138

925836-02_156_17-Feb-15_08:42:42_walter
 the scene and money at work

Monitor /
Identify Assess Plan Implement
improve

Figure 8.2: Risk management process

8.3.1 Identify
The first step in risk management is the identification of the risks present. In line with the defini-
tion of risk it is important to use the meta-language to describe each risk:

As a result of <definite cause>, an <uncertain event> may occur, which would lead to an <effect
on the project objectives or value driver(s)>.

It is important to realise that there might also be more causes for one risk or a chain of causes and
also that there might be multiple effects. For a good formulation of a risk obviously it is impor-
tant to be complete, but on the other hand the descriptions should also not be too detailed nor
over-complete. In the latter case one would lose focus on the real essence of a risk. The cause(s),
the event (the risk) and the effect(s) can also be given in different columns in a risk register.

The ISO31010 refers to many different identification techniques, including HAZOP (HAZard and
OPerability study), Delphi and interviews. The most common techniques in projects are brain-
storming sessions, lessons learnt and the use of checklists. The different methods can be used
alongside each other.

For brainstorming it is important to realise that it relies heavily on people and how they interact.
This means that for risk identification, it is best to sit together and brainstorm through possible
risks. Preferably people are present across the range of interfaces in a project from the current up
to the later phases (including operations). It is best to have a face-to-face brainstorm session for
which several systems exist such as:
• interactive computer tools so people can work simultaneously
• using sticky notes so all participants can brainstorm simultaneously or
• writing down each risk one by one while the other participants listen.

The advantage of a brainstorm session (with the whole project team) is that people buy in to a
project and its risks by collectively going through the risks. In the process of brainstorming, make
sure:
• every participant has a voice, avoid rejecting risks in the identifying stage in order to keep
ultimate creativity and openness of the whole group
• not only technical risks are dealt with and
• sufficient time is taken before moving on to assessment
• discussions of likelihood and impact are saved for the next phase (Assess)

139

925836-02_157_17-Feb-15_08:42:42_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

Another option is to have an individual risk assessment session. This can be done as a prepara-
tion for the ‘live’ session to save time or to replace the ‘live’ session all together. The advantage is
that you will have less group bias and the downside is that you will miss out on the opportunity
to discuss and therefore people might interpret the same risk differently. Besides brainstorming
sessions, a second option is to use lessons learnt from previous projects. Similar to the individual
brainstorm process described above, it is used as preparation for a live session, the extraction
of relevant lessons learnt from previous projects can be done upfront to serve as input into the
brainstorm session.

A third option is to use checklists in which several risk categories are distinguished with the aim
to having your risk inventory cover all relevant types of risks. One popular method is TECOPS
which stands for: Technical, Economical, Commercial, Environmental, Political and Sustainable.
The ‘ECOPS’ risks can be seen as ‘non-technical risks’ (NTRs) which is a relatively new term in
engineering.

One might ask why it is necessary to come up with another definition for something that is
already defined. This is related to the trend in recent years of the increasing social awareness
of industrial projects, their impact on their environment as well as an increase in the amount
of stakeholders involved (e.g. joint venture partners, different governmental bodies, NGOs, local
residents, suppliers, contractors, shareholders, employees, customers). Therefore the focus of
NTRs is on community-related issues, sensitive environments and a large amount of stakehold-
ers. This means that NTRs are most applicable to those industries that have a significant impact
on the environment, communities they operate in or having numerous stakeholders. Typical
examples are energy production (such as wind turbines), infrastructure construction and oil and
gas production.

Another checklist that can be used is the Work Breakdown Structure or schedule if available. Both
can be used to go through each activity on the WBS or schedule to identify possible risks.

The Wind Farm – Risk identification examples

The project team has identified two risks related to the communities near the
construction site. The risk formulation makes use of the meta-language.

Opportunity
As a result of the high human resource requirements for the maintenance of wind
turbines, many local residents might become employed, which would lead to an increase
in local support.

Threat
As a result of the wind farm being near shore, local residents might be against the
project and start to protest, which would lead to significant schedule impact (e.g. delayed
permitting) and a reputation impact on national level.

140

925836-02_158_17-Feb-15_08:42:44_walter
 the scene and money at work

8.3.2 Assess
Now that a list of risks is available to the project, it is important to start analysing and ranking the
risks. This is a quantitative step. The reason for this is that quantification enables objective prior-
itisation and gives an idea of how much implementation effort/costs mitigation would require.
The best known method of quantification is to split up a risk into the product of likelihood of
occurring times the size of the impact:

Risk = likelihood of occurring x size of impact

One can see that the application of the meta-language is beneficial for this step. It is because
in risk phrasing the event (with a certain likelihood of occurring) and the effect are specifically
separated. A graphical way to represent risks based on the likelihood and impact, is a risk assess-
ment matrix (RAM), see Figure 8.3. The colour coding shows which risks are acceptable (white,
gray, and pale blue), which might require mitigation (dark blue) or which ones will have to be
mitigated (black). The consequence is typically seen as more important than the likelihood; this
is the reason why a typical RAM is not symmetric but skewed towards effect. This is especially
true for safety related risks.

The likelihood scales used in the RAM matrix depend on the industry, project size, duration etc.
Some examples of likelihood scales are:
• Qualitative: ‘Remote / rare / unlikely / possible / likely’ (or sometimes the categories are num-
bered: 1 to 3, or 1 to 5)
• Quantitative: 0 - 5 % / 5 - 20 % / 20 - 50 % / 50 - 80 % / 80 - 100 % or ‘Occurs in: 1 in 100 projects
/ 1 in 20 projects / 1 in 2 projects / 2 in 3 projects / every project)’
• Mixed: ‘Never heard of in the industry / happened in the industry / happened in the company /
happened in the past year at the company / frequently occurred last year at the company’

Likelihood

Impact rating remote rare unlikely possible likely

Figure 8.3: Example Risk Assessment Matrix (RAM) (from ISO31010)

As the consequence should always be related to an objective or value driver (why else would one
care about the risk), the impact rating for a risk is related to the main objective or value driver for
that risk.

141

925836-02_159_17-Feb-15_08:42:44_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

In the estimation efforts it is again important to recognise human behaviour. This results for
example in bias and anchoring phenomena. Often people already have a gut feel, based on their
own experience, what the final outcome of the risk assessment should be. This can result in
(group) bias to the outcome in discussions. To reduce this effect, it helps to split the assessment
into two phases; first assessing the likelihood for all the identified risks and second, identify their
impact rating (while the likelihood is shielded off).

Secondly, anchoring is done subconsciously by people when they do not have sufficient knowl-
edge of a specific area. It describes the human tendency to use the first piece of information
offered (the ‘anchor’) as the reference point. An example: Asking a group of workshop partici-
pants to estimate the mean time between pump failures. If the question is asked ‘more or less
than a year’ versus ‘more or less than 10 years’, the typical estimate after the first phrase will be
significantly lower compared to the second one.

8.3.3 Plan
The next step after identification and assessment is to plan the response. At this level it should
be decided who owns the risk, what will be the risk response strategy and when these respons-
es should be executed. Since it is unsure whether a specific risk really is going to happen, it is
important to decide deliberately whether or not to respond to a risk and how.
The risk owner is typically the person (or organisation) who is best situated to deal with the risk.
This is not necessarily the person who executes all the actions. Note that in the end the project
manager is always accountable for all risks and in that sense she owns all risks.
Once a risk is identified and assessed a risk response strategy should be chosen for dealing with
the risk. In general, there are multiple strategies possible for dealing with risks. These strategies
are different for upside and downside risks (opportunities and threats); they are listed in Table 8.1.

Depending on the chosen risk management strategy, the new situation is not necessarily risk-
free. The first possible consequence of the risk response is that the risk likelihood or consequence
has been reduced, but not brought down to zero. This means there still is – what is called – a
residual risk.

A second result from a planned response could be a so-called secondary risk. This risk was not
present before, but rather it is a result of the chosen risk management strategy. These risks should
be included into the risk register as well (see Paragraph 8.3.1).

While discussing on risk planning, it is important to mention both the residual and secondary
risks, to make sure that the planned actions have the desired effect on either the consequence
and/or likelihood. The residual risk and secondary risk outcomes allow for assessing whether
spending time and money is worth the effort or whether the strategy should be adjusted.

8.3.4 Implement
This step is fairly straightforward. Just like with other action lists of the project, the risk responses
should be actively managed to get things done. For large risk responses it might be worthwhile
to plan them in the project schedule. The risk coordinator is the one managing this. Not all

142

925836-02_160_17-Feb-15_08:42:45_walter
 the scene and money at work

Table 8.1: Strategies for dealing with risks

Upside risk response strategy

Realise Ensure that the risk will definitely occur

Enhance Increase impact and/or likelihood

Share Find another party to improve management of the risk (by realising enhancement)

No action is taken although it is possible to develop contingency plans (either in actions or a

Accept
reserve in time/money/resources)

Downside risk management strategy

Avoid End risk exposure

Reduce probability and/or impact on objectives to an acceptable level. Also known as risk
Reduce
mitigation.

Transfer Find another party to deal with the risk

No action is taken although it is possible to develop contingency plans (either in actions or a

Accept
reservation in time/money/resources)

organisations have a risk coordinator, in which case the project manager takes on this role.
Depending on the duration of the project phase and the size/complexity of the project, regular
risk meetings should be organised to track progress, but also to check whether new risks popped
up.

8.3.5 Monitor / improve

After implementation of the risk responses, risks should be monitored to ensure that the respons-
es lead to the expected results. If this is not the case, responses should be adjusted. Just like
with the implementation step, regular meetings are required to update the register as the project
develops. This step is crucial for risk management and often forgotten in practice. One should
realise that it is not enough to make an inventory of the risks and define the risks response strat-
egies: the most important aspect is to make sure that the chosen approach works.

8.3.6 Reporting
One step not mentioned above, but which is definitely required, is the reporting step. Although
for large projects it can be beneficial to also do this within the team, reporting is typically done to
the management of the organisation that owns the project. Perhaps in addition to or instead of
talking your audience through parts of the risk the register itself, a visual reporting method, can
bring across the message much more effectively.
The visualisation is done by placing the titles of the risks that require reporting on the RAM
matrix. Next to the title, the trend and status are indicated using symbols in different colours, see
Figure 8.4.

143

925836-02_161_17-Feb-15_08:42:47_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

Risk O Risk A
Trend
Very high
Risk P
Improving

Stable
Risk K Risk B Declining
Risk C
High
Acceptability (after impact of
existing actions)

Risk level is acceptable

Risk F Risk G Risk D
Impact

Management of the risk

Risk H
Medium needs improvement
Risk I
Management of the risk
needs major improvement
Risk E Risk J Risk and actions under
Risk L review
Low
New risk

Risk removed or delegated

Risk M
Risk N
Insignificant

<5% 5-20% 20-50% 50-80% >80%

Likelihood

Figure 8.4: Example of visual risk reporting

8.4 ! Risks and range estimates

As stated before, risks are uncertainties that have an influence on the project objectives (or value
drivers). In other words: risks determine what the ultimate outcome of those project objectives
is. The more risks, the more uncertainties will present themselves around the project objectives
such as the costs and timing of a project. This means that risks drive the ranges of potential
project outcomes, also of costs and timing. Since a project is uncertain by definition, it means
that there is no such thing as THE project costs or THE planning. A project promise to a sponsor
or client should be made in terms of a range (‘The project can be finalised between 1 September
and 1 October’) or in terms of the chance of realising a certain cost or deadline (‘There is a 50 %
chance that the project will be ready by 15 September’).

Because of the intrinsic uncertainty of a project, all project promises should be ranges (theoreti-
cally). In practice, quite some managers do not like this, since they are used to make one promise
to their management to bring in a certain project at a specific date. Of course this is understand-
able, but one should always realise that this deadline might not be met (in case some risks fired
that are causing delays). This clearly shows the importance of communicating the risk profile of
your project, since this depicts the possibility of delay or cost overrun. For apparent reasons, this
is also one of the main reasons for clearly communicating the risk profile of a project at impor-
tant decision moments in the project (see also Chapter 2).

144

925836-02_162_17-Feb-15_08:42:48_walter
 the scene and money at work

There are two major elements that drive the range estimates in projects:
1. The variability in many project parameters. Examples are: the price of raw material or goods,
the sickness leave rate of the project members, the amount of time to be spent on finishing
details, the percentage of scrapped material, etc. This can be seen as ‘known unknowns’. One
knows there is uncertainty in the estimations, but not how much.
2. Risks – A risk can or cannot fire. If it fires it has an influence on one project outcome, if it does
not it does not have any influence (except for precaution measures, contingencies).

It is clear how variability influences the ranges: if we need 10 to 11 kg of steel at a price of

€ 10 - 12 euro per kilogram costs will be € 100 - 132. For risks this is less straightforward: if there
is a risk something might happen with a likelihood of 10 % which will cost € 100,000, what is
the effect on the project budget. If nothing is done, there is a chance of 10 % that there will be a
budget overrun of € 100,000. If we budget for the € 100,000, there is a 90 % chance that we will
not need it, whereas we might have spent it on other things (perhaps even on ‘gold-plating’). If
we budget for the expected value of the risk (€ 10,000), this will never work. If the risk fires we will
have too little money, if it does not we lose € 10,000.

A solution is to work with a contingency budget. The latter can be used for risks that have fired.
Sometimes, managers have problems in giving out contingency budget, but it should be clear
that these budgets can only be used when risks have actually fired. If a project manager has
spent the whole contingency budget but is unable to show that risks have actually fired, she will
have something to explain to the project steering comittee. Thus the contingency budget covers
the difference between the minimum and the maximum range estimate of the budget.
The range estimates can be calculated by means of probabilistic calculations. One needs to real-
ise that in practice, people often are ‘scared’ by this term alone: people do not really understand
it and sometimes they will try to argue it away.

For parameters that have a variability, all relevant costs and parameters are estimated as ranges.
An example of this is shown in Figure 8.5. On the horizontal axis the parameter to be estimated is
given. On the vertical axis the probability density is stated: for every cost level or timing a certain

Triangle distribution

Most likely
Probability

Minimum Maximum

Cost (€) / schedule (wks)

Figure 8.5: Example range estimate of one parameter

145

925836-02_163_17-Feb-15_08:42:48_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

amount of realisation possibilities exists. The peek is the ‘most likely’ value which simply means
the highest chance this budget or schedule is realised. The example distribution is triangular,
but you could use any distribution you like: normal distribution, uniform distribution, etc. These
estimations can also be done per task in the project schedule (facilitated by computer packages
like ‘Primavera’ or ‘Crystal Ball’).

The next step is to add all these estimations together, which clearly needs to be done with a
computer. One well-known method is the Monte Carlo method. Let us take an example for a
Monte Carlo analysis of a budget or project schedule. This method draws one value from all dis-
tributions for all parameters. After the draw the method calculates one final possible budget or
schedule based on these draws. For each draw all risks and their effects are taken into account:
if there is a risk of 10 % of something that takes 1 month longer, in 10 % of the draws this addi-
tional 1 month is encapsulated in the final schedule for that occasion (and in 90 % of the draws
this month is not appearing…). After that this is repeated several hundreds of times (typically
500 - 1000 times). It means that now hundreds of possible budgets or schedules are calculated.
These can be plotted in a probability distribution, see Figure 8.6a, or a cumulative distribution,
see Figure 8.6.b.

Figures tell us that there is a huge spread in potential schedules (or budgets): there is the – in
practice very unlikely – possibility of a schedule of 1 week all the way down to the possibility
of the project lasting 16 weeks. The most likely outcome is 5 weeks: this is simply the highest
value in Figure 8.6.a. Typically, these kinds of distributions are asymmetrical (skewed). This is to
be expected because at some point it is very hard (or impossible) to finish the project in less than
the minimum amount of weeks, whereas it can be delayed almost indefinitely. The asymmetry
is caused by the risks, especially the low chance-high impact ones. The cumulative plot (8.6.b)
confirms there is a 50 % chance that the project will take 5.5 weeks or less (this is the ‘median’).
Likewise, it can be seen there is only a 10 % chance that the project takes 2.5 weeks or less, and a
90 % chance that the project is completed within 10 weeks.
The strength of this Monte Carlo approach is that the deterministic (point) estimate on budget
and schedule now turns into probabilistic versions. This really improves expectation manage-
ment, but it also allows for sensitivity analysis and enables the quantification of the impact
of various risk management strategies. Having this quantitative impact of risks on costs and
schedule also provides a solid basis to communicate with stakeholders such as joint venture
partners or internal management.

8.5 ! Getting started

Now it is time to turn the plan into practice. In this paragraph guidance for day-to-day-work in
the field of risk management is given.

8.5.1 Risk management plan

The first step in sound project risk management is to consider what the risk management strat-
egy is and how it can be formalised. This is laid down in a risk management plan which could
typically be part of the project strategy/implementation plan for smaller projects or a separate
document for large projects. A risks management plan typically contains:

146

925836-02_164_17-Feb-15_08:42:52_walter
 the scene and money at work

Monte Carlo Result – Probability Distribution

18%
Most likely
16%

14%

12%
Probability

10%

8%

6%

4%

2%

0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Cost (€) / schedule (wks)

Monte Carlo Result – Cumulative Probability

100%
P90
90%
Cumulative Probability

80%

70%

60%

50%
P50
40%

30%

20%

10%
P10
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Cost (€) / schedule (wks)

Figure 8.6 a and b: Example probability distribution (a) and cumulative distribution (b) as a result of
Monte Carlo analysis

• Roles and responsibilities

• How the risk management process will take place
• When the 5 steps discussed earlier will be executed (identification, assessment, planning,
implementing, monitoring and improving)
• RAM matrix and impact scales for cost, schedule, reputation etc.

8.5.2 Roles and responsibilities in risk management

In risk management there are three formal roles that should be defined.

147

925836-02_165_17-Feb-15_08:42:55_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

• Project manager – ensures resources are in place, understands the top risks, signs off on the
risk responses and in the end is accountable for all risks
• Risk coordinator – does a frequent review of the risk register with the team, monitors and
develops responses, communicates to management and project team, owns the risk register.
The coordinator reports to the project manager
• Risk owner – part of the project team (typically owns the consequence of the risk),
communicates with coordinators about status.

A role is not the same as an individual so it is possible that there is one person with multiple
roles. It is crucial to realise that the risks that could cause the project to step outside the triple
constraints need to be signed off by more senior managers. Besides that, the role of the risk coor-
dinator is mostly only introduced for (very) large projects; typically a project manager takes on
that role as well.

8.5.3 How and when: risk workshops

It is crucial for risk management to invite the right stakeholders to brainstorm (identify) and
assess the risks especially within the project team in a risk workshop. An integrated process is
recommended with relevant parties like the project owner/customer, (sub) contractor(s), part-
ners, etc. This improves risk understanding and increases ownership throughout the larger team.
As with any other meeting, a workshop consumes time and energy from people and thus justifies
preparing thoroughly to generate the most value. In order to be well prepared:
• Make sure you invite the right attendees (also consider future project phases, e.g.
construction, operations)
• Make sure all project objectives (or value drivers) of the project are represented
• Consider what can be done in advance (e.g. offline brainstorming by all participants,
gathering lessons learnt, checklists etc.)
• Depending on the number of participants, ensure a facilitator and scribe are present
• Be clear what the aim of the meeting is and which of the steps are going to be discussed;
identify, assess and/or plan
• Decide whether to include HSE in risk assessment or make it part of a separate session.
Both have pros (integration, single register, having people already there) and cons (smaller
audience, safety discussions can eat away time from other topics).

A few tips for having an effective risk workshop are:

• Ensure alignment among participants on the risk assessment matrix and its interpretation
(both likelihood and impact scales). This prevents discussions during assessment later on.
• Use the meta-language which really helps identify good quality risks. This also helps in
assessing the risks later on for probability and impact.
• Assess the likelihood by thinking in percentages starting with ‘is it more than or less than
50 % likelihood’ after which the scale to determine whether the risk is ‘Very High’ to ‘Very
Low’ can be used, not the other way around.
• If one of the team members has experience with a certain risk that actually happened in the
past, she is more likely to rate the probability higher than those who have not. It is therefore
important to recognise that any assessment will be based on a common agreement between
perceptions (this is called the Delphi method). Try to prevent wasting too much time on the
assessment as it is nothing but a means to prioritise the risks, not to manage them.

148

925836-02_166_17-Feb-15_08:42:56_walter
 the scene and money at work

As stakeholders change regularly, the advice is to have a focused meeting or workshop on a regular
basis, but at least in every project phase.

8.5.4 Risk register

The most important way of handling risks is to keep track of them in a risk register in which all
the risks, including the risk status and planned responses are laid down. The register lists for each
risk the following information:
• Risk ID
• Risk title
• Upside or downside risk (Threat or opportunity)
• TECOPS identification (or likewise categorisation)
• Cause
• Event
• Effect
• Risk rating before risk response
– Likelihood rating
– Impact rating
– Risk (multiplication of the two)
• Planned response (including timing)
• Residual risk rating after response
– Likelihood rating
– Impact rating
– Risk (multiplication of the two)

The most obvious tool to use is a simple spreadsheet which lists individual risks on the rows and
the information listed above in the columns.
Although a spreadsheet function is fit for purpose for small to large projects, a shared database
(online) has a number of advantages. Some enable history tracking so you know when each
change was made. A second advantage is the ability to work with multiple users on this database
and sometimes even cross platform (including mobile devices). Thirdly it can automatically track
how actively the risk register is kept up to date.
To give the project stakeholder an indication of how actively risk management is being applied,
some key performance indicators (KPIs) can be defined and tracked. The easy and obvious ones
are:
• % of risks completely described (meta language, assessed, owner)
• % of risks added, changed, closed last month
• ratio of opportunities versus threats

Just like with project to-do-lists, the risk register should be kept up to date at regular intervals to
enable progress monitoring and timely intervention. Frequency depends on the kind of project.
Since the amount of uncertainty decreases by definition during the project lifecycle, the risks and
risk descriptions too will become more precise during the project. In line with good front-end
development (see Chapter 7): the earlier the risks are on the radar screen, the better the potential
for dealing with them in an efficient way. For an effective risk register regular updating is key.

149

925836-02_167_17-Feb-15_08:42:56_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

The Wind Farm – Risk register examples

The project team previously came up with two risks related to the comminities.
The table below shows how these risks are worked out in the register.

Risk ID 1 2

Risk title Local employment Local protest

Threat or opportunity Opportunity Threat

Organisation + sustainable
TECOPS category Sustainable development
development

High human resource

requirements for the
Cause The Wind Farm being near shore
maintanance of these wind
turbines

Many local residents might Local residents might be against

Effect
become employed the project and start to protest

Significant schedule impact

(e.g. delayed permitting) and a
Consequence An increase in local support
reputation impact on national
level

Before response

Likelihood rating 3 (20 % – 50 %) 4 (50 % – 80 %)

Consequence rating 4 (10 % – 20 % impact on NPV) 5 (> 20 % impact on NPV)

Risk (multiplication of the two) 12 20

Risk owner Project manager Sustainable development lead

(Reduce) organise frequent

(Enhance) plan for high local
meetings with communities and
Planned response (incl. timing) employment strategy (e.g. local
develop win-win development
advertisement)
options

Residual risk

Likelihood rating 5 3

Consequence rating 4 5

Risk (multiplication of the two) 20 15

150

925836-02_168_17-Feb-15_08:42:57_walter
 the scene and money at work

By now it should be clear to the reader that risk management can and should be applied for
every single project as it can easily be made fit for purpose. The steps explained basically all have
to be taken but fit for purpose for risk management means to select the right tools, involve the
right amount of stakeholders and spend an appropriate amount of time on e.g. workshops and
keeping the register evergreen. This could mean for example that risk workshops for small pro-
jects are held in the framework of a regular project meeting.

8.6 ! People are key

The techniques, tools and framework discussed should not be seen as all there is to risk man-
agement. After all, threats and opportunities are managed by people and not by processes and
spreadsheets. Recognising this strengthens the risk management in a project, but this needs
some understanding of the psychology of people and influencing skills.

Throughout the chapter the reader is shown that the risk management process is no ‘hard
science’ but rather a subjective process in which human assessment of situations and future
expectations play the key role. Still, a key element of risk management is at least prioritisation
or even quantification of risks. This means that we have to realise that both the prioritised and
quantified risks hold subjectivity in them. Different people will judge the danger of risks (or
potential of opportunities) in different ways. Day-to-day examples are: some people do not ride
a motorcycle because they think it is too dangerous, whereas others love the thrill. Some project
members just seem to see problems (and risks) everywhere, whereas others are always (very)
optimistic. Both types of personalities might be allergic to the other type: ‘Why can’t you stop
finding roadblocks everywhere? Let’s just do it.’ versus ‘Last time we also faced last-minute trou-
bles, don’t you remember? So let’s now work out this risk a bit more. You never seem to listen to
my warnings!’ For a good (risk management) team both attitudes are necessary and both types
perfectly complement each other. You need the other that you are so allergic for….

The attitude towards risks is described best by Hillson & Murray-Webster: ‘Risk attitude is the
chosen response of an individual or group to uncertainty that matters, driven by perception.
Understanding risk attitude is a critical success factor that promotes effective decision-making in
risky situations.’ (Hillson & Murray-Webster, 2007).

As the risk attitude is a continuum ranging from extreme levels of discomfort up to extreme levels
of comfort to risk, there is an infinite amount of risk attitudes. In Figure 8.7 this continuum is illus-
trated. The continuum is divided into roughly four groups: risk averse, risk tolerant, risk seeking
and risk neutral attitudes. Risk averse persons will typically (try to) avoid risks, whereas on the
other hand risk seeking people will actively seek out risks. There is a large group in the middle
that balances between those extreme attitudes. The attitude might also depend on the situation.
The risk neutral persons tend to be more averse in the short term, while they might be more risk
seeking in the long term.

Perception has a significant impact on risk management; both the likelihood as well as the
impact of risks are based on perceptions. Because perception is influenced by many factors (e.g.
previous experience, risk attitude, current emotional state), the resulting process and actions
from risk management depend on the individuals and the group and interaction between them.

151

925836-02_169_17-Feb-15_08:42:58_walter
 M a n a g e m e n t o f e n gi n e e r i n g P rojects

Extreme
Risk
seeking
High

Level of
Low comfort
to risk

Zero Zero

Level of Low
discomfort Risk
to risk tolerant
High
Risk
averse Risk
Extreme
neutral

Short Term Long Term

Figure 8.7: Risk attitude spectrum (adapted from Hillson & Murray-Webster, 2007)

Realising this is important. Nevertheless, influencing it can be a challenge the more so because
personal believes are at stake.

Already quite some ideas for influencing or dealing with these aspects were given. An example
is the use of several techniques (e.g. TECOPS) to ensure multiple categories of risks are identified
instead of merely the technical part (a common pitfall). During assessment, the separate discus-
sion of likelihood from impact gives more focus on the distinct items and thus reduces risk bias
in groups.

Paragraph 8.4 confirms risks determine probabilistic schedules and cost estimates, instead of
deterministic ones. Communicating in ranges to stakeholders gives much more information
about the project: not only is it clear what the ball-park figures of the project are, but one also
understands the effects of the uncertainties in the project. This does not change the fact that
there will always be people who are not interested in ranges and probabilities, but who simply
want to have single numbers: ‘Just give me the budget’. We now know this is too simple and that
we need to try to bring the richer picture across.

152

925836-02_170_17-Feb-15_08:43:01_walter
 the scene and money at work

8.7 ! Finally: the case for risk management

At the beginning of this chapter we asked the question as to why risk management is being
applied. Although the case for risk management seems clear, convincing your stakeholders of
the usefulness of applying effective risk management proves to be difficult in daily practice.
For this reason below some research conclusions are given that support the application of risk
management:

• ‘Projects tend to suffer unexpected outcomes… and organisations must learn to accept that as
part of reality, and be ready to prepare for them….’ (Raz, 2002)
• ‘…even low-uncertainty projects usually come with failure and delays, and their success is not
guaranteed.... In fact, previous studies have shown that high-risk projects are not less success-
ful than low-risk projects’ (Raz, 2002)
• ‘…risk management is more helpful in avoiding time and budget overruns than in helping
achieve better outcomes in performance and product specifications’ (Raz, 2002)
• A study from 2009 among 21 companies and 42 project managers, shows that out of 26
different project success factors such as trust, market, teambuilding and leadership, risk man-
agement was highest ranked by the project managers, even above SHE compliance (Safety,
health and environment). (Arkesteijn, 2009)
• Another study from 2010 on 67 projects focused on the impact on so-called value improve-
ment practices (VIPs). When asked about the benefit to the project, risk management was
rated as a top 3 item together with teambuilding and constructability review. (Bosch-Rekveldt,
The influence of project front end management and project complexity on project success,
2010)
• ‘… it is not about applying risk management with a ‘tick the box’ mentality, but rather it is
about truly investing efforts … One means to improve risk management is to have the right
people incorporated in the project team... A thorough risk identification session, including the
appointing of risk owners, should be followed by serious risk monitoring in order to take the
appropriate measures and achieve the project goals‘ (Bosch-Rekveldt, Managing project com-
plexity, 2011)

153

925836-02_171_17-Feb-15_08:43:01_walter