0% found this document useful (0 votes)
1K views222 pages

Delft Management of Engineering Projects

The document provides an overview of project management and engineering projects. It discusses the origin of project management in the early 20th century with the development of techniques like CPM and PERT. Notable early projects included the Hoover Dam and Manhattan Project. Formal project management emerged in the 1950s, and standards continued developing through the late 20th century, driven by technological changes. The document focuses on defining projects and engineering projects for the purposes of the book.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Topics covered

  • Project Complexity,
  • Project Success,
  • Project Lifecycle,
  • Lessons Learned,
  • Team Dynamics,
  • Project Failures,
  • Project Management,
  • Historical Development,
  • Risk Management,
  • Engineering Projects
0% found this document useful (0 votes)
1K views222 pages

Delft Management of Engineering Projects

The document provides an overview of project management and engineering projects. It discusses the origin of project management in the early 20th century with the development of techniques like CPM and PERT. Notable early projects included the Hoover Dam and Manhattan Project. Formal project management emerged in the 1950s, and standards continued developing through the late 20th century, driven by technological changes. The document focuses on defining projects and engineering projects for the purposes of the book.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

Topics covered

  • Project Complexity,
  • Project Success,
  • Project Lifecycle,
  • Lessons Learned,
  • Team Dynamics,
  • Project Failures,
  • Project Management,
  • Historical Development,
  • Risk Management,
  • Engineering Projects

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 1 ! overview
In this chapter, the origin of project management is explained as well as the development of pro-
ject management over the years. Following the definition of a project and project management,
the development of project management starting with the archaic ‘over the fence’ management
is dealt with in the next paragraph. Subsequently, a few of the project management standards
are introduced. The splitting of the project management lifecycle into various phases or stages
concluded by a stage gate at the end of each phase is the way in which a structured project
management process is developed. The step from project management towards management of
projects is a consequence of an integrated approach including the early involvement of all major
stakeholders. Despite this approach and this knowledge, projects still fail by spectacular numbers.
Focus on the people aspects, the front end development and a fit for purpose approach is the
solution to improve project performance.
The management of projects is continuously improving by learning from completed projects
and through benchmarking projects across different industries.

Chapter 1 ! outline
1.1 The definition of a project
1.2 The origin of project management
1.3 From ‘over the fence’ management to project management
1.4 Project management standards
1.5 Project management lifecycle
1.6 Towards management of projects
1.7 Projects fail by spectacular numbers
1.8 People are key in the management of projects
1.9 Fit for purpose management of projects
1.10 Learning from projects
1.11 The case study

925836-02_020_17-Feb-15_08:38:33_walter
the scene and money at work

Chapter 1
Introduction
by Hans Bakker

1.1 ! Definition of a project


What exactly is a project? In literature, a multitude of definitions can be found. On the internet an
even wider variety is presented. Even with the existence of the nowadays more or less accepted
‘bodies of knowledge’, there is no general consensus on the definition of a project. The most
comprehensive definition is given by Turner (1999):

‘A project is an endeavour in which human, financial and material resources are organised
in a novel way to undertake a unique scope of work, of given specification, within
constraints of cost and time, so as to achieve beneficial change defined by quantitative
and qualitative objectives.’

The PMI (Project Management Institute) definition is slightly shorter: ‘A project is a temporary
group activity designed to produce a unique product, service or result.’
The largest professional body for project managers in the UK, the Association for Project
Management (APM, 2004), uses the following definition: ‘Projects are unique, transient endea-
vours undertaken to achieve a desired outcome.’
The PRINCE2 definition of a project is: ‘A temporary organisation that has been created with the
purpose to deliver one or more business products according to a predefined business case.’

For the purpose of this book these definitions suffice. It is important to realise that what is meant
with the word project, is a temporary organisation (with defined start and end dates) brought to
life in order to deliver a unique (once-off) scope within given boundary conditions (schedule,
cost and quality). In that sense, Turner’s definition is the most complete definition and therefore
it is the one that has been adopted for this book.

Following this definition, a variety of activities can be described as projects. Moving house or
building your own home, buying a car, completing a PhD thesis, building a refinery, designing a
new coffee machine, or reorganising your department. You name it and the endeavour can be
considered a project. That makes life probably somewhat too difficult. Therefore, the book will be
focusing on engineering projects.

925836-02_021_17-Feb-15_08:38:35_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

1.2 ! The origin of project management


Some authors claim that project management really started with the advance of the chemical
industry in the early thirties of the twentieth century. Others believe that it was the period of
the arms race during the Cold War that created a demand for and focus on project manage-
ment. Notwithstanding the above, it is generally accepted that modern-day project management
began with the advent of the Critical Path Method (CPM, 1957 – Dupont) and the Programme
Evaluation and Review Technique (PERT, 1955 – Booz-Allen-Hamilton). Both originated from the
defence and aerospace industries and were subsequently taken up by the construction industry.
However you look at it, project management in itself is a relatively young discipline. In literature
most of the time four periods in project management evolution have been identified (Kwak,
2005). The history of project management is separated in the period leading up to 1957, the
period between 1958 and 1979, the period from 1980 till 1994 and from 1994 onwards. The mile-
stones marking these periods are the large technological developments that had major impact
on society in general: the invention of the plain paper copying machine by Xerox (1957), the
launch of the XT personal computer by IBM (around 1980) and the wider spread of internet to the
public from 1994. The evolution of project management is graphically represented in Figure 1.1.

Throughout history significant infrastructural endeavours have been successfully accomplished.


The pyramid of Giza and the Great Wall of China are great examples. More recently, the building
of the Pacific Railroad across the United States in the 19th century remarkably represents technical
courage and perseverance, although construction did involve delays and surprises. The building
of the Hoover Dam was considered a successful project. In total 5,200 workers were employed.
It was built between 1931 and 1936 within budget and ahead of schedule, but 96 workers were
killed during construction.

The oldest tool still in use in modern day project management was developed during this period
by Henry Gantt (1861 – 1919). The so-called Gantt chart outlines the sequence and duration of
events/tasks in a process and it was used during the construction of the Hoover Dam and the
Interstate Highway system (USA).
Another famous example of a project ‘avant la lettre’ is the Manhattan Project: the research into
and the development of the first two atom bombs that ended World War II. This project involved
125,000 workers and spent a staggering € 2 billion. Dutch projects in this same period are the
creation of the IJsselmeer with the Afsluitdijk and the start of
the Delta Werken, the big infrastructural project to protect the
southern part of the Netherlands against flooding. These were
successful endeavours indeed, however the phrase project man-
agement was not launched until 1954. In fact, Bernard Schriever, a
brigadier-general of the US Air Force, was the first to coin the title
‘project manager’. And because of that, he made it onto the cover
of Time Magazine.
In the second period (1958 – 1979), a large number of technolog-
ical developments influenced society and as a consequence also
the management of projects. The introduction of the plain paper
copier and the development of silicon chips and minicomputers
had a revolutionary impact on the way we are doing business.
The best known projects in this era were all based in the defence

925836-02_022_17-Feb-15_08:38:35_walter
the scene and money at work

1957 1980 1994


Y2K

Figure 1.1: Evolution of project management

and aerospace industries. Examples of large-scale technological projects that stand out are the
development of nuclear missiles during the Cold War (Polaris and Minute man), the Apollo pro-
ject by NASA and the design and construction of the Concorde. In the oil and gas industry, the
exploration and production of North Sea oil was a huge undertaking for a multitude of compa-
nies that lasted well into the next period.
During the third period (1980 – 1994), the advancement of technology in our businesses and
our daily lives accelerated enormously. The personal computer made its way into our offices
and eventually into our homes. Following this, project management tools and software became
widely available for the personal computer, which made project management techniques more
easily accessible for the larger community. Now for the first time the techniques that had been
developed for the big projects mentioned above became accessible for almost every project
engineer or project manager. Obviously, big projects continued to develop and apply the tech-
niques with high levels of sophistication. The building of the Channel Tunnel, Space Station and
Space Shuttle Challenger are most probably the showcases of this era. Many articles have been
written on the project management aspects of these developments. The growth of the member-
ship of the various project management institutes starts to develop almost exponentially from
here on.

925836-02_023_17-Feb-15_08:38: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 fourth and present era (1994 onwards) shows an unprecedented availability of and accessi-
bility to information. With the advent of the Internet and its spread across the globe, the project
management community has become more efficient in controlling and managing the various
aspects of projects.
The first time that the general public in its entirety was confronted with project management
and its side effects was around the transition into the new millennium, also known as the Y2K
project or the Millennium Bug. The Y2K project was instigated by the belief that on January 1st,
2000, most computer programmes would not function correctly anymore. Many organisations
adopted project management tools and techniques to execute their own Y2K project.
In this same period, the oil and gas industry started developing even larger major capital invest-
ment projects in order to keep up with the ever growing energy demand of the world. Easy oil
has long been discovered and the explorations and developments must now take place in new
and unknown territories. Projects are becoming more complex with even bigger technological
challenges. Examples include deep-water exploration and production near Brazil, in the Gulf of
Mexico and Malaysia (~ 3 km of water depth), ever larger Liquid Natural Gas plants in the Middle
East and the far east of Russia (liquefying natural gas at low temperature and transporting it by
ship) and the Gas to Liquid plants in South Africa and in Qatar (making liquid products out of gas
via the Fischer-Tropsch process).

1.3 ! From ‘over the fence’ management to project management


Over-the-fence management (Kerzner, 2005) preceded contemporary project management.
Traditionally, each discipline or function took care of its own activities. When the task was com-
pleted, the job was given to the next function in the line (‘thrown over the fence’). This means
that all the work was completely sequentially in nature and the last in line would most probably
get all the blame if the project went off-track. As a consequence schedule improvement was hard
to realise. The majority of project activities were performed by line managers who were more
interested in the advancement of their own departments than the success of the task at hand. In
fact, nobody was truly looking after the best interest of the project. Project management did not
really exist.

Another disadvantage of this sequential approach was that it was very difficult for customers to
keep track of where their ‘project’ was. Therefore at a certain stage, customers (and looking at
the earlier examples this was most often the government) demanded a single point of contact
throughout the ‘project’, a person who would be part of the development process during the
entire lifecycle. When this happened in the 1950s, the project manager was born. Initially, this
came with much resistance from senior managers as well as sales and marketing staff, since all
were afraid of losing their influence.
From there on the whole project management approach has been mostly based on best prac-
tice sharing and handing over of experience from manager to manager. This system has quite
a number of similarities with the traditional medieval master/fellow relation, although project
management is a much younger discipline.

925836-02_024_17-Feb-15_08:38:38_walter
the scene and money at work

1.4 ! Project management standards


Projects require effective management from inception to completion if they are to be completed
safely, on time and within budget and to meet additional business objectives as well. Therefore,
project management is nothing more than the controlled execution of an activity to complete an
agreed scope of work and meet predefined targets. The main objective of project management
is to deliver all the project goals and targets for the customer and possibly other stakeholders
involved within the boundary conditions given. Consequently, the management of engineering
projects is the controlled execution of design, engineering and construction activities for an
engineering project in such a manner that the project can be realised to meet the requirements
of the customer, technical or otherwise, within the given constraints such as safety, cost, time,
quality, resource, etc.

Project management is all about structure, standards and processes. Since the birth of the pro-
ject management discipline at the end of the 1950s, the various project management bodies
have grown exponentially. They all have produced best practices, guides and supporting tools
to further develop the project management discipline. At the moment a variety of standards and
disciplines are available for managing projects. Probably the oldest and best established is the
Project Management Body of Knowledge (PMBoK, 2008). The PMBoK Guide as developed, main-
tained and published by PMI (Project Management Institute) is the preeminent global standard
for project management. It provides project managers with the fundamental practices needed to
achieve organisational results and excellence in the practice of project management.
Their counterpart, the International Project Management Association (IPMA) has developed the
International Competence Baseline (ICB) Version 3.0. The ICB provides the official definition of
the competences expected from project management personnel by IPMA for certification within
the IPMA certification system.

Some governments developed over the years their own project management systems. The best-
known example is PRINCE2. PRINCE2 (Projects IN Controlled Environments, 2009) is a de facto
standard developed and used extensively by the UK government and is widely recognised and
applied in the private sector, both in the UK and internationally. It embodies established and
proven best practice in project management.
Since mid-2012 the voluntary International Standard Organisation (ISO) has issued the ISO 21500
Guidance on Project Management. The latter has been developed by participants from over 30
countries. It can be used by any type of organisation including public, private or community
organisations, and for any type of project irrespective of complexity, size and duration. ISO 21500
provides a high-level description of concepts and processes that are considered to form good
practice in project management. New project managers as well as experienced managers will be
able to use the project management guidance in this standard to improve project success and
achieve business results.

Not only governments developed their own project management systems and procedures but
also, large industrial companies decided to translate their own successful working practices in
the field of project management into a project management system. Those pragmatic and prac-
tice-oriented systems for managing projects form the basis of the approach chosen in this book.

925836-02_025_17-Feb-15_08:38:38_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

1.5 ! Project management lifecycle


Whatever the unique character of a project is, it will always have a number of distinct phases.
Turner (1999), for instance, distinguishes four phases from proposal and initiation, through design
and appraisal, execution and control to finalisation and closeout. Others split the whole project
lifecycle up in 5 or even 8 phases. Some examples that are given in Figure 1.2 originate from the
exploration and production industry, the refining industry, IPA (Independent Project Analysis) and
the process industry respectively.

The project management lifecycle as defined in this book is based on and aligned with the gen-
eral business process. In the first step a potential future project – called an opportunity in this
phase – is identified, the potential value is assessed and the alignment with the business strategy
is verified. There might be a number of ways in which this opportunity can be realised. Each of the
potential solutions will have positive and negative side effects and in the second phase the most
optimal – preferred – solution is selected. In the third phase the scope, engineering together
with the costs and the schedule, should be further detailed and defined and finally funding
to realise the opportunity need to be obtained. If and when all the pre-work or the front-end

Industry Phases

Exploration Identify and


Select Define Execute Operate Abandon
Assess

Oil / Chem Scouting FED 1 FED 2 FED 3 Implementation Operation Abandon

Strategy / Development Commitment Results


Exploitation
Front End Development Executed with Minimal Safety
IPA Use of VIPs Change IRR
Alignment of
functions Minimum Scope of Bussiness Needs Detailed Planning and
Leading technology Control Processes

Dutch Business Conceptual Basic Det. Pro- Con-


process cure- struc-
Scenario Design Engineering Eng. ment tion
industry
Business Implemen-
Planning & - Front-End tation Startup & Abandoment
Project Development & Operational Operation & Demolition
Strategy Readiness

Deliverables
Engineering Scouting or Basic of Design Front-End Eng. Handover Scouting or
Feasibility Report & Design Documentation Feasibility Report

Project Execution Project Execution Project Implemt. Start-up Post Investment New Project
Project
Strategy (PES) Plan (PEP) Plan (PIP) / FID Documentation Review (PIR)

Figure 1.2: Phase nomenclature in various industries together with an indication of engineering
and project management deliverables

925836-02_026_17-Feb-15_08:38:39_walter
the scene and money at work

development work is properly executed and sufficiently detailed, this will result in a positive
final (or financial) investment decision. In the fourth phase the project is executed and it has to
produce an operating asset within the boundaries of cost, schedule and scope as defined in the
earlier phases. In the fifth phase, the asset will be commissioned, started up and continuously
operated. A couple of months into this phase the operation will be evaluated to ensure that the
asset performs as forecasted and in line with the customer’s expectations, the so-called post-
investment review or PIR.

The PIR is one of the many documents that will be produced in the execution of a project.
In Figure 1.2 some of the engineering documents or deliverables are indicated for each of the
phases. Gradually the level of detail in these documents will grow and the accuracy of the scope,
the cost estimate and the planning will increase in parallel.

Only a couple of years ago, an additional phase was added to the project management lifecycle.
This phase is called the abandonment phase. With the growing environmental concerns as advo-
cated by e.g. the nongovernmental organisations, attention has to be given as to how the assets
will be dealt with once their production life is over. One solution could be to extend the produc-
tion life, but once this is not economically feasible the asset has to be abandoned or demolished.
It is good practice nowadays to think about these issues already during the design of an asset
and the development of the project. In the design phase, decisions can be taken that will simplify
abandonment three or four decades later. In the actual project management practice, this aban-
donment project will be a separate project well into the future.

Despite the varying names or titles, what the project management lifecycles from various indus-
tries all have in common is considerable attention for the front-end development phase of the
project. In other words, if done correctly a lot of attention, time and effort is invested in defining
and designing whatever needs to be accomplished with the project before any spade is put into
the ground or any weld is laid. The main reason for that is that the scope at this front-end stage
can still be changed relatively easy without too much impact on the overall costs and schedule.
Later on, a change can potentially be very costly and even derail the project.

The effect of influence and costs on project lifecycles is schematically indicated in Figure 1.3.
Prior to the final investment decision most of the work performed is paper-based. Scope has
been worked out and design has been further detailed. In the worst case a lot of man hours are
wasted if the project does not continue or another option is selected at a late stage. However
after the final investment decision equipment will be ordered, certainly the long-delivery items,
perhaps even before the detailed design is finalised. Especially in the industrial mega projects,
these preorders will be a large part of the execution budget. Changes in the project after pre-
ordering the long lead items will have a disastrous impact on the project.
Nevertheless, the reasoning for a good front-end development phase is not only financially based.
Spending sufficient time on all the aspects of a project in the early phase will have an enormous
influence on the execution of the project and the final result. A project well-defined in the front-
end development phase has a chance of becoming successful provided the execution is also
well managed. An ill-defined project can never be turned around for the better during execution
however good the management of the execution is. But a well-defined project can certainly be
derailed and even destroyed during an improperly managed execution phase.

925836-02_027_17-Feb-15_08:38:40_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

Rapidly
Major Decreasing Low
Influence Influence Influence

FID

EXPENDITURE
Appraise Define
INFLUENCE

Select

Mechanical
Completion
Front End Development

Build Operate
(EPC)

Project Project Construction Handover &


Planning Definition Start-up

Figure 1.3: Relation between influence and cost during the lifetime of a project

Based on the business alignment, the project phases as defined in this book are represented in
Figure 1.4. Since the abandon phase is most often considered a separate project, the decision was
taken to exclude this phase and limit the project management lifecycle to five phases in total.

Each of these phases is completed with what has become known as a stage gate or a review
point. The purpose of such a stage gate is to assess and assure that all the necessary conditions
and pre-work have been fulfilled before stepping into the next phase and further detailing the
project (thus spending more money and time). Normally this assessment is done by a person
or a team independent from the project team. By performing this assessment independently
a fresh look will be given to the deliverables and progress can be measured against the agreed
project management processes as they exist in the company. By carrying out this assessment
really independently and seriously, mishaps and omissions can be prevented which might later
on result in derailed projects.

Appraise Select Define Build Operate

Figure 1.4: The phases of the project management lifecycle as adopted in this book

10

925836-02_028_17-Feb-15_08:39:01_walter
the scene and money at work

Drug Dev.

Drug Dev.
Def. Aero

Def. Aero
Const’n

Const’n
IT

IT
Strategic Commercial

Portfolio Management W S/M W S Finance S M/W M/W W

Programme Management W/M S S W/M Marketing W W S/M S

Project Strategy W/M S S S/M Legal S M S S

Benefits Management M/S S W M/S Procurement S M/W S M/W

Value Management S/M W S/M M (Supply Chain Management) S W S M

Risk Management S S S S Bidding (Tendering) S M S W

Quality Management S S S M Contract Administration S M S W

Health, Safety & Environment S W S M/S

Technology Organisation

Requirements Management W S S M/W Organisation Structure S S S S

Briefing S W W W (Project Development Cycle) S S S S

Technology Management M S S S Teamwork S M S S/M

Design Management S S S N/A Leadership S S S S

Configuration Management W S S W Negotiating & Influencing S M S M

Information Management S S S S Conflict Management S M S M

(Document Management) S S S S Communications S S S S

Production S W S S (Stakeholder Management) S S S S

(Supply Chain Management) S W S M Career Development M M S M

(Construction Management) S N/A N/A N/A (Competences) W W S W

(Integrated Logistic Man.) W M/W S M Ethics M M S S

Testing M S S S

(Commissioning) S S S (S)

Control

Scope Management S S S S
KEY
(Change Management) S S S S
Generalizations are dangerous
Estimating S S S S but the indications are:

Resource Management S S S S
S Strong
Scheduling S S S S
M Medium
(Concurrent Engineering) M W S W
W Weak
Budgetting S S S S
N/A Not applicable
Cost Control S S S S

Integrated Performance Meas. M M S W/M

Figure 1.5: Project management practices in the various industries according to PMBoK
(according to Morris, 2003)

11

925836-02_029_17-Feb-15_08:38: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

In the first phase the business analyst together with the asset manager and the business mana-
gers will select the right project for the existing business strategy. The question that they will be
asking themselves is this: ‘Are we doing the right project’. The subsequent phases in the execu-
tion and the assessment performed during the stage gates will focus only on whether the project
is done right.

1.6 ! Towards management of engineering projects


The project management systems are quite often based on ISO9000 principles and therefore
the steps taken in the development of a project are documented and the process followed is
auditable and continuous learning is embedded. The project management process is quite often
supported by value improvement practices and project standards defined for the various activ-
ities that are taking place in the course of a project (estimating, cost control, risk management,
scheduling etc.). These systems/procedures have been developed over the years and are handed
over from one project manager to another. ISO9000 has driven the thorough documentation of
these project management systems.

Morris (2003) presented an analysis of the project management practices in the construction
industry (our focus in this book) and the implications for the project management societies. What
becomes evident from this analysis (see Figure 1.5) is that the classical project management
topics such as control, commercial and organisation are very well represented in the bodies of
knowledge (PMBoK). However, insufficient emphasis is placed on the strategic and technological
aspects of project management. For engineering projects focus will be on the column labelled
Const’n (= construction industry). Especially more attention should be given to portfolio mana-
gement, programme management, project strategy, requirements management, configuration
management and logistics management. Morris concludes that project management will only
be seen as totally integrated and in control, provided elements such as project definition as well
as implementation and early operation are considered as integral parts of the charter of the pro-
ject manager. That is when focus shifts from project management to management of projects
as indicated in Figure 1.6. This basically means that all relevant players should be involved as

Project management

Stage gate
Stage gate Stage gate Stage gate Project
review point
review point review point review point review
(FID)

Appraise Select Define Build Operate

Management of projects

Figure 1.6: Difference between project management and management of projects

12

925836-02_030_17-Feb-15_08:38:43_walter
the scene and money at work

early as (reasonably) possible in the definition (of functional requirements) and development of
a project.
Ideally, in the future no more handing over from business developer to project manager, to con-
tractor, to operator and finally to maintainer will take place. Instead, all parties should together
be involved from the earliest possible stage onwards. In short – and referring back to my earlier
statement – project management was born from over-the-fence management and has come
a long way, but there are still a few more fences to be demolished. Integration throughout the
project lifecycle is key to future success.

As a consequence of this change, a major improvement will be that the business development
is done in a more realistic manner taking the construction market and the project management
peculiarities more seriously into account. It means that in the appraisal phase (see Figure 1.6)
business developer and project manager should be working more closely together to develop
a realistic opportunity taking all technical, economical, commercial, organisational and politi-
cal aspects of the business opportunity into consideration. Also, interaction with the customer
(when applicable) should be done in cooperation between business developer or commercial
staff and the project manager.

If integration throughout the project lifecycle is taken seriously, it implies that all parties should
be involved far earlier than they were used to. Not only the project manager and business deve-
loper should join hands at a much earlier stage but also, maintenance staff and operators need to
participate in the design and development of the plant in order to guarantee the future operability
and maintainability of the asset. In practice it means that developments have almost gone full
circle. Traditionally the major oil companies, as an example within the process industry, had
almost all disciplines and skills available. Engineering and design offices were part of the head-
quarters and sometimes even part of the core skills that existed on a refining site. Through the
years most of these activities have been outsourced and the oil companies have been focusing

Basic design Engineering Procurement Construction Maintenance Past

Engineering Constructor /
Client Client Client
company Supplier

Basic design Engineering Procurement Construction Maintenance Present

Client / Contractor /
Contractor / Engineering Company / Supplier
Engineering Cy Client

Basic design Engineering Procurement Construction Maintenance Future

Client / Contractor / Engineering Company / Supplier

Figure 1.7: Developments in the process industry

13

925836-02_031_17-Feb-15_08:38:45_walter
Study by Year Projects studied Overrun Principal reasons

75 % cost increase ($346 billion Inflation, Quantity increases, engineering


General Accounting Office 1979 940 US civil and military projects
to $607 billion) changes, schedule changes, underestimating

Quantity changes, inflation, underestimation,


140 % cost increase ($460 billion
General Accounting Office 1982 444 US civil and military projects support costs, engineering changes, schedule
to $842 billion)
changes

Project size, complexity, technological advance


Harman 1970 25 US weapon systems projects 50 – 700 % cost increase
and development strategy

Large 1974 8 US weapon systems projects 200 – 400 % cost increase Underestimate difficulty and cost

925836-02_032_17-Feb-15_08:38:45_walter
200 – 300 % cost increase
Marshall and Meckling 1959 22 US weapon projects Differences in technological advance
30 – 50 % schedule increase

Merrow et al. 1979 10 US energy prototype projects 100 – 200 % cost increase Technology advance uncertainty

Cost: tecnological innovation and poor project


55 US process plants (33 having 140 – 210 % cost increase
Meyers and Devey 1984 definition. Schedule: concurrency and solid
pioneer technology) 0 – 30 months schedule increase
M a n a g e m e n t o f e n gi n e e r i n g P rojects

feedstock

14
Perry et al. 1969 19 US weapon system projects 0 – 460 % cost increase Government-induced scope changes

Unforeseen technical difficulties or


0 – 600 % cost increase
Peck and Scherer 1962 12 US weapon systems opportunities to improve technical
0 – 130 % schedule increase
performance

Technological uncertainty (30 %), scope


Perry et al. 1971 36 US weapon systems projects 0 – 220 % overrun
changes (50 %), underestimating (20 %)

Technological uncertainty and programme


Summers 1965 22 US weapon systems projects 15 – 150 % cost overrun
length

Blake et al. 1976 Various US power plants 58 – 258 % cost overrun

Inflation, increased safety requirements;


Canaday 1980 35 US nuclear power plants 58 – 408 % cost overrun
Table 1.1: The analysis of 3500 completed projects (from ‘The anatomy of major projects’)

interest charges

Cochran 1978 BART, TAPS, SRAM 36 – 200 % cost overrun Concurrency and resource shortages

2 large US coal liquefaction


General Accounting Office 1981 43 % cost overrun Poorly defined and administered contracts
plants

General Accounting Office 1984 3 US nuclear power plants 362 – 548 % cost overrun
the scene and money at work

on their core skills more and more. With the advent of EPC (engineering, procurement, construc-
tion) type contracts a number of the activities were already becoming more integrated in their
execution, be it outside the original company. Design and operations remained at least to some
extent part of the core activities. With the call for further integration the remaining borderlines
between design and EPC and between EPC and operations will be gradually reduced. By then the
oil companies will have come almost full circle in their evolution, not as an all-encompassing
single company, but as part of an integrated project team responsible for Design, Build, Execute
and Operate of the future assets together with a number of complementary companies. One
might even argue that when the execution is really integrated, the third bar will probably become
shorter due to higher efficiency, effectiveness and less rework.

This is easier said than done. Over the last few decades many of these activities have been
outsourced by major companies. To integrate these activities more closely may now seem coun-
terintuitive, but the only way forward. The project manager might be swimming against the stream
wanting to accomplish matters. Nevertheless, the goal will be better overall project performance
based on early and full integration. Quite often the cooperation between parties is governed by the
contract and the way the work has been outsourced. In order to overcome this, different relations
should be forged that are built on trust and mutual understanding and that are not only driven by
the contractual conditions. The approach needs to be truly integrated between all companies and
all participating parties in order to be successful. A team without boundaries is required from the
earliest possibility in the life of the project. This is still a real challenge.

1.7 ! Projects fail by spectacular numbers


What does the general public know about engineering projects, project management and project
success? If a survey were to be organised today, the majority would probably quote newspapers
and state that projects are generally completed far later than originally planned and that they
cost a bundle more.
And honestly, they would not be far out, even based on the professional literature available.
Recent infrastructural projects, projects in the oil and gas industry, the IT industry, but also many
projects in the aerospace and defence industry over the last couple of decades are not the best
examples that might be expected.
Of course, what made it to the newspapers are the mishaps, the disasters. Most often contributed
to the project manager or project management. The news value of a project delivered in time
and within budget is still relatively low and in that case it is due to the foresight and vision of the
owner and his organisation. But even from the perspective of the practitioners themselves the
project management profession is traditionally not seen as the discipline with the most appeal
(Van de Laar, 2007). Quite often in the business world people prefer a career in line management
rather than a career in project management.
The project management discipline as a whole does not have an incredibly good track record.
Morris and Hough (1987) have analysed a large number of projects – some 3,500 projects from
all over the world – realised in the period 1959 till 1984 (see Table 1.1). These projects were exe-
cuted in both the civil and military industry as well as in the power and nuclear industry. They
came to the staggering conclusion that these projects showed typical overruns in expenditure
and schedule between 40 and 200 % (and bigger overruns have been seen).
The independent international benchmarking company IPA produces an annual benchmarking

15

925836-02_033_17-Feb-15_08:38:46_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

comparison of the projects that have been completed by their member (subscribing) compa-
nies the previous year. By now, IPA has a database of more than 12,000 projects from within the
industry (oil, gas, fine chemical, petrochemical and pharmaceutical). Their analyses, although
more recent, show the same sobering results. Their conclusions are that since 1993 more than
50 % of the conventional oil and gas projects have been disasters. Disasters in this sense are
described as having more than 30 % cost growth and/or more than 38 % schedule slippage. On
top of that, less than 39 % of projects lived up to their promises during the first year of operation.
Another more recent example is the analysis of Flyvbjerg (2007) showing a similar trend in cost
overruns in large infrastructural projects: 9 out of 10 projects have a cost overrun.

In Figure 1.8 a plot of 19 anonymised large engineering projects – executed in the period 1992
till 2007, and collected by the author – is presented. These were the megaprojects of those days,
the construction of process plants with total investment costs ranging from € 500 million to 2
billion. On the y-axis the actual costs over the estimated costs is shown as a percentage. On the
x-axis the actual duration over the estimated duration is shown in a similar manner. The working
assumption is that a result within ± 10 % of the cost and duration is considered to be a successful
project (within the small dotted rectangle). As can be seen from the graph, only 9 out of the 19
projects can be considered successful according to this definition: a very disappointing 58 % fail-
ure rate. An underspending of more than 10 % is also considered unfavourable, because money
was tight up unnecessarily in the project that could have been used for other investments.
These results, whilst dated in some cases, are shocking. The most concerning fact is that over
the last 30 years the performance of the projects delivered has hardly improved. The results are
totally in line with the perception of the general public regarding projects and project manage-
ment as given at the start of this paragraph. The main question is now what can be done further
or maybe differently to change this situation.

100

150

140

130
Cost %

120

110

100
80 90 100 110 120 130 140

90

80

Duration %

Figure 1.8: Results from a portfolio of engineering projects

16

925836-02_034_17-Feb-15_08:38:47_walter
the scene and money at work

1.8 ! People are key in the management of projects


What has already been touched upon in the previous paragraphs is that successful projects are
integrated throughout the project lifecycle. The early involvement of the project manager is
essential to ensure full alignment with the business case. But early involvement of contractors
and suppliers as well as maintenance and operations staff is also essential.

Timely involvement of suppliers and contractors is important to have a smooth design process
focused on constructability later on in the project cycle. Bringing maintenance and operations
staff in early in the project will contribute to an effective handover and start-up process and will
support the future maintainability of the plant. In short, if the project manager is able to build
together with his contractors and subcontractors a fully integrated team, or in other words if the
project manager is able to build a team that operates as one entity – a seamless team – evidence
shows (Bosch, 2011) that such a project team is most likely to be successful. It is also strongly
recommended to early invite the assurance staff who will perform the stage gate reviews in order
to agree which process steps to follow and which deliverables will be adhered to.

Finally, more stakeholders would benefit from an early involvement. Project management is con-
sidered to be good if the communication with stakeholders is an integral part of the activities in
order to prevent unpleasant surprises by the time the project is ready to be started up. Managing
the project is in fact managing all the people involved, keeping them informed and aligned and
making the best use of their collective capabilities. Obviously tools, techniques and procedures
will be essential to deliver the project, but the success of the project depends for the great-
est part on the fruitful collaboration of all the parties involved. Fewer boundaries – perceived or
real – between the various parties will have a positive effect on the outcome.

Future relationships should become real partnerships built on trust and mutual understanding.
Building those relationships will require an enormous amount of effort and time in order to
change the existing culture of collaboration. Relationships are the foundation of future accom-
plishments. Examples of excellent relationships actually have been realised, yet it requires
concerted effort from all parties and it is far from easy to accomplish.

1.9 ! Fit for purpose management of projects


In the previous paragraphs a number of fit for purpose approaches have already been mentioned.
• First of all, spending enough time on the design and the development of the project is the
main requirement for a successful project outcome. Spending sufficient time and effort on the
development of the front end is essential and is more than anything else a fit for purpose step.
As mentioned before, the management approach should be commensurate with the size and
complexity of the project.
• The second step is to agree with the assurance staff executing the stage gate reviews what the
deliverables for each phase of the project will be. Depending on the size and complexity of the
project the deliverables can be adjusted. As an example, for simple and small-scale projects
sometimes a decision is taken to combine the FED1 and FED2 phases as indicated in Figure 1.2.
For that same simple and small-scale project it could be OK to make only one estimate and
not go through the steps of a number of estimates with increasing accuracy. One size does
not fit all. For a mega-project on the other hand the decision could be that a number of the

17

925836-02_035_17-Feb-15_08:38: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

value improving processes will be executed more frequently, for instance in every phase of the
project before every stage gate.
• If the project team is truly integrated, the selection of staff is an issue that needs to be addressed.
At this point the focus on people and the fit for purpose approach come together. In such an
integrated team one might not need a planner from the contractor and a planner from the
owner. Various tasks can be distributed amongst the contributing parties. One needs to make
sure the team does not become too heavily loaded. Whether this is feasible depends on the
amount of integration and the trust between the parties. LEAN techniques might be beneficial
and would certainly support a fit for purpose management approach.
• Collaboration in these integrated project teams will require a real shift in paradigm. The success
of the project should be driving individual behaviour and reward, not necessarily the success
of the individual companies, owner or contractor. This will require a massive shift in doing
business.

1.10 ! Learning from projects


Project management could make a big step forward if only at the end of the project lifecycle suf-
ficient time would be set aside to report on the accomplishments of the project and the project
management. Quite often and certainly in the present market, demand for human resources is
so high that even before the project is completed there is already a pull to transfer the project
manager to a new project and let his deputy complete the last details and the last few months.
Of course that can be done and it is as a matter of fact an excellent learning opportunity for the
deputy, but what really suffers is the managerial learning process (Storm & Savelsbergh, 2005).

A concerted effort should be made to capture all the lessons learnt from the project, report
them back and where feasible incorporate them in future procedures, tools and systems. This
is done, first of all for economic reasons. Has the project really delivered what was originally
promised in the business case? But this should also be done from a project management
perspective. Have new methods and approaches been applied successfully in this project that are
worth replicating in future similar projects or in general? A loud and clear plea is made that time
should be set aside after project completion to seriously capture the lessons learnt together with
the relevant high-level data.

Where possible it should be considered to make a case study out of these lessons for the edu-
cation of future project managers and other project professionals. Securing that this actually
happens is probably the biggest challenge for the future of management of projects. Often solu-
tions might have been developed by a project team and are being applied unnoticed for other
projects, because of the extreme focus on delivery.

This lack of managerial learning is a potential cause for project failure which for unknown
reasons hardly ever shows up in the top-ten reasons for project failure (also absent in Table 1.2).
Cooper (2002) has given a number of reasons that hamper the managerial learning. His remarks
as quoted below clearly resonate with and have been augmented by the author’s own expe-
riences and beliefs:
• The misguided prevalent belief that every project is different
• The difficulty in determining the true causes of project performance

18

925836-02_036_17-Feb-15_08:38:49_walter
the scene and money at work

• Projects are transient phenomena and few companies have sufficient resources for the very
purpose of gleaning and improving upon transferable lessons of project management
• While there are individuals who learn, their limited span and career paths make systematic
assessments and learning of transferable lessons that get incorporated in subsequent projects
extremely difficult
• The nature and character of project managers

In order to broaden project management from a skill to a discipline it is essential that the learning
in all phases and at all levels is institutionalised. This requires that time is set aside for captur-
ing the learning of individuals, teams and the project as a whole and to analyse in an open
and honest manner where improvements still could be made and what should have been done
differently in case of a mishap. This should not be done in isolation, only amongst the project
professionals, but in a concerted effort with all players with the aim of further improving the
management of projects as a professional discipline. Another way of transferring learning is that
a project team takes a young upcoming project professional on-board to train them on the job.
Handing over the experience and integrating the learning in the execution of a project is essen-
tial for future success.

There is already vast experience on what can go and what has gone wrong in projects. The
Independent Project Analysis (IPA) company founded by Ed Merrow has gathered an enormous
amount of data via their annual benchmarking process. The top 18 reasons for project failure as
indicated by IPA are shown in Table 1.2. These data have surely matured over time and are by
now based on a very extensive portfolio of completed projects.

Earlier Pinto (1997) showed that lessons could be learnt from past failures (see Table 1.3). In his
article he uses previous project failures as triggers for potential future risks and the accompany-
ing mitigating actions to overcome these. It is concerning that seventeen years later and after
having spent an incredible amount of money, the same mistakes are still being made. Some of

Table 1.2: Reasons for project failure as gathered by IPA

Schedule is calendar driven rather than data driven Optimistic forecasting

Overly aggressive appraisal strategy Wrong contracting strategy

Lack of front end loading Wrong contractors

Lack of clearly defined scope Lack of adequate resources (skills and / or numbers)

Lack of adequate analysis of potential solutions Personnel changes

High degree of complexity / innovation Personality clashes

Incomplete design / design errors Inadequate risk management

Unrealistic plan Lack of adequate change control

Unrealistic budget Lack of understanding of stakeholders aspirations

19

925836-02_037_17-Feb-15_08:38:50_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

Table 1.3: Twelve ways to ruin a project (Pinto, 1997)

Ignore the project environment (including stakeholders)

Push a new technology to market too quickly

Do not bother building in fall back options

When problems occur, shoot the most visible

Let new ideas starve to death through inertia

Never bother conducting feasibility studies

Never admit a project is a failure

Over-manage your project managers and your project teams

Never, never conduct post-failure reviews

Never bother to understand project trade-offs

Allow political expediency to dictate important project decisions

Make sure the project is run by a weak leader

the failures stated by Pinto do overlap with the IPA findings, but the latter ones are slightly more
detailed and already more focused on the front-end loading, where the difference can be made
as explained earlier in this chapter.

Recently Merrow (2011) published a book on industrial megaprojects. In the introductory chapter
of this book he argues that he has seen megaprojects going off the rails due to big mistakes made
by senior managers in the owner companies, not necessarily by the project managers. The main
reason for these mistakes is that these managers or executives have control over the issues that
have the most impact: strategy, money and people. The relationship that has the most influence
amongst the hundreds of relationships a project manager is maintaining, is the relation with his
sponsoring business director. The behaviour of these executives with respect to projects and their
execution has been summarised by Merrow as the ‘Sorry Seven’.

• I want to keep it all


• I want it NOW
• Don’t worry; we’ll work out the details of the deal later
• Why do we have to spend so much up front?
• We need to shave 20 percent off that number
• The contractor should carry the risk; they’re doing the project
• Fire those #$@$^! project managers who overrun our projects

These seven mega-mistakes are very recognisable to most project managers. The seven mis-
takes again in a way support the plea to spend sufficient time on the front-end development,
make sure that we only design what is really required and come up with realistic estimates and
build true relationships with our contractors and suppliers.

20

925836-02_038_17-Feb-15_08:38:50_walter
the scene and money at work

1.11 ! The case study


In order to explain the principles that will be shown throughout this book a case study has been
created to help clarify most of the processes, tools or procedures. The authors are convinced
that some practical examples will help to remember and understand the subjects more easily.
In this paragraph the background of the case is explained and the relevant parties are introduced.
The fictitious case is based on the data of a real project in its front-end development phase. Some
sensitive specifics like numbers and names have been changed for confidentiality reasons. In the
subsequent chapters an effort will be made to explain the content of the chapter by means of
the case. This part of the chapters is titled The Wind Farm and looks like the next page.

21

925836-02_039_17-Feb-15_08:38:51_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


Allwind Energy is the world’s largest supplier of a complete range of products, services
and solutions for the use of renewable energy and power transmission in grids. Last fiscal
year they employed almost 86,000 people and posted sales of € 27.5 billion.
Allwind has greatly expanded its wind power business since several acquisitions.
The number of employees in its wind power division has increased tenfold from 2000 to
approximately 20,000 and sales have increased twelvefold to approximately € 16 billion.
Allwind ranks second in Europe which is considered one of the most important markets in
the world for offshore wind power.
The Wind Farm Energy Polder is a combined onshore and near-shore wind farm under
development in Vento, in the northern part of the Netherlands. Upon completion it will be
the largest wind farm in the country. Owner-operators are members of the Participants
Windenergy Vento, a partnership of more than 100 agricultural entrepreneurs from Vento
and the energy company Esenca.
Due to the size of the Wind Farm Energy Polder and its contribution to the countries
renewable energy target both the spatial planning process and the necessary licences
are subject to a special procedure known as the Government Coordination Scheme. The
draft decisions for the wind farm have been made available for public inspection. All local
residents and other parties concerned have been given the opportunity to submit their
opinion.
Construction of access roads will soon begin as well as the expansion of the 110kV
transport network in order to connect the wind farm (done by the grid operator and
formally outside the project scope).
The wind farm will be located along the coast. A total of 80 wind turbines will be
erected; 50 will be sited near-shore (Allwind, 3 MW) and 30 onshore (Nishati, 8 MW).
The wind farm will produce 1TWh of electricity annually, enough to provide electricity to
400,000 households.
There are currently already 50 wind turbines on the coast shore. The new wind farm will
generate significantly more electricity than the current one, thanks to improved wind
turbine technology. One new onshore wind turbine provides as much electricity as the
current 50 wind turbines put together. It is planned to dismantle the existing wind turbines
once the new farm is constructed.
An estimated total investment of about € 1 billion is required for the construction of the
wind farm (for all 80). Residents in the proximity of the Energy Polder may also financially
participate in a section of the wind farm through an equity participation scheme. The
project will provide a sustainable boost to the local economy. The construction of the
wind farm will ensure employment opportunities. During the construction phase, around
300 new jobs will become available. Once it has been built, the wind farm will help
provide about 100 permanent jobs.
Allwind will be responsible for the turnkey realisation of the near-shore part of the Wind
Farm Energy Polder, including the design, supply, delivery, installation, commissioning
and testing, service, operations as well as maintenance of this 150 MW wind farm in
compliance with all the permits, consents and other agreements. Besides the turnkey
realisation of the wind farm, a 20-year maintenance contract will be signed as well.

22

925836-02_040_17-Feb-15_08:38:53_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

Chapter 3 ! overview
This chapter is dedicated to the project manager, carefully describing what activities she under-
takes, what roles she may have to assume in doing so and the personal skills and competences
required as well as the behaviours she should be able to display in these roles.
The chapter is also dedicated to some aspects of career development and includes a description
of how a competence development programme for project managers could look like. The chap-
ter concludes with a number of personal views from the author on what makes a good project
manager and why someone would choose this career.

Chapter 3 ! outline
3.1 Introduction
3.2 The project manager’s job
3.3 The roles of the project manager and enablers for the right behaviour
3.4 Enabling personal skills and attributes of the project manager
3.5 Competences of the project manager
3.6 Typical career development of the project manager
3.7 Developing the project manager
3.8 What makes a good project manager?
3.9 Why would anyone pursue a project management career?
3.10 The Wind Farm

44

925836-02_062_17-Feb-15_08:39:12_walter
the scene and money at work

Chapter 3
The project manager
by Hans Wierda

3.1 ! Introduction
This chapter is based on the author’s experiences and observations in the energy world, man-
aging projects from early initiation of an opportunity, through development phases to execution
and start-up and covers projects with different degrees of complexity. This includes projects in
a business environment varying from highly regulated in Europe with commercially focussed
partners to highly government controlled environments in the Far East with partners with strong
locally focussed strategic agendas. The author’s experience base is predominantly from a project
manager’s role in an owner’s organisation also responsible for operating the eventual project
deliverables. The chapter henceforth tends to view the project manager’s role through the own-
er’s perspective.

This experience base is dominated by new or additional infrastructural facilities for the pro-
duction (‘upstream’), transport (‘midstream’) or processing (‘downstream’) of oil/gas and energy
generation. However, there are many similarities with large infrastructural projects such as air-
ports, hospitals, tunnels and large factories in mining, ore processing, etc.

Generally the maturation of opportunities into projects and subsequent final decision to invest
and execute, is subject to a stage gate process with activities in each phase aiming to increase
the level of definition and reduce uncertainty. At the end of each phase a sound proposal to
proceed to the next phase is made, covering scope, budget, schedule and resources, all accom-
panied by a transparent description of remaining risks.

The nature of the activities in the development phases is characterised by unleashing creativity,
thinking outside the box to create solutions for an optimal plan. The implementation phases,
on the other hand, are generally characterised by a rigorous discipline to stick to the plan and
procedures with creativity being subordinate to the delivery plan.

In this context the most succinct (and classical) definition of a project manager is that she is
the person responsible for realising a project with clearly defined deliverables within an agreed
schedule for an agreed budget.

45

925836-02_063_17-Feb-15_08:39:14_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

However, that would not necessarily include her involvement and perhaps leading role in the
development process that transfers an opportunity for investment into a firm proposal as well as
obtaining agreements for final investment and execution of the project. This chapter considers
that phase of a project as an integral part of the responsibility of a project manager 1.

The sheer size of the projects as described above (generally in excess of € 10 million) and the
impact they may have on environment and society, demands a multidisciplinary team to manage
the complexity of internal and external agendas, regulatory requirements, industry standards and
compliance assurance processes.

The prime job of a project manager is therefore to be a team leader with a significant versatility
to play many different roles in relation to different stakeholders, from initiation until final hand-
over to the end user, demanding a large repertoire of technical, commercial, communication and
leadership skills.

A more accurate description of the project manager´s job therefore is to lead a team executing all
activities to transfer an opportunity for capital investment into a project with a defined and agreed
scope and deliverables and its implementation within agreed budget and schedule.

This chapter describes what activities she undertakes, what roles she may have to assume in
doing so and the personal skills and competences required to do that and what behaviours she
should be able to display in these roles.

3.2 ! The project manager’s job


The most important aspect of the project manager’s job profile is the leadership to transfer the
opportunity into a project and deliver it. The activities of the project manager are therefore
predominantly driven by the requirements of the processes that most major companies use to
mature opportunities: the stage gate process 2.

3.2.1 The project manager’s job in the development phases


In the development phase the processes are aimed at developing the opportunity from ideas into
a firm definition of the scope along with a budget and an implementation schedule. This includes
a multitude of activities such as:
• Framing the opportunity and fully understanding why the opportunity exists, what the value,
cost and schedule drivers and risks are and what decisions need to be made to reduce risks and
uncertainties to an acceptable level to allow clear definition and execution of the opportunity.

1 This choice is made for the sake of achieving an overview in the entire project lifecycle. In different parts of the infrastructural
industries this might not be the case: within infrastructural contractor companies the responsibility for a project manager often
starts with involvement in a bidding process which from a client’s perspective is well into the implementation phases.

2 Many stage gate processes consist of five phases where there is a lot of commonality in the nomenclature for the phases. For
the purpose of this chapter the author standardises on APPRAISE, SELECT (collectively referred to as Development) and DEFINE
, EXECUTE (together often referred to as Implementation) and OPERATE

46

925836-02_064_17-Feb-15_08:39:17_walter
the scene and money at work

• Identifying risks, issues, potential ‘showstoppers’ in the traditional risk areas of technology,
commercial and in- and external organisational areas 3.
• Based on these risks and issues: identifying scope for studies, surveys, tests, etc.
• Estimating cost, resources and making a schedule for approval, execution and control purposes.
• Obtaining the approvals to execute the proposal.
• Resourcing and building the project team and setting up the network of specialists to support
the team where required.
• Executing all activities to zoom in on the final concept for the scope of the facilities that will be
built.
• Preparing the proposal to move to the next phase of implementation.

The main deliverable of these activities is a conceptual plan for project execution such that
detailed economic evaluations allow comparisons with competing investment opportunities and
to test whether the concept satisfies the owner as well as external requirements. The project
manager’s job is to ensure all of the (greater) team’s activities focus on that final deliverable.

Understanding Value drivers


Key success factor in the early phases is to establish the project drivers: ‘Why are we doing
this project?’ What drives the value for the Owner/Funding Parties?
Examples for possible project drivers for a tunnel under a river:
• provide a tunnel with a certain capacity between the two river banks
• provide a tunnel connection with a maximum cost
• provide a tunnel with a maximum foot print

Without clarity on the priority of these project drivers lower level trade-offs cannot
be made.

3.2.2 The project manager’s job in the implementation phases


During the implementation phase the project manager’s job is twofold: at first she will need
to obtain agreement from the owner on the final investment decision. After the agreement is
obtained she will be expected to execute the project for final handover to the end users. For that
purpose the project team’s activities will include:
• Translating the agreed concept into a firm scope of work that can be used for tendering the
work and test the market of contractors, suppliers and service providers.
• Developing an agreed contract strategy for the full scope of the project including tender and
contract management strategies per work scope for each building blocks.
• Preparing contract documents and execution of all major tenders.
• Selecting contractors, suppliers and service providers.
• Re-building and managing her direct reports and ‘greater’ team of specialists, expeditors.

3 Many companies apply acronyms such as TEMPO (Technology, Economics, Markets, Political, Organisation) or TECOP
(Technology, Economics, Commercial, Political Organisation), TCP (Technology, Commercial, Political) as checklist for risk areas

47

925836-02_065_17-Feb-15_08:39:17_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

• Arranging independent assurance on the robustness of the supporting information for the
decision.
• Awarding and managing all contracts to execute the work.
• Managing the assurance 4 process to prove that the work is carried out as per agreed standards.
• Enabling a safe, efficient, effective commissioning and start-up process to hand over the facil-
ities to the end user.
• Manage the project, contracts and budget closeout and demobilisation of the project team.

Again, the project manager’s job in this phase is to keep the focus of the (‘greater’) project team
on the end deliverables.

In all these phases the project manager is leading her ‘greater’ project team that consists of:
• fewer senior project managers taking responsibility for the delivery of parts of the project
scope with direct line responsibility to the project manager.
• project discipline engineers who are accountable for the integrity of the traditional engineer-
ing disciplines (civil, structural, process, electrical, etc.) in the project deliverables.
• functional representatives such as economists, supply chain, HSE, financial, external commu-
nication and commercial specialists who are accountable for delivery of certain services to the
project (team) but at the same time have to maintain the standards of their function.
• representatives from end-user parties who will eventually operate and maintain the facilities.
• contractors project team with their own project manager (only in DEFINE and EXECUTE).

A major challenge for the project manager are the differences between his own team and the
organisation of his major stakeholders. The organisation of his own project team is predominant-
ly determined by the specific requirements, risk areas, and issues of the project and capabilities
of the project team members and changes when the project progresses through the various
milestones (refer to Chapter 4 for more details).

The organisation in the funding parties (such as in government and governmental execution-
al organisations) and in other shareholder/business partners are designed according to their
own drivers that are party-specific and not related to the project. The matrix organisation in the
major delivery contractor’s teams (only in DEFINE and EXECUTE phase) is partly driven by con-
siderations outside the control of the project manager and imposes an even bigger challenge.
This often results in similar accountabilities and responsibilities assigned at different hierarchical
levels and complicates the job of the project manager (and her team).

3.2.3 The usual stakeholders


Whilst her project team members directly report to her (fulltime or part-time), in bigger compa-
nies, other groups of the ‘greater’ project team (ref. previous paragraph) also have a functional
as well as other organisational responsibilities towards ‘matrix’ leaders who may not have a
direct ownership or interest in project delivery. The project manager needs to negotiate prior-
ities and possible compromises though on functional requirements. For the project manager
this is only one of the many relationships with stakeholders she needs to maintain.

4 Major investment companies demand independent assurance project reviews requiring major project team effort.

48

925836-02_066_17-Feb-15_08:39:17_walter
the scene and money at work

The other stakeholders with whom she may maintain relationships are:
• functional/discipline heads.
• project funding parties within (or outside) the project manager’s company/organisation who
fund the project and who ‘own’ the strategy under which the project is conceived and to
which the project contributes; these are the parties who set the decision criteria to approve
the final investment criteria and who are liable when the project requires more funds than
expected.
• non-operating business partners who have similar but often not the same interests as the
internal investment partners.
• end user of the project deliverables who will operate, maintain the facilities and who will even-
tually be responsible for generating income from the facilities.
• potential contractors who tender to execute work on the project.
• contractors who have been awarded a contract for work on this project.
• regulators and permit approvers.
• external stakeholders who are affected by the project although they do not have any formal
influence on the project.

The next chapter explains what role these relationships demand the project manager to assume
in the course of the project development and implementation phase.

3.3 ! The roles of the project manager and enablers to exhibit the right
behaviour
To execute the activities as described above in the various phases of the project, the project
manager will have to take on various roles of which the nature varies with each stakeholder.
These roles also vary with topics she is dealing with or with the phase of the project or phase of
the relationship. These relationships can be compared to a play where the project manager acts
in different parts. Below a selection of the roles the project manager may assume, i.e. of the ‘parts
she could or may have to play’:

As team leader she will be taking different roles as the:


• director directing the activities of her team;
• ‘the boss’ holding staff accountable for their deliverables and targets;
• recipient of the praise and flag on behalf of the team;
• provider of praise, glory and stick where deserved and appropriate;
• loyal team member protecting staff where appropriate;
• assessor when it comes to assessing performance;
• coach to help her staff when stuck, in need of information, to serve as the sounding board
etc..; friend or colleague if personal problems emerge requiring dedicated approach;
• promoter of proactive creative thinking in the early phases and challenger of over-ambitious
ideas;
• defender of original scope against out-of-scope creative proposals in the implementation
phases for ‘improvement’ but a willing listener to creative improvements.

49

925836-02_067_17-Feb-15_08:39:19_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

As an effective team player in the team of colleague project managers as:


• colleague assisting colleagues with information and support where that matters for the team
objectives;
• competitor in securing scarce funds, resources for her projects;
• competitor for subsequent project or broadening assignment;
• primus inter pares for leading team or companywide improvements.

In the relationship with her direct supervisor as employee:


• serving the company by delivering on her agreed targets;
• being an effective team player;
• displaying the company values;
• safeguarding the company’s interests and reputation.

As ‘matrix’ colleague of functional/discipline heads:


• negotiating for priorities for functional staff;
• negotiating for decisions on deviations from functional or discipline standards.

In the relationship with the decision-making lines/funding approving parties as:


• trusted advisor in safeguarding the company’s interest;
• service provider/partner in delivering the commitments of the next project phase;
• professional specialist to assess and mitigate the project risks;
• ‘marketeer’ of the project content performance to justify approval of funds.

In the relationship with the end user of the project deliverables:


• as a good listener (‘to understand what end users mean rather than what they are saying’);
• involving the end users, in order to ensure their commitment to the project;
• translating the end users’ requirements into cost-effective and user-friendly solutions.

In the relationship with tenderers as company representative of the client as:


• negotiator for the best deal;
• information provider to maximise alignment between partners;
• partner to find solutions for optimal and realistic risk sharing.

In the relationship with contractors as company representative as:


• partner to make it all happen within the contract conditions;
• ‘boss’ to hold the contractor accountable for their target commitments;
• provider of praise, glory and stick where deserved and appropriate;
• firm but fair negotiator on deviations from the contract consistent with the spirit of the
contract.

In the relationship with external stakeholder as company representative as:


• qualified partner for negotiations or information sessions;
• empathetic provider of information desired by the stakeholders;
• empathetic and patient recipient of flag and praise where appropriate;
• empathetic challenger of unreasonable positions or statement of facts;
• patient negotiator for the desired end result.

50

925836-02_068_17-Feb-15_08:39:21_walter
the scene and money at work

In the relationship with non-operator business partners as company representative as:


• trusted advisor in safeguarding the partners’ interest fully aligned with her company’s interest;
• service provider/partner in delivering the promised commitments of the next project phase;
• professional specialist to assess and mitigate the project risks;
• ‘marketeer’ of the project content and performance to justify approval of funds.

In the relationship with regulators and permit approvers as company representative as:
• partner/ambassador who is equally committed to safeguard the intentions of the regulations
as the regulator;
• provider of reliable information who fully understands the intention of the regulations;
• ‘marketeer’ of the company intentions to fully comply with the regulations and/or permit.

3.4 ! Enabling personal skills and attributes of the project manager


The project manager’s major challenge in assuming all these roles is to find the right behaviour
and ‘tone’ – fit-for-purpose for the moment and the stakeholder – but also to be consistent in
jargon, level of information and story line.

For that purpose the project manager will need to rely on a number of personal skills, attributes
and competences in a number of different areas (see Paragraph 3.5) to enable her to intuitive-
ly choose the right behaviour and tone. This also allows her to make conscious choices for a
specific behaviour for a specific purpose; e.g. showing emotions or being confrontational can be
useful under specific circumstances.

These personal skills and attributes are:


• Effective communication to articulate her case to different levels of audiences (shareholders,
CEOs and junior technical assistants) using different methodologies (long short presentations,
mails, private discussions, speeches or teleconferences/VC) on topics that in many cases are
not her specialism.
• Business acumen to make the right commercial judgement in negotiations with external
parties.
• Imagination to role model creativity when needed, balanced with a critical mind when
challenges are needed.
• Wide knowledge of the relevant functions and disciplines and their interfaces with other
discipline and functions.
• Ability to see the bigger picture and almost intuitively sense when detailed attention is
appropriate (‘helicopter view’).
• Ability to analyse data and see the ‘wood from the trees’ and patterns for conclusions.
• Ability to develop and maintain sustainable relationship with others.
• Empathy, genuine interest in people and their drivers.
• Diplomacy for challenging and enthusiasm for praise.
• Passion for professionalism, the cause of the project and company’s interest.
• Controlling emotions but also able to use them as effective tools when appropriate.
• Ability to be contained when she must and confrontational where needed.
• Ability to manage ambiguity and use it as a tool where appropriate.
• Preparedness to lead, back up, be the first where appropriate.

51

925836-02_069_17-Feb-15_08:39:21_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

3.5 ! Competences5 of the project manager


Considering all the activities as described in the previous paragraph, the project manager can
easily be considered a ‘Jack-of-all-trades’ and frankly: she must be one. However, she cannot be
a specialist in all disciplines and hence her most important competence is the ability to delegate
and lead the integration of the many views from different angles on the project into one
consistent and effective approach. She should therefore be able to understand the significance
and proactively apply the decision points in all contributing disciplines she is co-ordinating. That
means she needs to have knowledge and experience in these disciplines and find a balance
between width and depth in one or many disciplines and subject matters affecting her project.

3.5.1 Competences in the development phases


During the development phases of an opportunity the activities are explorative in nature in order
to appreciate the issues, uncertainties and risks in many areas and to identify solutions. This to
avoid that they turn into technical, political or economic showstoppers. It demands an open,
unbiased, creative and imaginative mind-set to value opinions but yet to manage them towards
conclusions. The project manager should be able to create an atmosphere where multifunctional
views are heard and valued, where open and honest discussions can take place, and creativity
and imagination is encouraged to achieve outside-the-box thinking. There are many tools that
can be used for this purpose such as framing, study work, risk identification and modelling, etc.
The project manager therefore needs to be able to either manage these herself (for small pro-
jects) or see that this is being professionally facilitated on her behalf.

At this stage her team almost certainly will consist of staff who are creative, buzzing with ideas
and can relate these ideas to implementation constraints to remain practicable. On one hand the
project manager should promote the creative thinking processes, ensure that the right specialist
staff are involved; on the other hand she should channel their buzzing creativity into the focus
to eventually deliver a firm, realistic conceptual proposal to move forward to the next phase of
maturation.

3.5.2 Competences in the implementation phases


During the first part of the implementation phase however the focus is primarily on firming up
the concept and delivering the agreed scope. This demands a delivery, milestone focus and com-
mitment to stick to the scope, whilst complying with a multitude of quality and governance
related procedures that are perceived by many as bureaucratic. In this phase any creative drive
to change or ‘improve’ the concept and the ways of execution could be fatal for the end result.

At this stage her team will consist of experienced implementation specialists and managers
who do provide that delivery focus but often have not been involved in the concept generating
process and the dilemmas that eventually resulted in the selection of the final concepts. Their
professional experience and lack of natural ownership of the concept will generate new concep-
tual ideas for changes to the concept. This often also applies to external stakeholders who do not
necessarily appreciate the danger of changing the concept after it was supposed to be frozen.

5 For the purpose of this chapter competency is defined as a combination of knowledge, skills, behaviour and proven performance
to perform a job.

52

925836-02_070_17-Feb-15_08:39:21_walter
the scene and money at work

A major challenge for the project manager in this phase is therefore to channel creativity and
imagination towards best implementation practices and solving executional issues and avoid
conceptual changes rather than allowing new conceptual ideas, i.e. control the ‘drive for change’.
Arguably managing this change is seen by many as one of the most important competences in
the implementation phase. In the event changes are indeed likely to improve the overall result,
she needs to manage this in such a manner that all considerations that have led to the initial
concept are reviewed and affected stakeholders are heard to ensure appropriate control over
changes, i.e. manage the change process.

3.5.3 Other major competences


Another important competence is the ability to manage the decision-making processes in the
company or government institutes (the Governance Processes) that are the sponsors of the pro-
ject. This is an important process to obtain project funding based on the strategic objectives of
the project which needs to be aligned with the (capital allocation or political) strategy of the
company or government decision-makers. In this context the project manager needs to be fully
conversant with economic decision criteria and be able to challenge other long-term strategic
drivers that often are not sufficiently articulated.

In the oil/gas/energy and general facilities infrastructural industry, it is not uncommon that up
to 90 % of the work scope of major investment projects is executed by contractors, consultants
and suppliers who are specialists in their own field. The management of the relevant parts of the
Supply Chain processes is therefore considered an integral part of the palette of competences of
a project manager even for small projects.
Although in many cases the project manager will rely on teams to execute the supply chain acti-
vities, she will generally have to lead the development of the contract strategy that will form the
basis for the scope of work for each contract, tender/negotiation tactics and contractor selection.
In addition she will be accountable for the final selection as also she will be accountable for the
final result and will lead the management of all contracts post award.

During all phases the project manager will be responsible for cost, schedule and will be required
to report on progress against promises (budget, deliverables and agreed milestones). She there-
fore needs to lead the process that results in cost estimates that can be used to set budgets,
completion dates, and intermediate milestones. These form the basis for subsequently con-
trolling cost and schedule and to report on progress: i.e. managing the project control processes.
In addition, the nature of the many activities in this industry may have a significant impact on
the health of staff and other stakeholders, safety of facilities and surrounding premises and the
environment. The project manager should therefore be fully committed to HSE objectives, pro-
cesses and procedures and role modelling proactively application of the overall principle that
‘safe business is good business’.

Last but not least the project team and many contributing networks and teams need to be moul-
ded into effective teams, towards high performance using creativity and an effective business
approach. The project manager needs to display that leadership to build and motivate her team.
(See also Chapter 4 for more details how to build a project team). This leadership is required to
drive performance by holding staff accountable for their personal responsibilities and targets.

53

925836-02_071_17-Feb-15_08:39:23_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

3.5.4 Overview of competences


Many competence schemes are developed to enable a structured assessment process. They are
based on a detailed description of the competences as described above and broken down in
many sub-competences. This almost suggests the existence of an algorithm for overall compe-
tence assuming that all have an equal (or even weighted) value.

This drive for exhaustiveness often results in a highly bureaucratic assessment system that adds
more value to assessment system service providers than to the competence development of
staff. It is therefore recommended to keep it simple and to allow a more holistic approach at
major competence level (one of the 8 competences) and use the competence components as
checklist to identify what could be important in gap analysis. A pragmatic breakdown is therefore
provided in Table 3.1.

Table 3.1: List of competences and subcompetences for a project manager

Competences Subcompetences

Applying company strategy to opportunity assessment


Managing Investment Governance (decision making Benefit Analysis for business case
process in a company or governmental institutes) Economics and funding
Managing the assurance process

Manage framing sessions, define Scope of Work


Manage multi-disciplinary front-end engineering
Manage the ‘early’ development phases activities (facilities, subsurface, wells, ops)
Define and optimise project concepts
Manage risk identification and scope definition

Manage FEED and detailed design activities


Controlling Change
Manage Logistics
Manage and define the execute phase Manage Quality
Manage construction/installation activities
Manage OR&A and commissioning
Manage project handover

Applying discipline drivers


Technical and commercial integration
Project Integration
Stakeholder management and communicaton
Managing support functions (HR, IS, Fin, HR)

Contract and tender strategy development


Tender process management
Supply Chain
Contractor & supplier selection
Contract management, post award

Estimating and scheduling


Uncertainty and risk assessment
Project Controls Management Contingency assesment and management
Progress and cost reporting
Manage MoC process

HSE leadership and commitment


HSE competences HSE risk controls
HSE monitoring and improvement

Building and managing teams


Leadership in project environment Motivating skills
Driving performance

54

925836-02_072_17-Feb-15_08:39:25_walter
the scene and money at work

The list of competences focuses on management and leadership skills in a predominantly tech-
nical environment. Larger, more complex projects hence tend to require a smaller technical
component in a PM’s job than smaller projects. Starting a career as project manager without a
technically oriented basic education is therefore highly unlikely.

3.6 ! Typical career development of a project manager


The ultimate goal for an ideal career path for a project manager would be to seek exposure in
all competence areas of a project manager (see Paragraph 3.7). Staying with one project would
provide full-life cycle exposure of development and implementation but there are very few
opportunities to do so. Even if they are available it would only give exposure in one type of
project in a single operating environment.

This leads to the career development ‘strategy’ that aims for a path that should provide:

• exposure to gain experience in the main competence components;


• exposure to different type of projects;
• exposure to different operating environments (e.g. in other countries, different parts of the
world);
• exposure to customer or contractor environment;
• gradual increase in project complexity and monetary value.

An effective ‘tool’ to indeed obtain these exposures, is to change a job and/or employer and
many people with a focussed career development do so.

Another important ‘tool’ that can be applied in career development is the opportunity of a broad-
ening assignment outside the project management arena that provides distinct exposure in one
of the main competence areas. E.g. an assignment in Supply Chain can be a very useful exposure
to understand the tender and contractor market and processes in detail. Similarly an assignment
in business development would provide a project manager a unique insight into the governance
process and decision-making criteria as well as their sensitivities. Other broadening assignments
could be considered in Asset Management, Engineering Management, Business development
(economics, Acquisitions and Divestments, marketing, deal making), Finance (cost control, audit)
and HR (staff planning).

Owing to the large technical content of many infrastructural projects, most project managers
will start their career as discipline project engineers after a degree in one of the technical engi-
neering disciplines that are traditionally contributing to a project team. A successful start in a
project management career requires a full understanding of the interfaces between the techni-
cal disciplines. A project manager’s career therefore tends to be preceded by a period of being
responsible for one of the technical disciplines in a project: e.g. project engineer process or
structural. Being confronted with consequences in her own discipline the project manager will
build up invaluable integration experience that adds to her technical credibility for a long period
to come. A typical career development is shown in Figure 3.1.

55

925836-02_073_17-Feb-15_08:39:25_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

General Management
?

Broadening
Assignment outside
Project Management

Project
Management
Assignment

Discipline
Engineering
Asset Business Human
Management Project Management Supply Chain Finance Development Resources

Graduate Degree

Typical Career Path for Senior Project Director

Figure 3.1: Typical career path for a senior project director

Beyond this first period, successful project managers typically attract assignments in more
complex projects that provide them with more exposure and hence they can build up more
experience and subsequently attract more challenging assignments. Some very generic recom-
mendations are given below:

1. In the early phase of a career: proactively seek the learnings from the exposure particularly
beyond the formal content of the job; only consider job/employer change if no continuous
learning is obtained.
2. Understand your ambition, check it with independent parties (e.g. a mentor outside your
immediate organisation) and be prepared to adjust downwards as well as upwards depending
on opportunities, market circumstances and valued feedback on your potential.
3. First 10 - 15 years of career: develop options and keep them open. Before the last 15 years:
drop options; zoom in to your ambition which may have to be adjusted. Do not job-hop too
often.
4. Do seek broadening assignments during early and middle part of career but do return.
Capitalising on this experience in a more senior project management role will become
progressively more difficult if away for longer than some 4 years.

Why are there so few female project managers despite increasing number of
female discipline engineers?
No evidence exists to suggest that female engineers are less suitable to develop into project
managers than their male colleagues. Arguably their widely celebrated supremacy over
men w.r.t handling the ‘softer’ issues would even suggest a higher suitability. The macho
reputation of the construction world may well scare off female engineers but that may
well be a question of time before that is solved. Those who did pursue a project manager’s
career are subject to the same chance of success and failure as anyone else. For that there
is no recipe and hence suitability is entirely up to each individual’s ability to handle all the
roles of a project manager.

56

925836-02_074_17-Feb-15_08:39:26_walter
the scene and money at work

Duration of projects can vary widely depending on what is defined as project (the full lifecycle
from inception of ideas or as implementation only as is the case in contractor’s organisation).
Even then it can vary from a couple of months for small projects or to 10 years or longer major
infrastructural works depending on technological, funding and regulatory approvals. The tradi-
tional project phases in these long projects are therefore often not executed consecutively
(e.g. owing to permit approval delays). Even if they were, they are often managed by different
individuals whose experience is fit for purpose for that specific phase with its different challenges.
Even in shorter duration projects, owners tend to nominate a person with specific experience for
the Implementation phases than the person who managed the development phases.

From a career development perspective it is therefore also recommended not to focus on


remaining with one project until its very end but by consciously making that decision at each
phase or major part thereof.

3.7 ! Developing the competences of a project manager

3.7.1 Historic background


Project management existed for many years in the industry and many business-oriented aca-
demic degree courses provide optional project management subjects. The concept of project
manager as a profession however has taken longer to be accepted. It first emerged in the aero-
space and defence industries heavily encouraged by the NASA space programmes in the 1960s
in the US. Nevertheless it took a major disaster (Space Shuttle Challenger) before the first Project
Academy was established in NASA6 to educate future project managers in multidisciplinary inte-
gration, perceived as one of the root causes of the failure.

Only during the last decade, major energy companies started to recognise the need for a dedica-
ted competence development programme for project managers. A surprising statistic considering
that project managers directly or indirectly carry the day-to-day responsibility and supervision
for about 80 % of the capital expenditure of major investments.

In the past project management was considered a specialised version of general manage-
ment with very specific application in project management environment in different industries.
Academia hence left it to the industry/companies to design their own bespoke development pro-
grammes similarly to bespoke general leadership programmes for their high potential staff who
were expected to develop to future leaders.

Whilst most companies started with a traditional training approach to individual project man-
agement topics such as planning and cost estimating, from the late 1990s onwards more
comprehensive issues as governance and risk management were added. In addition the benefits
of blended learning (e-learning, on-the-job-exercises and classroom teaching) were instrumen-
tal to designing a more comprehensive approach to many aspects of project management.

6 The Project Management Institute was established in 1969 after a period whereby project management started to be recognised
in the space industry. The first official project academy was also a NASA initiative Academy of Programme/Project & Engineering
leadership which was founded in 1988 in order to tackle a number of the root causes of the Challenger disaster.

57

925836-02_075_17-Feb-15_08:39:27_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 late 2000s more industries characterised by major infrastructural investments developed a
wider (‘academy’) approach (such as in BP, XM, Shell, GSK, Bombardier, AMEC) aiming to provide
a world-class, competence programme to develop a skill pool of project managers capable of
delivering high performance in their companies’ investment programme.

3.7.2 A comprehensive competence development programme for project managers


This paragraph describes an approach that contains elements of all these large companies’
competence development programmes. It is inspired on a number of staff development:
• The spiralling effect from knowledge feeding skills resulting in experience that allows more
knowledge to be gained that results in more skills etc.
• This process can be enhanced by exposing people to new environments (e.g. different coun-
tries, cultures, business environments (e.g. highly regulated, government owned), operating
environment (urban, remote, desert, arctic, on- and offshore) or broadening horizons (e.g.
from project management to business economics or business development or asset owner).
• The pace of competence development depends on a person’s seniority potential, i.e. the high-
est level of seniority a person theoretically is able to reach given unconstraint opportunities.
• Many people are more comfortable with providing knowledge and experience to others than
prepared to ask for the same thereby implicitly admitting the omission of that knowledge.

On this basis a programme can be designed consisting of the following components (Figure 3.2):

ce
r ien Ed
uc
pe at
ex io
ow n
Gr re
Fo
lea c u
su r n sed
po in
Ex g
Kno

ion

Competence
& co
Net m m u n

it i o t &
wle

develop-
it at

n
wor

re c s s m e n

ment
dge

re d

og n
k ingt y

Ac c
t ra n

e
i

A ss

Mentoring
s fe r

& coaching
Figure 3.2: Pentagon model of
Encouragement the Shell Project Academy
& guidance

3.7.2.1 Grow experience by exposure


The objective of this component is twofold:

a. maximising the benefit of on-the-job training.


b. increasing awareness on what type of next jobs/exposures a person should be seeking con-
sidering the career goals she has set herself (Ref. Career paragraph above).

58

925836-02_076_17-Feb-15_08:39:29_walter
the scene and money at work

This can be achieved by career advisors recruited from the senior project managers’ network who
are in regular contact with the project manager and who act as a mentor (see Paragraph 3.7.2.3).

Particularly in the beginning of a career many staff are unaware of many opportunities outside
their current job scope for development (attending conferences, exhibitions, books, membership
of a special task force, professional memberships, attending high level meetings, site visits etc.).
Depending on the size of the company generic career advice can be generated through tools as
a career navigator building on examples of successful careers of role models.

3.7.2.2 Increase knowledge by networking and community building


The underlying thought in this component is that learning and development can be accelerated
significantly by:
• tapping in the wealth of information on best practices and lessons learnt that is available to
anyone who is prepared to ask the right questions to the right colleagues.
• creating a performance-driven culture where consultation and sharing is the norm rather than
an exception.

This is affected by the implementation of a number of knowledge sharing initiatives of which


moderated social networks actively using data bases are the most obvious ones.
The effectiveness of these are then aimed to be further enhanced by creating a sense of com-
munity among the pool of project practitioners in a company or network. Many companies
therefore create professional community events such as Project Management conferences that
are held regularly with an agenda that promotes this knowledge sharing and builds a sense of
community among different layers of seniority in the community.

3.7.2.3 Encourage and guide by mentoring and coaching 7


Whilst any employer would acknowledge the value of effective mentoring and coaching, the two
are often combined. Nevertheless, the emphasis on staff development advice by a mentor can
best be achieved from an independent colleague whereas coaching in the job is one of the prime
tasks of any team leader or someone close in the working environment. In an effective scheme,
the employer is proactively encouraging staff to seek a mentor and broker a relationship with an
independent colleague if they are not successful in finding one themselves (the preferred route).
In any event it is recommendable for project managers to seek consulting relationships with sen-
ior colleagues who are specialist in specific disciplines or functions contributing to their projects.

3.7.2.4 Recognition by assessment and accreditation


This component is driven by the view that:
a. Assessment of staff’s competence gaps assists in identification of development areas.
b. Recognition of performance and competence growth at distinct levels (certification):
– is motivational for further performance and development.
– can be used by employers as selection criterion for more senior positions.
– provide employers the evidence to third parties (partners or clients) that their staff is equipped
with a minimum competence level.

7 For the purpose of this chapter ‘mentoring’ is defined as assisting a person with advise about personal development in a com-
pany beyond the confines of a person’s job whereas ‘coaching’ is defined as assisting a person in the execution of her job.

59

925836-02_077_17-Feb-15_08:39:30_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

Whilst the IPMA accreditation system with four levels of competence of project management 8 is
arguably the most comprehensive programme of accreditation, it is not yet well distributed over
the industry. Yet, most bespoke project management competence programmes also recognise
four levels.

Certification institutes will argue that the independence of assessors, an important prerequi-
site, can only be achieved by external staff. Well-matured project management communities
managing complex projects will argue that only representatives from the same industry (i.e. com-
petitors) can make that assessment but would resist doing so in view of the commercial impact.
This is particularly the case for a reliable assessment of performance effectiveness. Companies
managing major projects will therefore not use external certification for selection purposes but
design and use their internal assessment process.

3.7.2.5 Formal education by focussed learning events


Deliberately last but not the least of the programme components is the formal education where-
by important knowledge is transferred through traditional class room education blended with
distant learning and on-the-job exercises. ‘Deliberately last’ to counter a natural tendency to
stop any perceived competence gap with formal training. Classroom education is the most cost-
ly option to fill a gap in a person’s competence profile. Other development opportunities as
described above under ‘experience growth’ should therefore be considered first and may prove to
be more efficient and hence more cost-effective.

The objective of formal education is to:


• accelerate the upwards spiral of gaining knowledge, skills and experience;
• achieve consistency of approach and compliance with company or industry standards;
• update staff on developments in best practices and lessons learnt;
• promote a knowledge sharing culture;

A comprehensive portfolio of formal education events is likely to focus on major topics such as:
• Governance and Assurance in project management (the stage gate process as well as risk
management and decision-making processes)).
• Fundamentals of project management in Development phases.
• Fundamentals of project management in Implementation phases.
• Project controls (covering cost estimating, scheduling, progress monitoring and reporting).
• Risk management and its translation into contingency management.
• Managing Health, Safety, and Environmental issues in projects.
• Stakeholder management.
• Effective contracting in projects (supply chain management).

More specific topics could be added which often are the result of repeated findings of project
assurance reviews (themes). These may well depend on the very specific issues and circum-
stances of projects in a company.

8 Ref the levels as defined by IPMA: levels A (most senior), B, C and D (entry level)

60

925836-02_078_17-Feb-15_08:39:30_walter
the scene and money at work

In addition, ‘tool box’ courses can be considered targeting project services staff:
• Project progress assessment.
• Planning techniques and estimating tools.
• Benchmarking in project planning and estimating.
• Management of change.
• Monte Carlo simulation in cost estimating and scheduling.

One of the biggest challenges for designing an internally suitable project management educa-
tion portfolio is driven by the lack of standardisation of approach in the industry. Particularly the
processes, jargon and standards surrounding the governance processes affecting cost/budget,
schedules, accountabilities and the level of authority to staff can vary widely per company and
hence require a bespoke approach in education.

Standardisation to one approved portfolio of formal education events preferably from as low a
number of providers as possible is therefore the best strategy for education management.

Since these are scarce in the industry, major investment companies are designing their own
bespoke course portfolios, clearly emphasising the need for consistency and compliance disci-
pline rather than basic skills.

3.7.2.6 Closing notes on competence development


The above programme is obviously designed for a large company with international operations
in a variety of environments. Their project management community is dispersed around the
world and so large that many of the above components such as assessment, mentoring, lectur-
ing during network and education events can be done by senior members of that community.
This in its own right enhances the sense of community. Smaller companies do not have that
luxury and will design a fit-for-purpose programme for instance by teaming up with other com-
panies and/or industry associations.

3.8 ! What makes a good project manager?


Considering the description of the variety of tasks and activities, roles, attributes, personal skills
and competences and the fact that project managers – as human beings – do have limitations
such as preferences, quirks, baggage and other human limitations, one can state that it is impos-
sible to be a perfect project manager at all times.

One of the biggest pitfalls of the project manager in many of these roles where she has to
demonstrate leadership is a tendency to think that the success or failure of (parts of) the project
is attributed to her only. This can easily lead to either prima-donna, ‘bossy’ behaviour or, at the
other end of the extreme, a nervous breakdown.

It is clear that without the many competences representing a wide spectrum of knowledge, skills
and proven performance and effectiveness, she will not be able to do her job successfully but it
is probably even more obvious that without being effective in the many roles (of Paragraph 3.3)
in the relationships with direct stakeholders she would not even have a chance. In this switching
of roles it is easy to take seemingly contradicting positions. A good project manager will find a

61

925836-02_079_17-Feb-15_08:39:31_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

fit-for-purpose, balanced approach without repudiating and compromising her own beliefs, val-
ues and professional integrity.
Arguably the most important of all is the ability to rise above the role of a boss driving results and
lead her team and stakeholders towards success.

3.9 ! Why would one pursue a career in project management?


The desire to pursue a career in project management mainly is a question of taste, personal
interest and drives. Below an attempt for some general pointers:

The job is clearly not suitable for those expecting a 9 - 5 daily work pattern or someone who
thrives in a well-established and predictable work environment. In project management there
is no such thing as a quasi-static work environment since the environment varies with project
progress.

Project managers deal with a variety of topics, without the need but with many opportunities to
dive deep. In the course of her career the project also continuously expands her professional and
social exposure to many different areas and environments and is almost forced into a life-time
learning and development process. Those interested in that ‘never-a-dull-moment’ environment
are likely to find a project management job very rewarding.

Most satisfying of all however are the personal contacts and relationships with an amazing vari-
ety of people with diverse backgrounds, seniority, education and interests among which are
colleagues, owners, contractors, and many other direct or indirect stakeholders. This even starts
at a relative low level of seniority and continuously expands. Together with these parties the
project manager has overcome many technical, economic, organisational, financial, personal
and emotional challenges to deliver a tangible and lasting result for society; a very satisfactory
reward, often combined with an attractive remuneration and further development opportunities
towards general management.

62

925836-02_080_17-Feb-15_08:39:32_walter
the scene and money at work

3.10 ! The Wind Farm


No doubt the project manager job in the case of the wind farm project will predominantly
follow the activities in the various phases as described in this chapter. An illustration of
the integration challenge in the project manager’s job is the consequences of the specific
work streams in this project such as:
• The special government coordination scheme aimed at obtaining operating licenses
as well as land permits will include a very specific schedule with technical details
required in an early stage that would normally only be assessed after freezing technical
concepts requiring significant funding earlier than is justified on the basis of remaining
risks (e.g. not receiving permission and energy subsidies).
• Owing to the size of the project alternative solutions to limit the footprint (number
of cables, substations, cable-shore crossings etc.) might be suggested or imposed by
stakeholders (investors, permit authorities, local stakeholders). This requires significant
early investment in studies, tests and other activities before progress can be made.
• Whilst the government coordination scheme aims at obtaining the higher government
approvals, there will still be a large number of local authority, stakeholder (such
as individual land owners) approvals/permits etc. to be obtained. Depending on
the specific interests of the stakeholders these may impose a significant risk for
implementation progress after sanction. Based on these risks a choice will have to be
made as to which to tackle early and which to leave for later on.

The challenge for the project manager will be to identify the high risk issues for early
tackling, to align the various work stream schedules and to integrate these with the
overarching government approval process. A challenge therein will be to provide a reliable
estimate of cost and schedule up to the next phase in the approval processes.

63

925836-02_081_17-Feb-15_08:39:33_walter
M anag em ent of e n gi n e e r i n g p ro j e cts

Chapter 4 ! overview
This chapter focuses on the team effort that is needed to bring a project to a successful end. It
shows why teamwork is essential and why it should not be taken for granted. It explains which
challenges the project manager faces in developing a group of specialists into a coherent team.
The chapter provides you with several ideas and tools to help you deal effectively with these
challenges. For instance: it provides specific advice on choosing which leadership style to use
in which situation. After reading this chapter you will understand how to select the members of
your project team, how to organise your team and how to lead your team from day to day.

Chapter 4 ! outline
4.1 About the teams
4.2 Creating a project team
4.3 Leading your team: the forming stage
4.4 Managing your team from day to day: the storming phase
4.5 Taking your team to a higher level: the performing phase
4.6 Finishing the job: the adjourning phase
4.7 The Wind Farm

64
Setting Time People
Introduction Preparation Outlook
the scene and money at work

Chapter 4
Building and leading
the team
by Chantal Savelsbergh and Peter Storm

4.1 ! About the teams

What is a team?
The most common description of a team is that it consists of a group of people who work
together towards a joint goal. However, almost any department of any organisation has these
properties. If a group has just these properties then we would still call it a group and not a team.
In order to be truly referred to as a team we believe a group must also have these characteristics:
• To reach the joint goal, the team uses a joint approach (a game plan),
• in which each team member has a unique role,
• which is customised to her specific abilities.
• To guide their efforts along the way the team uses joint performance criteria,
• which all team members have adopted.

Now we can properly distinguish a department from a team. More important: these additional
characteristics imply that a group cannot become a team simply by calling itself a team. In order
to become one, the group must transform itself.

In practice there are different types of teams:


1. Would-be teams: groups who call themselves ‘team’, but which are not.
2. Football-type teams: highly structured teams with a detailed game plan.
3. Basketball-type teams: highly flexible teams in which joint improvisation is important for
success.
4. Baseball-type teams: teams in which individual performance alternates with joint performance.
5. Tennis-type teams: teams in which individual performance is enhanced by a joint spirit.

Is teamwork essential for project success?


Charles Pellerin is a former director of NASA’s Astrophysics Division. He led the team that repaired
the Hubble Space Telescope. When he started this repair project his first objective was to find
out why the billion dollar telescope did not function properly right after it was launched. To his

65
Setting Time People
Introduction Preparation Outlook
the scene and money at work

So, human beings sometimes decide to cooperate with each other and at other times they decide
to compete with one other. The results of various laboratory experiments indicate that people
are more likely to cooperate than to compete with each other when they:
• are insecure about the circumstances they are facing and about what is going to happen.
This phenomenon can be seen when a group on a sailing trip suddenly is confronted with
bad weather. We can call this the security effect of cooperation;
• have a desire to accomplish something which they cannot accomplish individually.
We can call this the performance effect of cooperation;
• have strong feelings of belonging together. Of sharing the same norms and values.
We can call this the socialisation effect of cooperation;
• expect that helping someone else will bring a reward of some kind. This we can call the
rewarding effect of cooperation;
• expect that working together with someone else will teach them something new. Something
that can help them in the future. We can call this the learning effect of cooperation.

You as a project manager should be aware of these basic drives and apply them wisely in your
role as a team leader.

Natural stages of team development


Teams do not automatically perform at the optimal level from the first day onwards. People have
to settle into their roles. They have to get to know each other and adjust to the style of the leader,
the project manager. Extensive research has been done into how teams are being formed. That
development goes traditionally through four or five stages. These stages are also known as form-
ing, storming, norming, performing and adjourning. The fifth stage is not always included, but is
definitely important for a project team, that has by design a short and discrete lifetime.

In the forming stage trust and interpersonal relations have to be built. The team needs to find
its place and so do the members of the team. Not much work will be achieved, but people will
learn how to deal with each other. People are typically very much on their own initially, feelings
are not dealt with and weaknesses are covered up. This is probably a good time to agree the
team charter. Agree how people want to work together and how issues will be resolved. This is
the time for setting the standards for the project together and by doing that learn to join hands.
At the second stage, the storming stage, people will start experimenting. Boundaries will be test-
ed, feelings being raised and the concern for others will grow. Some stressful negotiations will
take place in order to establish positions and mutual dependencies. The team feeling will grow
and the charter will be tested and deepened.

At the third stage, the norming stage, roles become accepted, the team starts developing based
on agreed procedures, methodical working and established and tested ground rules. In the final
operational phase, the team is fully effective and performing. More use is made of the abilities
of the team members and the available energy. The needs of all participants are met and the
social aspects are duly considered. The leadership style is appropriate to the phase the project has
reached. At the final stage of the team, the team will be disbanded and adjourn. One of the chal-
lenges for the project manager is to make sure all her team members, with whom she has worked
for the duration of the project, find a new project or a new position in the line organisation. The
selection of her next team might be dependent on how she dealt with her previous staff.

67
M anag em ent of e n gi n e e r i n g p ro j e cts

The challenges of building and leading a team


What you have been reading so far gives you several clues of what it takes to build and lead a
team:
• First, you must understand yourself as a team member. This may sound strange because you
are the leader, are you not? However, reality dictates that you cannot ask your team members
to be good team mates if you are not one yourself.
• Second, you should find out what your project demands from your team. What kind of team is
needed for your project.
• Third, once you know what kind of team you need for your project you will have to select your
team members. Not only the selection itself can be a challenge. In many cases the project
manager, you, will not automatically have a say. Hence, you will have to somehow ‘wriggle’
yourself into the process.
• Fourth, when your team members have been selected you will start to mobilise them. This is
easier said than done because most of them will have other obligations. The challenge is to
convince them that when they spend a little time now in getting acquainted with you, the
project and each other they will save a lot of time later on.
• Fifth, after mobilisation comes the most challenging and rewarding part of leading a project
team: developing your team into a well-oiled machine.

4.2 ! Creating a project team


What kind of team does your project need?
Not a would-be team obviously. Earlier we offered you a choice between four types of real teams.
Let us analyse with the help of Table 4.1 which type is needed when:

Table 4.1: Types of teams

Which type of team? When?

Operational projects that require simultaneous, well-coordinated


Football-type teams: highly structured
efforts from a large number of people. An example is a so-called
teams with a detailed game plan.
turnover project in the process industry.

Basketball-type teams: highly flexible Tactical projects that require flexibility through improvisation and
teams in which joint improvisation is adaptation to changing circumstances. Rescue operations are an
important for success. example of such projects.

Baseball-type teams: teams in which


Technical projects that alternately require individual expertise and
individual performance alternates with
collective coordination. For example: product development projects.
joint performance.

Tennis-type teams: teams in which Small projects that require most of all individual ingenuity, expertise
individual performance is enhanced and perseverance but cannot do without group support. For
by a joint spirit. example: fundamental research projects.

68
Setting Time People
Introduction Preparation Outlook
the scene and money at work

This book focuses on the first type of projects: Operational projects that require simultaneous,
well-coordinated efforts from a large number of people. These projects need well-oiled organi-
sational machines so to speak. The success of such projects depends to a large extent on the
care with which:
1. the project organisation is structured,
2. the tasks among team members are distributed,
3. these tasks are executed and
4. the execution activities are synchronised.
If these four conditions cannot be met the project may end up in chaos.

How the team can be organised


In the case of larger engineering projects the project manager will normally be a part of a
business development team. The business developers have, based on market information, on
contacts with prospective clients or with resource holders, come up with a possibility to develop
a new opportunity (a plant, a factory, a plant extension, additional storage capacity). The direct
stakeholders in this new venture will for the duration of the project be the business opportunity
manager, the project manager, the future operations manager and possibly the (new) technology
manager. This so-called asset development team will be governed by a steering team consisting
of line and commercial managers (see Figure 4.2).

Project
sponsors

Steering
committee

Venture Project Operations Technology


manager manager manager manager

Asset Development Team

Business
Project Operations
development
team team
team

Figure 4.2: Venture team and related governance and assurance

Assuming that the project manager or project director is already nominated by the powers
in charge – either the board, the head of the project department or the engineering manager
(with input from the project sponsors and/or the steering team) – her first task after trying to

69
M anag em ent of e n gi n e e r i n g p ro j e cts

understand what the project is all about is to find herself a team. This course will be a cascading
process. First the project manager will decide what types of roles are required to manage the
project towards successful completion.

Depending on the size and the complexity of the project more or fewer roles will be required
to manage the project in all its aspects. But traditionally the project team will consist of various
project engineers, a project controls or finance controls expert, an engineering manager, a con-
struction manager, a planning and estimating engineer, a contracting and procurement specialist
(either combined or separate) and a quality assurance/quality controls engineer. All these roles
will report to the project manager although with bigger projects some of the roles will report to
the project services manager, who quite often acts as the deputy of the project manager (see
Figure 4.3).

Project
manager

Finance Quality

Manu-
Engineering Contracts Planning Procurement
facturing

Figure 4.3: Project team with a number of required functions

The preceding paragraph identifies the basic functions to be fulfilled in the project. Each of these
functions makes a unique contribution to the development of the project. However, all of these
contributions are interdependent. Interdependency can take on different forms:
• Pooled interdependency. This means that different functions share the same resources.
• Sequential interdependency. This means that one function depends on the outcomes pro-
duced by another function.
• Reciprocal interdependency. This means that two or more functions are simultaneously
dependent upon each other.

A proper organisation of the project, therefore, does not only describe how the functions are dis-
tributed but also how they are coordinated. Coordination can be accomplished in various ways:
• Through direct supervision by a team leader. For example: a decision made by the team leader
to form a temporary task force to jointly solve a problem that cannot be solved by each of the
functions alone.

70
Setting Time People
Introduction Preparation Outlook
the scene and money at work

• Through formal guidelines. For instance a chart describing who has what kind of responsibility
and authority with regard to which kind of issue. This is called a RACI chart (see Table 4.2),
where R stands for Responsible to take action, A for Authorised to decide, C for must be con-
sulted and I for must be informed.

Table 4.2: Example of a RACI chart for the execution of a project

Businiss Opportunity Manager

Site Operations Manager


Decision Review Board

Construction Manager
Decision Executive

Project Managers

Site HSE Manager


Task & Responsibilities

HSE Consultant

Contractors
Implement HSE project plan (and sub HSE plans) A I t R C C

Governance A I R C C I C I

HSE management A I R R C C I

HSE targets I I A R C C C I

Communication / HSE in meetings A R C I

Toolbox process I A C R I

HSE monitoring (rounds / audits) I A R C R I

Management of change I A R C C I

Contractor selection A R C

HSE project introduction C R I

Emergency respons I A C R I

HSE in workplanning and execution A C R I

Permit to work process I A C R I

Risk assesments A C R I

HSE supervison A C R I

Incident management A R R R C I

Waste management A R C C R I C I

Competence and fitness to work A R C R I

Process safety in design and construction A C R C I

Business leadership

Project leadership

Project team members

Site leadership

Contractors

71
M anag em ent of e n gi n e e r i n g p ro j e cts

• Through formal and informal communication. Time schedules together with progress meet-
ings are examples of formal communication which aims at coordinating the efforts of the
different functions.
• Through training and drilling. This involves training combinations of functions to attain the
highest possible level of joint competence and to practice coordination in try-outs. In sports
teams this is the most preferred way to improve coordination. In business teams it is the least
widely used.

In complex engineering projects all four are needed. It is up to the team leader to combine and
synthesise these four means of coordination. For many team leaders in established organisations
this is a challenge because they often do not feel authorised to adapt the formal guidelines, not
influential enough to change the informal communication and not skilled enough to train and
drill their team. It is a fact of life for most project managers that their authority to make deci-
sions and change the rules is very limited. However, there is another way. So far we have been
talking about ‘functions’. A function is an abstract thing. A construct. But the people who fulfil
these functions are not. Given the limited authority a project manager has, it is crucial that she
acknowledges this fact to the fullest extent. In the next paragraph we will explain why and how.

What is your leadership style?


When you start leading a team you will be regularly confronted with dilemmas.
Forinstance, when you have to make a decision quickly: will you take the time to
listen to suggestions made by members of your team before you make the decision or
not? Or, when you notice that a team member is struggling with a task: will you give
her specific advice or will you let her find out for herself? There are advantages and
disadvantages to ‘both sides of the coin’.

Over a period of time team members will notice a basic pattern in the way you handle
these dilemmas. For instance they might notice that you tend to behave in a directive
style. Which means that you (a) have the final say over decisions, (b) rarely include team
members in your deliberations, (c) reward team members for doing the right thing and
punish them for what you consider to be misbehaviour and (d) give precise instructions to
team members on how to do their work. Or, alternatively, they might notice that you have
a participative style of exerting leadership. Which means that you include team members
in most of the decisions that have to be taken. In this style you share your leadership
responsibilities with your team. A third leadership style that is often recognised is the
delegative style. When you use this style you delegate as much responsibility to your
team members as you can. You treat your team members as responsible and experienced
professionals who know what they have to do and how to do it. You focus on stimulating
and inspiring them, rather than punishing or rewarding and on dealing with the external
issues of the team.

The way you have been reared by parents, teachers and leaders during the first phases of
your life probably has a great influence on your natural leadership style. As you take on
the role of a leader yourself it is important that you are aware of what your natural style

72
Setting Time People
Introduction Preparation Outlook
the scene and money at work

is. You can assess your style by taking one of the available tests (see for instance: http://
psychology.about.com/library/quiz/bl-leadershipquizb.htm) and by asking feedback about
your behaviour from those who work closely with you. The general opinion of those who
study leadership is that there is no such thing as the ‘one best leadership style’. In certain
situations the directive style is most effective, in others it is not. For instance, in dangerous
situations where immediate threats are present it is probably best to apply the authority
you have, give clear instructions, correct misbehaviour and take decisions quickly. Earlier
in this chapter we wrote about experimenting with your leadership style. Finding out
which style works best in which situation. If you do not experiment with your leadership
style then your effectiveness as a leader will wear out in the long run.

Selecting the members of your team


In most cases the members of a project team are selected and assigned by higher management.
The project manager needs to make the best of what is assigned to her. However, there is always
a moment when you have the opportunity to influence the selection process. This means that
you have to reflect about what you consider the best possible composition of your team and
express your thoughts to higher management.
On the one hand you want the best specialists available. On the other hand you want the most
devoted team players. So it comes down to finding a good mix.

Climbing Mount Everest


The first Dutch expedition to conquer the Mount Everest was launched in the early
nineteen eighties. This team consisted of the best and most experienced climbers
available at the time in the Netherlands. It failed because of poor teamwork. One reason
why the teamwork was poor had to do with mutual competition within the team. Every
team member wanted to be the one to reach the top.

A couple of years later, in preparation for the second attempt, it was decided to select
a limited number of ‘top climbers’ and add a number of ‘supporting climbers’. In order
to make the expedition attractive to these supporting climbers they were given the
opportunity to improve their personal record regarding the highest level they had ever
reached. This expedition was a success.

Who are the ‘best specialists’? Is the number of years of working experience decisive? Or is it
something else? Of course, years of experience is a relevant criterion. But it tells you only what
a person potentially can accomplish. It does not say anything about what she wants to accom-
plish. So, what you want is someone who is experienced and motivated. What motivates people?
Well, general motivation theory tells us that people tend to be motivated when the job is:
• Challenging in the sense that it is neither too easy nor too difficult.
• Rewarding in the sense that their personal achievement will be recognisedrecognized and
rewarded.
• Instructive in the sense that it provides the opportunity to gather new knowledge and insights.

73
M anag em ent of e n gi n e e r i n g p ro j e cts

Complex engineering projects potentially provide all of this. But not in the same way. For some
projects the crucial success criterion is to do the project in the most efficient and cost-effective
way possible. For other projects the crucial success criterion is to manage the external risks as
completely as possible. And for still other projects the main criterion is to apply brand-new tech-
nology successfully. Each of these provides different ways of making the jobs within the project
team challenging, rewarding and instructive. It is up to you to find out what the primary success
criterion of your project is and to find specialists who want to be part of it. Higher management
rarely has the opportunity to talk extensively with specialists about their motivation. You can
create that opportunity for yourself and influence the selection process indirectly by inspiring
enthusiasm on the part of the specialists of your choice. If they are enthusiastic they will ask to
be included in the team.

Who are the most dedicated team players? The answer is rather simple: the most dedicated team
players are those who put team play above anything else even if they are the only team player in
the group. Generally speaking: the less the team spirit in the group the more effort team players
will spend to restore it. This implies that you do not need that many dedicated team players. But
it also implies that you must make an effort to recognise and acknowledge their contribution to
the team. This is easier said than done because dedicated team players do their job in a very sub-
tle – almost invisible – way and they are not apt to ask for recognition. Above all, do not make
the mistake to judge a team player solely on her performance as a specialist.

In order to identify team players you can use the ‘Are you a team player?’ test. Not in a formal
sense like: ‘Hey can you do this test for me?’ but in an informal sense by just talking to people and
asking questions in such a way that they do not feel judged. Do not hesitate to adapt the test so
that it corresponds closely to what you think is characteristic of a team player.

Are you a team player?

In each of the following situations you have three options. For each situation select one option which is most
applicable to you.

1. When we have a quarrel at home, then I


A. will do my best to maintain a peaceful atmosphere.
B. will try to mediate and refrain from becoming involved.
C. will seek support from others.
D. ask myself if this issue is worth a quarrel.

2. If I were to be asked to take up a position on the board of a community service organisation,


then I will say
A. yes if I believe that the board and I can make a success out of this.
B. yes if it fits in my time schedule.
C. yes if I believe that the service organisation really needs me now.
D. no to find out how badly they need me.

74
Setting Time People
Introduction Preparation Outlook
the scene and money at work

3. When I arrive late at a meeting, then I will


A. quietly find my place and start to listen.
B. apologise and ask which point of the agenda is being discussed.
C. apologise and listen quietly to find out what the discussion is about.
D. make a joke to relieve the pressure.

4. If my team is being criticised by someone outside the team, then I will


A. bring in the criticism at the next team meeting.
B. defend my team and challenge the person giving criticism.
C. ask that person to inform my team of his or her criticism.
D. listen politely and refrain from an immediate reaction.

5. When a colleague in my team has done a fantastic job, then I will


A. immediately seek her out and congratulate her.
B. organise an informal celebration at the end of the day or week.
C. send an email to congratulate her.
D. wait till I happen to meet her and congratulate her.

6. If we encounter a serious problem in our work, then I will


A. start looking for a solution as soon as possible.
B. inform higher management as soon as possible.
C. bring various people together to find a solution.
D. first determine the urgency of that problem before I do anything else.

7. If a colleague, with whom I work together regularly, tells me in confidence that she is looking for
another job, then I will
A. try to keep her for our organisation.
B. advise her to go for her best interests.
C. explore her motivation for wanting to leave our organisation.
D. show respect for her choice and explore the consequences of her decision for our team.

8. The best working environment for me is one


A. in which I can do my job according to my own belief.
B. which is stable and supportive.
C. in which joint performance is more important than individual performance.
D. in which vision and strategy guide the actions and interactions of people.

Your score

For each time you have chosen one of the following options add ‘1’ to your score. Start with a score of ‘ 0’.

Question 1 Question 2 Question 3 Question 4 Question 5 Question 6 Question 7 Question 8

B A B B B C D C

If your score is higher than five, you are most likely a team player.

75
M anag em ent of e n gi n e e r i n g p ro j e cts

4.3 ! Leading your team: the forming stage

Kicking off with your team


Once you have your team assembled it is time for a kick-off. To kick off you can have a meeting
with your team in which you explore the project. When you prepare this meeting make sure that:
• Everyone knows the essence of the project, what it is about. Its goals, deliverables,
constraints, challenges, risks and opportunities. In headlines, not in detail.
• Each specialist has prepared a brief presentation about her personal goals, deliverables,
constraints, challenges, risks and opportunities. Again, in headlines, not in detail.
• All team members are present.
• You have an agenda which allows you to try out the three different leadership styles
mentioned earlier.
• You have in mind what you want to observe in your team.

Tools to help you


Ideas for an agenda which allows you to try out different leadership styles are given in Table 4.3.

In the following practical example all aspects of a project play a role. The task at hand is restricted
in time, a true team effort is required to ensure a successful outcome, the task is non-routine – it
is not something you do every day, it requires meticulous planning and it can be risky if you do
not take the right precautions.

Practical example
As a team (4 - 8 persons) you are to arrange a 10 meter long endless rope into a perfect
square. While you are doing this each of you is blindfolded and each of you should
actively participate in the task. You may determine the precision of your square and
you should perform the task of rearranging the rope within 5 minutes (from the moment
you touch the rope). You have 30 minutes to prepare yourself for this job; 15 minutes
of these should be devoted to searching and selecting a solution and 15 minutes should
be devoted to designing a procedure.

Figure 4.4: The project ingredients

76
Setting Time People
Introduction Preparation Outlook
the scene and money at work

Table 4.3: Agenda for trying different leadership styles

Topic Ideas for how to address this topic Your style

Give an Elevator pitch. Stand up and


Directive style. Be brief and firm. Show
What is this project write down some essential points.
your commitment to and enthusiasm for
about? Invite questions which ask for more
the project.
information. Restrict discussion.

Invite team members to share their


experiences regarding working in
a project team. Note all positive Participative style. Lead the process
What kind of team does
experiences. Introduce the idea that but limit your own input. Stimulate
the project need?
‘different projects require different interaction and joint exploration.
teams.’ Ask the team to jointly describe
what kind of team this project needs.

Find one or two team exercises on


the internet and do these with your
team. Ask the team to evaluate the way Delegative style. Give clear instructions
What kind of team are
they worked together and compare at the start and then sit back and
we now?
the outcome with the outcome of the observe.
preceding step (‘what kind of team does
our project need’).

Ask your team to design:


• A team structure: who is responsible
for what?
Participative or Delegative style,
How are we going to • A mutual dependency chart: who is
depending on what your natural
organise ourselves? dependent on whom for which tasks?
leadership style is.
• A communication plan: what kind of
meetings do we need? How do we
keep each other informed?

Tell your team how you intend to lead


and control the project and what kind Directive style. However, do not hesitate
How will I lead and
of contribution you ask of them in order to show yourself as a real life person
control this project?
to make it possible for you to lead and rather than just as a manager.
control the project successfully.

Ask your team members to share with


each other what they ‘take-out’ of this Participative style. Do not hesitate to
Round up session, how they feel about being part be open and frank about your own
of the team and which questions still thoughts.
remain on their mind.

77
M anag em ent of e n gi n e e r i n g p ro j e cts

Ideas for an observation list which helps you assess the strengths and weaknesses of your team
are given in Table 4.4.

Table 4.4: Assess strengths and weaknesses of a team

What you want to


What to observe
know about your team

• Do they ask for each other’s opinion? Are the less outspoken members of the
Do they interconnect? team invited to speak up?
• Do they show interest in each other’s expertise, experience and personality?

• Do they raise and discuss the question ‘what do we want to accomplish now?’
Are they goal-oriented?
• Do they refer regularly to the goals and deliverables of the project?

Do they manage the


team process?(this • Do they raise and discuss the question ‘how shall we approach this?’
topic is only relevant • Do they stick to the approach that was agreed?
when you use a • Does someone lead the discussion and is this person accepted by all as a leader?
delegative style)

Are they action • Do they regularly repeat the same points of view?
(progress) oriented? • Do they work towards joint conclusions?

Do they explore the


• Do they look for solutions for dealing with the constraints of the project?
challenges of the
• Do they share knowledge about the stakeholders of the project?
project?

Do they reflect about


themselves and the • Do they reflect on the process (how it was accomplished)?
way they are working • Do they share feelings about their mutual relations?
together?

Do not expect your team to score high on this list during the kick-off. That would be unfair
because hardly any group has all of these properties right from the start. The idea is that you start
observing your team objectively.

78
Setting Time People
Introduction Preparation Outlook
the scene and money at work

4.4 ! Managing your team from day to day: the storming phase

Issues
The day to day issues of managing a project team are manifold. We will explore those that you
are most likely to encounter. It is up to you to lead your team through this storming phase and
introduce the routines they need to deal with these issues.

Which issues can you expect?


• Soldiering: some team members are not pitching in as much as they should.
• Intra-team conflicts: task related disagreements become personal confrontations.
• Inter-team conflicts: your team experiences difficulties in dealing with another team which is
somehow involved in the project.
• Not delivering on time: ignoring the time schedule, not knowing what the time schedule is or
making excuses for not delivering on time.

Acknowledging that these things may happen is the first step in curing them. They are quite
natural phenomena and it does not really help to become irritated when you encounter them.
We will give you some simple and straightforward advice on how to deal with each of these
issues.

Soldiering
Why are some people not pitching in as much as they should? This may happen because they
have other obligations which occupy their minds and hearts more than their contribution to the
project. A very common phenomenon in projects. Another cause might be that someone does
not feel comfortable with her position or role in the team. Yet another cause can be that some-
one is not fully aware of what is expected or does not feel capable of meeting these expectations.
Three different causes that require different solutions.
The first step is to find out what the major cause of soldiering is for this team member. This
requires a private conversation in which you lead the way by showing sincere interest and using
open questions. Do not address this issue in public and do not gossip about this person.

Once you have established what makes it difficult for someone to contribute fully to the team
effort you aim at finding a joint solution. As indicated, different causes call for different solutions:
• Being occupied with obligations outside the project is, at core, a rational problem that needs
to be addressed in a rational way. A rational solution, for instance, is to temporarily reduce the
workload. Our standard cause of action here is to make sure that the team member focuses on
her contributions to the work of other team members. This prevents the person involved from
isolating herself and, potentially, dropping out of the team.
• Not feeling comfortable with the team or the specific role in the team is, in essence, a
social-emotional problem. There are no rational solutions in such a case. There are courses
of action which can be taken but you will have to find out by trial and error what works and
what does not. Different options are, for instance: invest more time in social team activities,
give the team member a special assignment which requires frequent contact with other team
members, reassign her to another position in the team, hold intervision sessions with the team
in which personal experiences are addressed and explored in a way that is non-threatening or
select a personal coach.

79
M anag em ent of e n gi n e e r i n g p ro j e cts

• Not being able to live up to the expectations of the job is both a rational and a mental problem.
Sometimes the problem is relieved by specifying more precisely what is expected. In oth-
er cases it helps when performance goals and learning goals are separated and a course of
action, such as additional training, is chosen to help reach the learning goals. On the mental
side it is up to you as a leader to invest more time in coaching the team member involved. The
conversation with which you started the process will have given you insight into what kind of
challenges and what kind of support works best with this person.

Intra-team conflicts
Disagreements among team members are like wake-up calls. They take the team out of its com-
fort zone and challenge it to review its assumptions about the true nature of the problems it
faces and about the preferred solutions to these problems. It is up to you to guide your team
in dealing with disagreements in such a way that they come up with better joint solutions. And
to prevent disagreements from becoming interpersonal conflicts. In order to do so you need to
understand why task-related disagreements can become interpersonal conflicts.
Basically, disagreements tend to become interpersonal conflicts when there is not only a clash of
opinions but also a clash of social styles. What people say to each other becomes less important
than how they say it. Some people talk more in an asking way: they state their opinions more
carefully and speak in a softer voice. Others talk more in a telling way: they state their opinions in
a more authoritarian way and tend to speak in a louder voice. Some people talk more in a con-
trolled fashion focusing on facts and limiting small talk. While others are more emotive in the way
they talk, expressing feelings and involving in small talk. When we combine these different ways
of how people talk to each other we end up having four different social styles:
1. Analytic: talking in a controlled and asking fashion.
2. Amiable: talking in an emotive and asking fashion.
3. Driving: talking in a controlled and telling fashion.
4. Expressive: talking in an emotive and telling fashion.

When nothing is at stake and the surrounding atmosphere is relaxed, like at a party, these different
styles tend to mix well with each other. Together they create variety and make the conversation
pleasantly unpredictable. When the stakes are high and the atmosphere is tense, the opposite
may happen. People with a driving social style may become irritated by the amiable style used
by others and vice versa. They do not understand each other anymore, both at the content level
and at the relational level.
Recognising these different styles can help you draw attention to the underlying phenomenon
of social styles and bring them to the table. Call for a time-out and ask team members to stop
talking about the content for a moment and start sharing what they noticed about how they are
talking to each other. It is up to you to help your team recognise and deal with this phenomenon.
Once they learn to appreciate the different social styles rather than feel bothered by them they
will find it easier to separate content from style and avoid getting into a fight just because the
styles are different.

80
Setting Time People
Introduction Preparation Outlook
the scene and money at work

The next step in preventing disagreements from becoming interpersonal conflicts is to set the
ground rules of collaboration within the team. What kind of ground rules? We suggest behaviour-
al ground rules rather than intentional rules. Behavioural rules are for instance:
• ‘Be on time for meetings’.
• ‘Appreciate other points of view even if you disagree’.
• ‘Talk with others, not about them’.
• ‘Bring conflicts out in the open and take responsibility for solving them’.

The way to set the ground rules of cooperation is to do it in a cooperative or participative way.
Ask each team member to recollect and share a previous experience which has shaped her opin-
ion on how to collaborate in teams. Share one or two of your experiences too. Stimulate your
team members to inquire further about these experiences. Why is a particular experience impor-
tant to someone? What has she learned from it? How does she apply what has been learned? It
takes some time to do this.

Inter-team conflicts
In complex engineering projects we rarely see just one team being involved. As mentioned ear-
lier, at the owner’s side there are the business development team, the project team and the
operations team. At the contractor’s side we can also identify multiple teams, such as the design
team, the materials supplier team(s) and the construction team. Complex engineering projects
are temporary alliances between organisations and their teams. The performance of the alliance
as a whole has more influence on project success than the performances of the separate allies.
Hence the degree of collaboration between the different team leaders and their teams is crucial.
Collaboration between teams and their leaders in a project is commonly guided by contracts,
policies and procedures, information systems, a coordinator or coordinating team and by the
decisions made by the agreed decisions makers. As the risks involved in a complex engineering
project are huge it is common to invest quite some time in designing, aligning and implementing
these different coordinating mechanisms. Does that mean that you, the project manager, can rest
at ease and focus just on leading your own team? No, not at all. Remember Pellerin (NASA) who
discovered that the human factor is more decisive than any other factor. The human factor can
only be controlled to a limited extent through the formal mechanisms mentioned above. There is
no contract, procedure or policy that guarantees you will not experience inter-team conflict. You
have a responsibility for preventing and solving inter-team conflicts. How to go about it?

First try to develop some degree of team spirit among the various team leaders. The very least
you can and should do is to hold occasional and informal off-site meetings in which you share
experiences, inform each other of planned or otherwise expected actions, talk about joint prior-
ities and review the quality of collaboration among the teams. Second, hold frequent meetings
with your team to explore: their interfaces with other teams, the degree to which your team
structure matches the structures of the other teams, how the communication channels with
the other teams function. Look for small and simple improvements on your side and implement
them rapidly. Third, help your team understand the differences in the way-of-working of the
teams they need to collaborate with. Pellerin’s four-dimensional framework of team cultures may
help you with that (see Figure 4.5).

81
M anag em ent of e n gi n e e r i n g p ro j e cts

Intuited information

1. Cultivating Dimension 2. Visioning Dimension


(Human Need: To feel appreciated) (Human Need: A hopeful future)
Social Context: Mutual respect, enjoyable work, Social Context: Sustained, efective creativity,
willing engagement and collaboration. seeing innovative solutions.
Achieved by: Expressing authentic appreciation Achieved by: Expressing reality-based optimism
and addressing shared interests. and being 100% committed.

Emotional decider Logical decider

3. Including Dimension 4. Directing Dimension


(Human Need: To feel we ‘belong’) (Human Need: To meet other people’s expectations)
Social Context: Authentic, aligned, action with high Social Context: Outcome focus, no blamers or victims;
trustworthiness and efficiency. clear achievable expectations.
Achieved by: Appropriately including others and keeping Achieved by: Resisting blame / complaining, clarify roles,
all your agreements. accountability and authority.

Sensed information

Figure 4.5: Pellerin’s four-dimensional framework (Pellerin, 2009)

What the framework tells you is that all people have a basic need for Being Appreciated (box 1),
Being Included (box 3), Having a Positive Vision (box 2) and Meeting other People’s Expectations
(box 4). Despite the fact that all people have these needs, very few teams are able to establish
and uphold the values and norms that are needed to fulfil all of these needs equally. Some teams
tend to become Green more than any of the other colours. When you visit such a team you feel
respect and appreciation from the moment you arrive. The team from box 1 will take time to get
acquainted with you. However, when you try to do concrete business with a team from box 1
you will experience some difficulties. A team from box 1 is not very capable of designing time
schedules to which they will stick whatever happens. You will hear things like ‘Just trust us, we’ll
do the job’. When you visit a team from box 4 on the other hand you should not expect them to
take much time to get acquainted and exchange appreciative things about each other. They will
like to come to the point as soon as possible. A team from box 4 will prefer to analyse the facts
rather than the people. A team from box 4 is proud to be in control. Each of these four dimen-
sions is related to two behavioural norms. For instance ‘Keep your agreements ‘(box 3). You can
help your team become a more complete team by:
• Observing which norms are being adhered most in your team.
• Discussing the other norms and explaining how important they are in dealing with teams
which have a different colour.
• Practising the application of these other norms at various occasions. For instance during team
meetings.

Not delivering on time


This happens a lot even when your team members are all working hard. Why is that? Well, the
throughput time of a project is not really influenced very much by variations in how hard every-
one is working. Of course, at the extremes it is. When everyone is doing nothing the throughput
time will increase tremendously. However, we are not talking about extreme situations here.
Instead we focus on what happens normally. And under normal circumstances the throughput
time will be influenced much more by what happens between people than by what everyone is

82
Setting Time People
Introduction Preparation Outlook
the scene and money at work

doing by himself. This phenomenon is strongly related to interdependencies between the var-
ious activities in a project: pooled interdependency, sequential interdependency and reciprocal
interdependency. You should manage these interdependencies. One way of doing that is to focus
part of your team meetings on this subject. Even professionals need encouragement at this level
because it is in their nature not to acknowledge that they are dependent on someone else.

4.5 ! Developing your team to a higher level: the performing phase

Joint learning is the key


Once your team has gone through the storming phase it is time to take it to a higher level. There
are many different views on what a high performing team is and how to stimulate the team to
reach a high performance level (Griffith and Dunham, 2015). Our view is that the most essential
characteristic of a high performing team is that it has developed a strong capability for joint
learning from experiences. Our research (Storm and Savelsbergh, 2012) shows that a strong capa-
bility for joint learning helps the team to:
• Endure stress and misfortune better.
• Open up to perspectives other than the dominant team perspective.
• Come up with a larger variety of solutions when they meet new problems.
• Act more quickly when incidents occur.

What do we mean by joint learning capability? In our research we focus on behaviour which is
indicative of a joint learning process. This is our way of looking at it.
Figure 4.6 represents eight different learning behaviours. The spider web in red indicates the

Exploring the environment


& the future

Experimenting
with improvements Identify errors timely

Brainstorming Analyze causus of errors

Reflect on processes Evaluate team performance

Gather external feedback

Figure 4.6: Joint Team Learning Behaviours (Storm and Savelsbergh, 2012)

83
M anag em ent of e n gi n e e r i n g p ro j e cts

scores of a particular team. This particular team scores high on behaviours like identifying errors
and analysing the causes of errors. This means that they engage rather often in these behav-
iours together. If only one or two persons engage in these behaviours then that is probably not
representative of the whole team. The team scores low on behaviours like experimenting with
improvements and gathering external feedback.
Each of these behaviours has rather little value by itself. Only when all behaviours have a high
score you will see the positive effects mentioned above. There is a small chance that a team will
purposely try to increase its joint learning capability. You, the team leader, are much needed.

4.6 ! Finishing the job: the adjourning phase


Adjourning may start rather early in the project if one or more team members leave the project
and take on a new challenge. Adjourning ends when the team is fully disbanded. The early leav-
ers present you with the opportunity to gain insight and practice in adjournment.
Adjournment can be a rewarding process to all concerned as long as you have clear objectives
for it. In determining your objectives you might ask yourself these questions:
• How will I like the project to be remembered by those who leave?
• What would I like team members to remember of what they learned from the project?
• Which interpersonal issues should be solved before anyone leaves the project?
• How would I and my team members like to celebrate the end of the project?
• How can I help my team members make a successful transition from my project to their next
assignment?
• How are we going to say ‘goodbye’ to all these fine people and teams we have worked with?

Many projects are in need of some kind of after delivery service. If you wait for that to happen
before your official disbandment you will miss out on the rewards of proper adjournment. So, it
is up to you to plan the moment of disbanding even when you are not sure when it will all end.

84
Setting Time People
Introduction Preparation Outlook
the scene and money at work

4.7 ! The Wind Farm


In order to apply the ideas about successful teamwork to a particular project it is wise to
diagnose the nature of the project in order to identify the specific challenges to the team.
Our diagnosis leads to the following project characteristics and related challenges:

1. The project will bring three quite distinctive organisational cultures together into one
venture: a routine-oriented culture (represented by Allwind), a process-oriented culture
(represented within the organisation by the operator of the transport network) and a
project culture (represented within the organisation by the construction company).
The challenge for the project team is to learn rapidly how the strengths of these
cultures can be synthesised and how potential clashes between these cultures can
be prevented. As an example, it is our experience that the way in which people plan
their efforts and how they deal with risks are quite different. A project start-up should
include a joint exploration of this challenge.

2. On the operational side, the project essentially requires the project organisation to
repeat the same thing – erecting a wind turbine in the sea – fifty times. In projects
where repetition is a core task it is essential that everything is planned and organised
to create a steep learning curve. This means proceeding more promptly and more
efficiently every single time. People who have not been trained to think and act in
terms of the learning curve have a tendency to think that improvement will come by
itself. This is a fundamental mistake. The challenge for the project team is to explore
extensively how a steep learning curve can be realised in all project aspects – technical,
logistical, organisational, and financial. The topic of joint team learning, described
above, prevails.

3. The project has a large number of very different stakeholders, some of whom have
mixed interests (these are the inhabitants who are also part owners). Dealing with the
contrasting interests of stakeholders is a major challenge in this project. We would
recommend engaging an experienced stakeholder manager.

85
M anag em ent of e n gi n e e r i n g p ro j e cts

86
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 6 ! overview
The goal of opportunity framing is to add value by (re)framing the project concept, using new
technologies or concepts, or adding scope. However, in many situations solutions are too quickly
chosen without investigating any other attractive options. We call this ‘premature convergence’.
Values can be calculated by (social) cost-benefit analysis (CBA). Value Engineering (VE) is an
interesting approach to optimise value throughout the lifespan. Crucial is the function analysis, in
which functions are determined without thinking of solutions, and the creative phase to generate
ideas. Ideally, opportunity framing starts at the very beginning of a project (front-end develop-
ment), but organisations should stay open for opportunities during the planning, realisation, and
operational phase (by far the longest period).
Opportunity framing is highly dependent on the goal, characteristics and context of the project.
Opportunity framing should lead to project success. The latter requires the iron triangle (sched-
ule, budget, quality), yet other criteria are also important. In general there is not one universal
perspective on project success. This differs from project manager to project manager and seems
to depend on the characteristics of their project.

Chapter 6 ! outline
6.1 Introduction
6.2 Premature convergence
6.3 Value management
6.4 Opportunity framing, a continuous process
6.5 People are key
6.6 Fit for purpose
6.7 Project success
6.8 The Wind Farm

102

925836-02_120_17-Feb-15_08:41:44_walter
the scene and money at work

Chapter 6
Opportunity framing
by Marcel Hertogh

6.1 ! Introduction

Opportunity framing is a structured approach to understanding and defining an opportunity. It is


the starting point for a robust, decision-driven process for the realisation of the opportunity. For
projects this is first of all setting the boundaries on what the project is and is not. The essence
of opportunity framing is to decide what the project will include and what not. This process is
performed together with stakeholders.
In addition, opportunity framing can be about adding scope and (re)framing the project concept.
It can also be the application of a new technology, or any new concept to be considered by the
client/sponsor, project team or stakeholder. Important at opportunity framing is the interaction
with stakeholders to secure project success.

Crucial at opportunity framing is:


• To define the project scope.
• To involve stakeholders.
• To define when the project will be successful (project success).
• To create value drivers.
• To identify risks: threats as well as opportunities.

To illustrate the concept of opportunity framing and these important elements, we will give the
following example. The busy highway A2 runs through the eastern part of the Dutch city of
Maastricht, dividing the city into two parts and creating unacceptable levels of air pollution. For
decades there have been plans to bring the highway underground at the current location, or
even outside the city, but sufficient support and funding were lacking. At the beginning of the 21st
century, the plan was reframed. The opportunity was to look at the project in a new way. From
an infrastructure project it became a city development project. By bringing the highway under-
ground in a tunnel, new space could be created for real estate, housing and an environmental
upgrade of the area (‘scope’). In this plan, which is now under construction, the city development
contributes financially to the infrastructure to make the project feasible (‘value driver’). A major
part of the new space that is created by bringing the highway underground will be designed as
a green zone that has been generating extra support for the project (‘value driver’). The project is
named after this green zone: the ‘green carpet’ (Figure 6.1).

103

925836-02_121_17-Feb-15_08:41: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

Figure 6.1:
A2 Maastricht ‘Green Carpet’

The ‘Green Carpet’ is an example of opportunity framing. The opportunities at the Green Carpet
were the adding of extra scope and the reframing of the project. The result was sufficient political
and societal support (‘stakeholders’), a financially feasible project, improvement of the living envi-
ronment, better traffic flow, new apartments (1,100) and extra commercial real estate (30,000 m2)
(‘project success’). Major threats to the project are the technical risks at the construction of a
double-deck tunnel, and the financial risks at the timely sale of the real estate (‘risks’).

An opportunity is a favourable or advantageous circumstance or combination of circumstances.


A threat is the opposite. If a threat is the downside or disadvantage, then an opportunity is the
upside or benefit. Threats and opportunities are two sides of a coin, a coin named uncertainty. An
uncertainty can have a positive result (opportunity) or a negative result (threat), see also Chapter
8. Interestingly, a threat can turn out to be an opportunity.

The threat of abandoning the A2 in Maastricht, led to looking for opportunities and finding new
solutions. Whereas a threat can overcome you, you yourself need to look actively for an opportu-
nity to improve the business and living environment, as illustrated by the quote of Kyle Chandler
‘Opportunity does not knock, it presents itself when you beat down the door.’

After giving the successful example of the A2 ‘Green Carpet’ in the city of Maastricht, we will show
a major pitfall of opportunity framing. It is called premature convergence (6.2). As we saw, an
important element in the approach is to define and ensure project success. What are the ‘success
criteria’, and by which ‘success factors’ can these criteria be reached (6.3)? Value drivers are an
important element (6.4). The process of opportunity framing starts in the early phase of a project,
and interestingly is this is also beneficial during the following phases, before and after delivery
(6.5). At opportunity framing, where the scope of the project originates, interaction between
people is a key factor in creating the scope and realising project success (6.6). Finally, opportunity
framing is highly dependent on the specific situation: starting points, ambitions and preferences
of stakeholders, characteristics of the environment, etc. This leads to a fit-for-purpose approach
(6.7), where we also present an overview of the examples we discussed in this chapter.

104

925836-02_122_17-Feb-15_08:41:47_walter
the scene and money at work

6.2 ! Premature convergence


Opportunity framing can result in project enrichment. However, in many situations a solution
is chosen early in the process, thereby ‘killing off’ many other options present at that point in
time. We call this ‘premature convergence’. In an international research of six large infrastructure
projects (rail and highway projects) 14 critical events were examined (Hertogh, Westerveld, 2010).
They were identified by asking respondents to identify important events in their projects that
changed the course of the project. Premature convergence was found at 10 of these 14 events,
without sufficient interaction with other stakeholders. This ‘keep it simple’ mindset in extreme
cases removes the possibility of exploring other, possibly promising, alternatives.

The upgrade of the West Coast Mainline in the United Kingdom was a major project that started
around 1990 and was delivered in 2008 (total costs € 10.2 billion). The project delivery organisa-
tion wanted to use ERTMS (European Rail Traffic Management System, a new signalling system)
and that was the main starting point in the cost calculations and the passenger train contracts.
However the development of this new technology turned out to be too costly and time-con-
suming. The project organisation had chosen for the ERTMS without sufficient research and
without having a Plan B. The problem with the development of ERTMS was one of the reasons
that the project came into a crisis, prompting reorganisation in 2001. By then, a more traditional
train safety and communication system was chosen.

The oil industry too observed premature convergence: ‘Reviews of previous opportunities show
that with the pressure to deliver results there is a tendency to jump in with both feet and execute
without having a full clarity of purpose. For instance is the team, group, or stakeholder fully
aligned on objectives, have the real value drivers and critical issues been identified?’ In other
words, in many cases the opportunities have not been sufficiently framed.

6.3 Project success


Opportunity framing is an important element to achieve project success. Two questions emerge:
What is project success? and how to facilitate project success?

In his article (2003), Westerveld linked success factors and success criteria into one coherent
model known as the ‘Project Excellence Model’ (Westerveld, 2003). This model has been adapted
from the EFQM Excellence Model. The European Foundation for Quality Management, EFQM, was
founded in October 1989. The Foundation set up a team of experts, from the industry and aca-
demic world, to develop the EFQM Excellence Model, a holistic framework than can be applied to
any organisation, regardless of size or sector (www.efqm.org).

The Project Excellence Model (Figure 6.2) is designed to link into one coherent model (Westerveld,
2003):
• six result areas covering project success criteria. These are ‘hard factors’: time, costs, quality
and safety, as well as ‘soft factors’: satisfaction of five groups of stakeholders. Satisfaction con-
cerns both the outcomes and the process.
• six organisational areas covering critical success factors. These enablers are crucial in realising
in the success criteria.

105

925836-02_123_17-Feb-15_08:41: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

Enablers Results

Policy & Strategy Civil principal


Project- Project-
management results
Project Personnel
• Scheduling • Time
Stakeholder mgt.
• Budgeting • Costs
Leadership • Quality • Quality
Users
& Team • Information • Safety
• Organisation
Resources • Risks
Contractors

Other
Contracting
Stakeholders

Feedback

Figure 6.2: Project Excellence Model (Westerveld, 2003)

Later on IPMA also developed a Project Excellence Model with similar contents and layout.
Halfway into the first decade of the 21th century, IPMA began to conduct assessments with this
model awarding annual prizes to the best performing projects.

Early work on success criteria assumed that the main criteria for success were the so-called ‘iron
triangle’ of being (1) on schedule, (2) within budget and (3) achieving the quality or functionality
required. However, project success turned out to be far more subtle than this. Van Aken (1996)
defines project success as ‘The satisfaction of all stakeholders’. Perceiving project success simply
as the compliance with time, cost and quality constraints can be qualified as a more ‘narrow’
view in this respect. Westerveld distinguishes six result areas, see Table 6.1. One of these is the
iron triangle, the five others concern satisfaction of involved parties.

Success criteria will differ from project to project depending on a number of issues such as size,
uniqueness and complexity (Wateridge, 1998). So a less ‘fixed’ and more flexible approach seems
appropriate in studying project success. Westerveld concluded from literature that a more flex-
ible approach to project success is to develop clusters of possible success criteria – assuming
that (while criteria defining project success can be different for each project) a universal cluster-
ing of criteria can be formulated to cover the whole issue of project success. This is exactly what
was done in a research to study the public project manager’s perspective on project success
(Koops et al., 2014, Van Loenhout, 2013). From an extensive literature survey and interviews with
Dutch public project managers, she developed a subset of 19 relevant public sector criteria, see
Table 6.2.

106

925836-02_124_17-Feb-15_08:41:47_walter
the scene and money at work

Table 6.1: Result areas of the Project Excellence Model (Westerveld, 2003)

No. Result area Explanation

Project results
Budget The original iron triangle of project goals. Most projects will have
1
Schedule specific scheduling, budget and quality constraints.
Quality

The client initiates the project to fulfil a specific need. What aspects
2 Appreciation by the client and factors does the client value in judging the success of the
project.

Project staff will be concerned with reaching their personal goals as


3 Appreciation by project personnel
well as having a good working atmosphere.

Users are concerned with their overall influence in the project and
4 Appreciation by users
the functionality of the end product.

Appreciation by contracting Contracting partners try to make a profit at the project. They are
5
partners also concerned with getting new orders and learning possibilities.

Parties that are not directly involved in the project but which do
6 Appreciation by stakeholders have a large influence (e.g. environmental groups, citizens and
government agencies). These parties manage their specific interest.

Table 6.2: 19 relevant public sector success criteria (Koops et al., 2014)

Success Criteria

Well-known criteria from literature: Sporadically mentioned in literature, but presumed


relevance for public sector:
1. Delivered on time
2. Efficient use of available resources 13. Effect on the professional image of client
3. Fit for purpose organisation
4. Learning opportunities for client organisation 14. Good working relationship with contracting
5. Personal growth and development partners
6. Profitability for contractor 15. Impact on the environment, sustainability
7. Quality 16. Right process is followed
8. Safety
9. Satisfies needs of project team Derived from interviews or perceived relevance:
10. Satisfies needs of stakeholders
11. Satisfies needs of users 17. Continuation of client organisation
12. Within budget 18. Project specific political or social factors
19. Satisfies needs of shareholders

107

925836-02_125_17-Feb-15_08:41: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

The Q-methodology has been used for showing the respondent’s view on prioritising in the sub-
set of criteria. Each respondent was asked to rank the 19 criteria from most to least important in
determining project success. The authors analysed the response of 26 public project managers of
infrastructure projects in the Netherlands (national and regional level) and extracted three collec-
tive perspectives on project success. A collective perspective is shared by a group of respondents
with similar views (highly correlated with each other), and shares only limited correlation with
respondents holding any of the other perspectives. We will briefly discuss the three perspectives.

Perspective 1: Holistic and cooperative leadership


This perspective is shared by a group of public managers who keep a holistic view, not focusing
on details, but rather on the project as a whole. They give immediate attention to those issues
threatening the project objectives and end result, instead of losing themselves in details. They
stress the importance of cooperation and stakeholder satisfaction. They value safety above all
other criteria, whereas no value is attached to the so-called ‘right’ process.

Perspective 2: Socially engaged, ambiguous manager


Public managers at the local and regional level share this perspective. They aim at improving
their city or region, not just executing a project. Finishing the project within budget is the most
important criterion in this perspective, however it is not clearly separated from the other criteria.
These public project managers have an ambiguous view in which there exists no clear prioriti-
sation and their project success is largely determined by criteria they cannot influence. They see
the right process as a way to end up with the right result.

Perspective 3: Executor of top-down imposed assignment


These public project managers are very much influenced by politicians and their decisions,
although they have no direct contact. The political promise is translated into a quantifiable goal
in project execution: the timely delivery of the project. Both shareholders and stakeholders are
unimportant in this perspective. The public project manager executes the project in a well-de-
fined environment and is able to keep priorities clear throughout the project and focus on these
to reach the end result.

Interesting is to look at the rankings of distinguishing success criteria (total 10). These illustrate
the three perspectives, see Table 6.3. The other 9 criteria are less distinctive.

When we take a close look at Table 6.3, we see that the three criteria of the iron triangle:
• are distinguishing criteria;
this means that the perspectives differentiate particularly in terms of time and budget.
• are important;
but others can be of more importance to the public project managers.

The conclusion is that the iron triangle matters, but that other criteria are also significant. In
general there is not one, universal perspective on project success. It differs from project manager
to project manager and seems to be dependent on the characteristics of the project involved.

108

925836-02_126_17-Feb-15_08:41:54_walter
the scene and money at work

Table 6.3: Factor scores of distinguishing criteria with corresponding ranks

Perspective 1 Perspective 2 Perspective 3


Success criterion
Rank Rank Rank

Within budget 2 1 10

Delivered on time 11 6 2

Quality 7 7 8

Right process is followed 19 10 6

Safety 1 9 3

Profitability of contractor 12 19 17

Satisfies need of shareholders 5 12 19

Satisfies need of stakeholders 3 3 18

Fit for purpose 8 4 15

Project specific political or social factors 10 2 1

6.4 ! Value management


Values can be calculated by means of the cost-benefit analysis (CBA). For the process industry,
the expected profit is usually calculated using scenarios. With infrastructure projects such a profit
is usually not the case but social cost-benefit analysis (SCBA) is used instead. The goal of the
SCBA is to compare project alternatives according to the impact these projects have on welfare
of society, so the social costs and benefits (Kwast, 2013). The SCBA gives answers to the following
questions:
• What are the costs and social benefits of the project alternatives?
• Who bears the costs and who enjoys the benefits?

The SCBA is an analysis for projects whereby all the social relevant effects of a project are sche-
matically described. Three types of effects are generally distinguished (Kwast, 2013):
• Direct effects: the project directly engages on, for instance travel time savings;
• Indirect effects: are effects for actors other than where the project is primarily aimed at, for
instance rising real estate prices when accessibility improves;
• External effects: negatively affecting stakeholders, for instance extra air pollution from addi-
tional traffic.

Value Engineering is a systematic, multidisciplinary approach to optimise (or improve) the value
of a system throughout the lifespan. Value Engineering seeks to maximise the value for the client.

109

925836-02_127_17-Feb-15_08:41:57_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

ProRail uses eight stages when it comes to value engineering (Van Geffen, 2005). ProRail is a
Dutch government task organisation dedicated to maintaining and extending the national rail-
way network infrastructure (not the metro or tram), to allocating rail capacity, and traffic control.

These stages are:


1. Preparatory phase. Setting the goals and scope.
2. Informative phase: Gathering and analysing information.
3. Function analysis phase Analysing the design or problem and allocating cost to functions.
4. Creative phase: Generating ideas from a functional perspective while focusing on the
functions with the highest potential value.
5. Evaluation phase: Prioritising ideas with predefined criteria. Selection process of best ideas
with potential value increase.
6. Developmental phase: Further development of the selected ideas and elaboration of
consequences for implementation of solution.
7. Presentation phase: Presenting the results to all relevant stakeholders.
8. Report and Implementation: Report, handover and start of the implementation process.

All of these phases are necessary, but two steps are the core of the method: function analysis and
creative phase. The essence of function analysis is to determine the functions, without thinking
of solutions, because these may hamper the thinking process. An opportunity framing work-
shop can be used in the creative phase. Every organisation involved in the project can organise
this workshop: the client/sponsor, the project delivery organisation, the contractor and suppliers.
An opportunity framing workshop facilitates the process of finding opportunities and finding a
way to realise them. The workshop should facilitate creativity, and ideas are welcome. For this
a safe atmosphere is needed. An option to speed up the generation of ideas while the input of
the participants is anonymous is an electronic boardroom. The participants communicate via
computers, without mentioning who the input generates. Key players need to be involved. It can
be beneficial to interview the key players beforehand by the facilitator and to get a feeling what
project success means to these parties.

Van Geffen presents the example of a tunnel at a train station to increase transfer capacity, con-
nect both sides in the future, upgrade bicycle parking and preserve the original station roof. The
Value Engineering study goals were to reflect on the functionality and assumptions, as well as
to improve value compared to the proposed design. The teams used among others brainstorm-
ing techniques and they worked in three separate groups to create alternatives. The three best
alternatives have been evaluated. The chosen alternative was cheaper (23 %) than the proposed
design, and had some functional benefits, such as fewer temporary measures for commercial
activities and maximising the width of the tunnel, as well as acceleration of the design process.

6.5 ! Opportunity framing, a continuous process


Opportunity framing should start at the very beginning of a project. The ‘Green Carpet’ that
was discussed in Paragraph 6.1 is an example of ‘front-end development’ (see Chapter 7). In this
front-end phase, the scope of the project is created. The idea is that in the early stages it is eas-
ier to influence the scope than during later stages, see Figure 1.3. In the design and preparation
phase (with land acquisition, and important legal procedures) this ability diminishes, while the

110

925836-02_128_17-Feb-15_08:41:58_walter
the scene and money at work

investment costs rise. During construction it is even more difficult to change the scope unless
the client/sponsor accepts a major financial impact, as well as substantial delay.

Isn’t this classic Figure 1.3 too simple? First it is not always that costly to change the scope in the
later stages, and also it does not concern the operational phase, for instance when choosing for
more adaptive solutions. This scheme (Figure 1.3) focuses on the scope of the project. However
opportunities can also be intangible. These are easier to implement during later stages.

An example of opportunity framing during the construction phase is NEAT (German: Neue Eisenbahn-
Alpentransversale), the New Railway Link through the Alps. At the heart of NEAT are two ‘base’
tunnels, the Lötschberg (34.6 km), and the St. Gotthard (57 km). Because the tunnels go through the
base of the mountain and do not need to climb, the line can be much straighter than in the current
tunnels where they are forced into curves and switchbacks in order to gain the height and reach the
entrance. Because the line is almost flat, freight trains can be twice as heavy and go faster than those
which have to climb to today’s tunnels (www.swissworld.org). During the feasibility phase (front-end
development) the Swiss decided to go for these base tunnels. The NEAT is expected to take 90 % of
the goods in transit through Switzerland. Amid much fanfare, the Lötschberg base tunnel was finally
opened on December 9, 2007. The longer Gotthard base tunnel is set to open in 2016. After comple-
tion, the Gotthard Base Tunnel will be the longest tunnel in the world. At the preparation, the focus of
the client/sponsor and the project organisation was increasingly more on the technological marvel
of NEAT (on the base level of realising infrastructure in Figure 6.3 that will be discussed later on). But
after some debate about the necessity of the project in the mid-1990s, the responsible politicians
and civil servants became increasingly aware of the environmental importance and they reshaped its
purpose. To express this thinking, the slogan ‘the biggest environmental project in Switzerland’ had
been developed and used ever since (Schalcher et al., 2008).

At the Gotthard Base Tunnel the ‘system’ was able to ‘adapt’ its mission during realisation after
‘the front-end’ phase. The NEAT system was the network of parties, as previously mentioned
politicians and civil servants, but also NGOs, like the Alpine Initiative that initiated a referendum
in 1994 about the protection of the mountains. At that time there were fierce discussions about
the necessity of two tunnels and also about the cost NEAT would involve. The new approach

Figure 6.3: NEAT, New Railway Link through the Alps

111

925836-02_129_17-Feb-15_08:41: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

referring to the benefits for the environment helped the politicians and client/sponsor in favour
of NEAT to retain the original scope.

Another interesting example is the Betuweroute, a rail freight line in the Netherlands. Debate
emerged in the mid-90s whether in the future trains would operate with a stack of two contain-
ers instead of the usual single container. This could be the case if the Betuweroute turned out to
be very successful and ‘double stack’ will be needed. Because the Betuweroute has five tunnels,
it would be very costly if the diameter of tunnels that are only fit for a single container had to be
increased to facilitate double stack after delivery. Finally, the decision has been made to prepare
the tunnels for double stack. To this end the tunnels have been constructed with a larger diam-
eter to make double stack possible. And what about the viaducts? The viaducts are only built for
a train with a single container, but a physical provision has been made to make it easy to jack
the viaduct at a later stage. Interestingly, the decision for double stack was taken in a relatively
late stage of the design process. This case is also special, because these costly precautions to
anticipate on uncertain future developments are not frequently taken in infrastructure projects.

‘The secret of success is to be ready when your opportunity comes’ said Benjamin Disraeli. And
these opportunities can come during the whole lifespan of the project.

While creating the scope at the front-end stage and during design and realisation, it is important
that the organisations embrace opportunities during the planning and realisation of the project.
But can opportunity framing also be used during operation? This should be welcomed, because
the operation phase is the longest period by far, see Figure 6.4.
The operational phase can take decades or even longer. A new chemical plant can have a planned

Opportunity framing

Front
end

Operation Redesign, Reuse


Realisation
Recycle Operate

Figure 6.4: Continuous opportunity framing during the project lifecycle

operation phase of 30 years, the storm surge barrier at the Eastern Scheldt was constructed for
200 years and the Egyptian pyramids were built 4500 years ago. At the pyramids the functionality
shifted from a tomb for an Egyptian pharaoh to what we might call an archaeological treasure
and a tourist attraction that generates income to the Egyptians nowadays.

An interesting case for adaptive management is the Dutch ‘Room for the River’ project. Because
of climate change, extremely high river discharges will occur more frequently in the future and

112

925836-02_130_17-Feb-15_08:41:59_walter
the scene and money at work

for this reason it was decided to ensure that the rivers could discharge the forecasted greater vol-
umes of water without flooding. The Government approved the ‘Room for the River’ plan in 2007.

This plan has three objectives:


1. By 2015 the branches of the Rhine will cope with a discharge capacity of 16,000 cubic metres
of water per second without flooding.
2. The measures implemented to increase safety will also improve the overall environmental
quality of the river region.
3. The extra room the rivers will need in the coming decades to cope with higher discharges
due to the forecast climate changes will remain permanently available.

These objectives combine (1.) the need for water safety with (2.) environmental quality in a dual
objective in a way (3.) to cope with future developments.

The Room for the River embraces a more flexible approach than the traditional flood defences,
by giving the river more room at 30 locations to accommodate higher water levels, essentially
allowing the river to flood safely. One example is the ‘Overdiepse Polder’ where 16 farms have
been designated as flood zones to protect 140,000 residents of Den Bosch. As the New York
Times put it ‘By displacing farmers, residents in that city can breathe a little easier’. Other examples
to increase adaptation are floating buildings (Dixon, 2014).

Room for the River confirms that it is possible to anticipate on current and future opportunities
that are currently unknown. Systems are adaptive when they are able to respond to changes in
requirements or conditions. It means that these systems have the ability to learn and evolve.
The system will be adaptive when the complexity of a system exceeds a critical limit, and will
produce unexpected variety and novelty through spontaneous, unpredictable self-organisation
(Brukx and Wackers, 2001, Flood, 2009). This was also the case with NEAT. The ‘Alpine Initiative’
was not expected beforehand, but had an important influence on the approval of NEAT.

Finally, an example of redesign and reuse are old buildings that are given a new function.
Interesting are old harbour buildings near waterfronts that are now used as trendy apartments
(after some modifications), and by giving the area a major revalorisation as was the case in the
cities of Hamburg, London and currently Rio Janeiro. It is not necessarily big projects, as the ren-
ovated old station building of Elva in Estonia shows that serves as a leisure and travel centre now.

6.6 ! People are key


As was seen in the case of premature convergence, sufficient interaction is necessary. Constructive
interaction can help projects to accept new, and often external, changes. These changes might
potentially improve the project outputs, reduce costs or speed up the project delivery, and are
a crucial help to obtain project approval (Hertogh et al., 2008). Interaction starts with the notion
that projects need to be realised in a context with all kinds of stakeholders and that this context
will change. One needs to be realise that problems are ambiguous and goals are related to par-
ties. It means that goals are not fixed, in fact they change as the context changes in contrary to
the fixed goal assumption of traditional project management. Management focuses on satisfying
needs through interaction in stakeholders’ network, and also on the flexibility to have the ability

113

925836-02_131_17-Feb-15_08:42:00_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

to act (preferably by anticipation) in the face of changing circumstances or specific outcomes of


management strategies: adaptive management. Agility is one way in the process industry.

Two main strategies of interaction are suited for opportunity framing:


1. Alignment of stakeholders (interests, vision, objectives).
2. (Re)definition of the problem and change of scope.

The alignment strategy takes the specific needs and perceptions of parties as its starting point.
These needs and perceptions cannot (fully) be known in advance; only through interaction insight
in the needs and perceptions of others and, that is interesting often, of ourselves can be gathered.
In the process of continuous interaction and collaboration, issues will become interconnected
and things will often be seen in a new perspective and therefore views need to be reformulat-
ed. Through this interaction, needs and perceptions evolve. Research (Hertogh, Westerveld, 2010)
demonstrated that using a strategy of cooperation has a greater chance of success than an ‘inter-
nal’ approach that may lead to ‘premature convergence’ (see Paragraph 6.2). The intention is that
through the process of alignment, solutions with a wider range of support can emerge. In this
sense the process reduces ambiguity – and, by the same means, complexity – by aligning the
interpretations and perceptions of stakeholders. On the other hand, it can increase complexity if
scope is added through this interaction.

Parties should also bear in mind the potential pitfalls of strategies of interaction. The most impor-
tant pitfall is that pure and unique focus on alignment may seriously limit project progress and
may lead to over-expensive solutions emerging, because difficult decisions are avoided and
because they are not confronted.

To enable effective adaption during the operational stage at ‘Room for the River’, intensive stake-
holder collaboration (interaction) during the early stages of the programme was initiated. This
provided a robust basis and flexibility to adapt (Rijke et al., 2014). The client/sponsor chose to
allocate the responsibility for the delivery of the designs to local and regional government lev-
els, so that these government levels became responsible for customising solutions to their own
context and dealing with local stakeholders. Because these organisations are typically more con-
nected with the regional context than the programme management office, which was operating
on a national level, this enhanced the ability of the programme to adapt to the context of indi-
vidual projects. On the other hand at the programme level there was a clear vision and planning
framework of the programme design, which ensured a stable basis (i.e. robustness) for the pro-
gramme management processes. This combination of clear programme vision and customising
solutions gave the programme the flexibility to adapt to changes. It can be concluded that the
combination of programme governance and coordination allowed for programme adaptation,
which has resulted in continuous alignment of the management of programme to the context
of the programme as a whole and the contexts of the individual projects. On a national level the
effectiveness of measures like ‘Room for the River’ is monitored continuously (Van Rhee, 2012) in
respect to predictions of the future.

The second strategy was presented in the example of the A2 ‘Green Carpet’ in Maastricht in
Paragraph 6.1. As mentioned earlier, from an infrastructure project it became a city development
project.

114

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

6.7 ! Fit for purpose


Projects must be conceived, managed and operated as an integrated whole, with the prime
purpose being the user, social and economic benefits derived from a new or improved factory,
building or transport link, rather than the completion of a physical project as a final stage in itself.
Where the success of the outputs depends on operational interfaces as well as physical construc-
tion, these must be managed from the outset and integrated into the programme management
of the whole project (Hertogh et al., 2008). This is presented in Figure 6.5.

Value creation
society

Connect functions

Connect projects

Integration

Infrastructure

Figure 6.5: Value creation by the area specific approach of the province of Friesland

It depends on the ambition and the characteristics of the project, how far the project organi-
sation can go in broadening the scope – see the orange arrows. By broadening the scope, the
project is more likely to succeed, but on the other hand the management will be more challeng-
ing, which might jeopardise the project success. Somewhere there is an optimum.

An interesting example is the development of a fit-for-purpose, area-specific approach taken by


the Dutch province of Friesland to link infrastructure and area development. Up to 2020 the prov-
ince of Friesland will be realising infrastructure projects worth € 1.5 billion based on a so-called
‘area-specific approach’. The aim of this approach is not only to improve the network of infra-
structure projects, but also to give the area a ‘plus’. This ‘plus’ can take many forms. It could mean
extra nature, a higher bridge for pleasure boating or improving liveability in a declining area.

More conceptually, in realising an infrastructure project, the following levels are distinguished by
the province to create value (see Figure 6.5):
1. The physical construction of the infrastructure that needs to be executed according to
requirements of finance, time and scope.
2. Integration in the environment, such as a diversion of the route, noise screens.
3. Connection with other projects, such as the use of sand from a dredging project for a new
highway project.
4. Connection with other functions, such as power supply (solar cells), recreation, land
development.
5. Value creation for society, such as creating an attractive business environment (employment)
and keeping areas in the countryside vital; in general focus on economic and social
sustainable growth of the whole province.

115

925836-02_133_17-Feb-15_08:42:03_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

To realise added value, cooperation between the provincial authority and partners in the region
begins at an early stage in the process. These are the parties that can exert real influence on the
scope of the projects and the process. Interesting is that the area-specific approach is a custom-
ised approach. On the one hand the province has learnt from previous projects in realising the
‘plus’, on the other hand the province experienced that every project is unique and requires a
specific approach and solutions at specific levels. Some projects incorporate all of the five levels
presented in Figure 6.5. All the examples we discussed in this chapter come with specific chal-
lenges, solutions and results. These are summarised in Table 6.4 to illustrate the ‘fit-for-purpose’
character.

Table 6.4: Examples of opportunity framing

Programme/ Project (discussed in


Challenge Result
paragraph)

From infrastructure and liveability


1. ‘Green Carpet’ A2 Maastricht to broader perspective on city Add scope: green zone, houses,
(6.1) development: living and working real estate.
space, environment.

The belief in an unproven Severe problems that were solved


2. West Coast Mainline (6.2) technology turned out to be over- after the choice for an alternative
optimistic, because not feasible. solution for signalling.

To reflect on the functionality and Low costs (23 %), some functional
assumptions, as well as to improve benefits, maximising the width of
3. Train station (Netherlands) (6.4)
value compared to the proposed the tunnel, and speeding up the
design. design process.

4. NEAT (including Gotthard and Biggest environmental project of


The NEAT project was approved.
Lötschberg Base Tunnels) (6.5) Switzerland.

Combination of water safety A variety of adaptive solutions,


5. Room for the River (Dutch
and environmental quality in an such as retention areas and
Water Authority) (6.5, 6.6)
adaptive manner. floating homes.

Larger diameter of tunnels and a


6. Betuweroute (Dutch cargo From single to double stack to
provision in the viaducts to jack
railway) (6.5) increase future proofing.
up.

Add scope dependent on project:


From infrastructure to added value
7. Programme Friesland (6.7) recreation, environment, nature,
for the area.
liveability, economic growth, etc.

116

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

6.8 ! The Wind Farm


Crucial at the opportunity framing stage is the alignment of stakeholders. Interesting is
that over 100 agricultural entrepreneurs together with the energy company Esenca will be
the owner-operators of the park. With the main stakeholders the scope of the project will
be decided, as well as what success will look like and what the various value drivers are.
At the wind farm 80 wind turbines will be erected. Because modern wind turbines
produce far more electricity, all 50 existing wind turbines can be dismantled.

Success criteria at the wind farm can be distinguished as hard factors and soft factors.
Hard factors are the electricity produced (11 MW in total), safety, delivery on time
and within budget. Soft factors are the appreciation of stakeholders, team members,
contractors, etc. One interesting detail is the possibility given to local residents to
participate at a financial level. A reason for dissatisfaction could be noise pollution and
visual hindrance. After defining the success criteria, the following step is to determine
a method of measurement for the identified success criteria, during and also at the end
of the project. The most important criterion of the wind farm project is related to safety,
where no accidents should happen during any of the project phases.

A value driver acts as a lever to reach the pre-mentioned project success. Examples of
value drivers are the involvement of main stakeholders during the lifecycle, reduction
of capital expenditure (CAPEX) and revenue growth. Main threats are the opposition of
stakeholders, delay in obtaining permits, very optimistic calculations for the generation
of electricity and an underestimation of maintenance costs

117

925836-02_135_17-Feb-15_08:42:08_walter
Chapter 6
HOW DO CONTRACT TYPES AND INCENTIVES
MATTER TO PROJECT PERFORMANCE?

Collaborative contracting in projects 145


Chapter 6 | Abstract

How collaborative contracts and contractual incentives might influence project performance
remains equivocal. We hypothesized that their effects on project performance are mediated
by owner–contractor collaboration, measured in terms of relational attitudes (relational
norms and senior management commitment) and teamworking quality (inter-team
collaborative processes). Using PLS-SEM, we analyzed a sample of 113 capital projects. The
results suggest that through better relational attitudes and teamworking quality, projects
with a partnering/alliance contract are likely to perform better than those with lump-sum
and reimbursable contracts. Likewise, the projects with incentive contracts are likely to
perform better than those without incentives through better relational attitudes and
teamworking quality. There were no differences in project performance directly associated
with different contract types and contractual incentives. Taken together, a
partnering/alliance contract and incentive contracts do not necessarily result directly into
better project performance but through relational attitudes and how they play out into
actual teamworking behavior.

Keywords: Capital project; Collaboration; Contract; Incentive; Relational; Teamwork; Trust.

Note:
• This chapter is reprinted from Suprapto, M., Bakker, H.L.M., Mooi, H.G., Hertogh,
M.J.C.M., 2015. How do contract types and incentives matter to project performance?
International Journal of Project Management, doi: 10.1016/j.ijproman.2015.08.003.
• The author of this dissertation contributed in study conceptual model, survey design, data
collection, statistical analysis, interpretation of results, writing and finalizing the
manuscript. The co-authors contributed in interpretation of results and review of the
manuscript.

146 Collaborative contracting in projects


Chapter 6 How do contract types and incentives matter to
project performance?
6.1. Introduction
There is a wide agreement that the choice of contract types should be contingent upon
various circumstances such as product and/or process uncertainty, desired allocation of risk,
owner in-house capability, and market conditions (Merrow, 2011; Turner and Simister, 2001;
Walker and Rowlinson, 2008). A proper contract type is chosen to encourage the owner and
contractor to work rationally together to achieve the best outcomes in accordance to their
common objectives and within the expected risk (Morris and Pinto, 2007; PMI, 2008; Smith,
2002; Turner, 2009; Walker and Rowlinson, 2008). However, two separate empirical studies
at different times by CII (1986) and IPA (2010) suggest that there is no clear or direct
relationship between the contract type and project performance. CII suggests that
regardless the choice of contract type, the real issues that affect the project cost
performance are associated with the alignment between owner and contractor and their
agreement in allocating and managing risk. In a similar vein, IPA suggests that any contract
type can deliver success or failure because contract is a second-order concern. One contract
type may work well for some owners but fail for others because different contract types
bring different difficulties and situations.

In this study we focused on three basic types of contracts underlying the relationship
between owner and contractor in the execution of capital projects: lump-sum or fixed price,
reimbursable, and partnering/alliancing (Smith, 2002; Turner and Simister, 2001; Turner,
2003). A lump-sum contract is a contract where the contractor is paid a fixed amount for the
whole scope of works defined in the contract. A reimbursable contract, commonly called
cost reimbursable contract is a contract where the owner reimburses the contractor for all
costs, reasonably incurred and directly associated with the amount of work done for the
project; plus a certain fee (fixed fee or percentage fee) and/or an incentive fee (Berends,
2006; Merrow, 2011). A partnering/alliance contract is an extension to reimbursable
contract where the owner and the contractors (often including specialist contractors and
key suppliers) jointly establish the target out-turn cost and share the gain and/or pain
resulting from the actual cost (Meng and Gallagher, 2012; Ross, 2003; Turner, 2003).

What is the potential influence of different contract types (partnering/alliance versus lump-
sum versus reimbursable) on the nature of the relationship between owner and contractor?
On one extreme, the lump-sum contract demands less owner intervention (or less
involvement) and therefore offers more flexibility and less administrative burden to the
contractor in executing a project (Berends, 2006; Lowe, 2007). But it also has some

Collaborative contracting in projects 147


Chapter 6

perceived drawbacks. A lump-sum contract is often considered to create an adversarial


relationship between the parties in dealing with changes of circumstances during the project
execution (Smith, 2002; Turner and Simister, 2001). The reimbursable contract, in contrast,
implies that more owner involvement and support can be expected and thus less barriers to
building a collaborative relationship and an integrated team (Berends, 2006; Smith, 2002).
But a reimbursable contract also has some drawbacks from the one party’s perspective
toward the other party (Berends, 2006; Smith, 2002). The contractor often perceives that
the owner will be more demanding for achieving target cost and schedule. On the other side,
the owner perceives that the contractor will come up with additional work and thereby
increase costs over what was initially estimated. In the end, lump sum and reimbursable
contracts have a quite similar implication on owner–contractor collaboration (Müller and
Turner, 2005).

On the other extreme, a partnering/alliance contract focuses on the ‘principles’ of relational


contract to change project participants’ attitudes from being short-term and adversarial
toward a more collaborative mind-set and behavior (Cowan and Davis, 2003; Larson, 1995;
Macbeth, 1994; Naoum, 2003; Ross, 2003; Thompson and Sanders, 1998). A
partnering/alliance contract is often advocated to be more collaborative than lump-sum or
reimbursable contract (Davis and Walker, 2008; Thompson and Sanders, 1998; Turner and
Simister, 2001; Turner, 2003).

Several in-depth case studies of partnering/alliance practices, however, reveal that this
contract type does not always eliminate the underlying adversarial attitudes. Lack of top
management commitment, lack of collaborative mind-set, and insufficient initial effort to
establish shared culture remain in practice (Aarseth, Andersen, Ahola and Jergeas, 2012;
Alderman and Ivory, 2007; Bresnen and Marshall, 2002; Chan, Johansen and Moor, 2012;
Smyth and Edkins, 2007). Contemplating the practical difficulties of partnering/alliance
projects, it is questionable whether a partnering/alliance contract is better than other
contract types. Merrow (2011) coins a controversial view on the role of alliance contracts,
“…, even if everything possible has been done to prepare the project (industrial
megaprojects)… Alliance contracts … do nothing to help us understand who is responsible
for what” (p.293). This contradiction provokes an important research question, to what
extent do different contract types actually enact different quality of collaborative
relationship between owner and contractor and in turn affect project performance?

This paper adopts Suprapto, Bakker and Mooi’s (2015a) conceptualization of owner-
contractor collaborative relationship as a set of norms and the manifested interactional
processes by which the project parties (owner and contractor) jointly act and decide on the
issues emerging during the course of a project in order to bring mutually satisfactory project
outcomes. Owner-contractor collaborative relationship includes two dimensions: (1)
relational attitudes; and (2) teamworking quality. Relational attitudes refer to norms and
commitment developed and shared by the senior management from both owner and

148 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

contractor to govern their project-specific relationship. The essential elements of relational


attitudes include fairness, inter-organizational trust, transparency, and no blame culture
alongside the commitment of senior management to support the project teams (Cheung, Yiu
and Chim, 2006; Rahman and Kumaraswamy, 2008; Suprapto, Bakker, Mooi and Moree,
2015b). Building on the works of Hoegl and colleagues (Hoegl and Gemuenden, 2001; Hoegl,
Weinkauf and Gemuenden, 2004; Hoegl and Parboteeah, 2007), Salas, Sims and Burke
(2005), and Pinto, Slevin and English (2009), Suprapto et al. (2015a) define teamworking as a
set of underlying mechanisms reflecting the task-related and social interactions between
owner team and contractor team in executing a project. They operationalize teamworking
quality as a higher-order construct capturing the quality of inter-team interactions and
including 5 facets of task-related interactions: communication, coordination, balanced
contribution, aligned effort, and mutual support; and 2 facets of social interactions: cohesion
and affective trust.

The positive effects of relational attitudes and teamworking quality on project performance
(in terms of efficiency, effectiveness, perceived satisfaction, and perceived success) has been
empirically substantiated whereas relational attitudes indirectly influence project
performance through teamworking quality (Suprapto et al., 2015a). Extending Suprapto et
al.’s research model, we addressed the research question by examining the effects of
contract types (partnering/alliance, reimbursable, and lump-sum) and contractual incentives
on project performance through two mechanisms: (i) directly and (ii) indirectly through the
mediation of relational attitudes and teamworking quality.

By quantifying such direct and indirect effects, this paper attempts to make three
contributions. First, we extend the scope of analysis by considering the ex-post effects of
contract types and incentives on the quality of owner-contractor relationships and project
performance that have been assumed ex-ante and lacking empirical support. Second, by
moving beyond the direct effects, this study is the first to assess potential indirect effects of
contract types and incentives on project performance through the parties’ relational
attitudes and their inter-teamworking quality. Third, the findings provide explanation to
which contract type is better than the others toward project performance and what
mechanisms are underlying it.

The paper is structured as follows. Section 2 presents the theoretical background on the
relationships between contract types, contractual incentives, relationship quality, and
project performance. Section 3 describes the research methodology used to test the
hypotheses. Section 4 presents the results and finally Section 5 discusses the implications
and future research directions.

Collaborative contracting in projects 149


Chapter 6

6.2. Conceptual framework


6.2.1. Collaborative contracting in engineering and construction projects
Literature on inter-organizational relationships and alliances often distinguish governance
modes in terms of equity and non-equity (or contractual based) alliances (Gulati, 1995) in
the context of R&D alliances (Feller, Parhankangas, Smeds and Jaatinen, 2013), buyer-
supplier (Zaheer, McEvily and Perrone, 1998), and new business ventures (Faems, Looy,
Janssens and Vlaar, 2012). In capital projects, one-off creations of complex physical assets,
the relationships between the owners and the contractors are generally, if not always, on
contractual basis. Contract types known and used within engineering and construction
industry like lump-sum, reimbursable, and partnering/alliance are the more specific forms of
non-equity alliances.

Conceptually, the choice of contract type depends upon a number of factors known ex-ante:
initial trust and commitment that emerged from a prior relationship (Gulati, 1995; Poppo,
Zhou and Ryu, 2008), perceived risks and uncertainty as a function of scope definition
(Gopal, Sivaramakrishnan, Krishnan and Mukhopadhyay, 2003; Smith, 2002; Turner and
Simister, 2001; Turner, 2003), and external factors like regulatory challenges, market
volatility, and difficulties due to location (Berends, 2007; Merrow, 2011). A contract in
project context is ex-ante designed to align the owner’s and contractor’s goal (Turner, 2003).
However, the inherent complexity, scope and scale, and the long time duration make capital
projects susceptible to future uncertainties and turbulence (Drexler and Larson, 2000;
Hartmann and Bresnen, 2011; Miller and Lessard, 2000; Sanderson, 2012). As a
consequence, any new risks and unforeseen events may arise as the project progresses
which in turn cause potential disputes and breakdown of the relationship. To cope with such
threats, the parties need to build stronger, more collaborative and more flexible
relationships on the basis of consciously designed ex-post governance mechanisms (Miller
and Lessard, 2000; Sanderson, 2012; Turner, 2003; Winch and Maytorena, 2011).

Prior studies in project-based collaboration, however, also reveal that the presumed
governability is often not realized to the extent expected (Bresnen and Marshall, 2002;
Alderman and Ivory, 2007; Gill, 2009). Relationships in projects also involve problems
associated with competing cultures and rationalities in day-to-day practice among project
team members. This in turn necessitates “relational contracting” emphasizing on ongoing
adaptations, reciprocity and interdependence, avoidance of detrimental behavior, mutual
trust, and communication openness between the parties and the teams (Gil, 2009;
McLennan and Scott, 2002; Müller and Turner, 2005; Smyth and Pryke, 2008).

Building on the aforementioned literature, we assume that the function of a contract in


capital projects is to serve as legally binding, enforceable, and reciprocal commitment
governing the collaboration between owner and contractor (Turner, 2003; Berends, 2014).

150 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

We focus on the ex-post governing effect (after contract award) of the choice of contract
type on the owner-contractor collaboration and the project performance.

We consider two related concepts: relational attitudes and teamworking quality specified by
Suprapto et al. (2015a) as the basis for defining owner-contractor collaboration. Suprapto et
al. conceptualize and empirically validate relational attitudes and teamworking quality as
two higher order constructs that capture the complex nature of owner and contractor
collaborative relationship at inter-firm and inter-team levels respectively. The underlying
concept of the relational attitudes is that when an owner and a contractor work
collaboratively in a project, the relationship between the two firms is characterized by a high
degree of reciprocal attitudes such as mutual trust and respect, commitment and leadership,
no blame culture, and communication openness between senior management from both
sides (Meng, 2011; Pinto et al., 2009; Rahman and Kumaraswamy, 2008; Smyth, Gustafsson
and Ganskau, 2010; Suprapto et al., 2015b; Young and Poon, 2013). At the project team
level, highly collaborative teams display behaviors related to seven facets of teamworking
quality. Team members in teams with high teamworking quality openly communicate
relevant information, continuously coordinate their activities, contribute their knowledge
and expertise to their full potential, mutually support each other in anticipating unforeseen
events, and align their efforts to expected priority (Hoegl and Gemuenden, 2001; Suprapto
et al., 2015a). Teams with high teamworking quality also possess cohesiveness (‘we-ness’)
(Hoegl and Gemuenden, 2001; Suprapto et al., 2015a) and affective trust among team-
members (Pinto et al., 2009; Suprapto et al., 2015a).

6.2.2. Contract types, incentives, and collaborative relationship


Project management scholars distinguish contract types into traditional contracts (like lump-
sum and reimbursable contracts), and relational contracts (like partnering or alliance). Under
a lump-sum contract, the owner assumes certainty of the project scope in terms of the
functionality and performance specifications. The contractor is expected to implement the
best solution and method of delivery to meet the specified functionality and performance
specifications (Smith, 2002; Turner, 2003). Because all project activities and the associated
risks are expected to be managed by the contractor, the owner has less direct need to follow
up on project progress assuming the project proceeds according to the defined scope
(Berends, 2007; Müller and Turner, 2005). This leads to the decrease in the owner's
involvement in the project leading to limited information exchange and coordination
(Merrow, 2011; Müller and Turner, 2005).

A reimbursable contract including the variants like cost plus a fixed or percentage fee,
assumes the project definition is more uncertain (Berends, 2006; IPA, 2010; Merrow, 2011;
Turner, 20). Under a reimbursable contract, the contractor is paid for his efforts with all risks
taken by the owner (Smith, 2002; Turner, 2003; Müller and Turner, 2005). It is often
perceived by the owner that the contractor is attracted to over-supply to gain more profit
(Müller and Turner, 2005). This encourages the owner to assign a much larger team to

Collaborative contracting in projects 151


Chapter 6

perform extensive control and monitoring over the progress and quality of the contractor’s
work (Berends, 2007; Merrow, 2011). The close interaction between owner team and
contractor team during the course of the project, however, does not necessarily mean a
better collaboration (Müller and Turner, 2005).

A partnering/alliance contract is a particular form of reimbursable contract where the goals


of the contractor are aligned to those of the owner through target cost and a gain-sharing (in
alliance contract this includes pain-sharing; Ross, 2003) mechanism (Bennet and Peace,
2006; Scott, 2001; Thomas and Thomas, 2005). Partnering/alliance contract is built on
relational contracting aiming to facilitate owner-contractor collaboration with a common set
of goals, norms of trust and respect, and clear procedures for joint risk management and
dispute resolution (Beach, Webster and Campbell, 2005; Larson, 1995; Naoum, 2003; Scott,
2001). With a partnering/alliance contract, the collaboration between owner and contractor
can be further enhanced through a joint project governance board and integrated project
team to ensure effective teamwork to achieve better project results (Beach et al., 2005;
Davis and Walker, 2008; McLennan and Scott, 2002; Ross, 2003).

Linking the characteristics of contract types to the owner-contractor collaborative


relationships, we proposed that different contract types may influence the senior
management from both owner and contractor to develop and share a different degree of
relational attitudes (relational norms and commitment) in order to govern their relationship
ex-post during the project execution.
H1. Partnering/alliance contracts for projects are likely to display better relational
attitudes toward collaboration than (a) lump-sum or (b) reimbursable contracts.

Likewise different contract types imply different degree of teamworking (task-related and
social interactions) between owner team and contractor team when performing inter-
dependent tasks. Controlling for the effect of relational attitudes, we hypothesized:
H2. Partnering/alliance contracts for projects are likely to display better teamworking
quality than (a) lump-sum or (b) reimbursable contracts.

Independent of the remuneration schemes, incentive provisions can be incorporated into


any contract. There are four types of incentive schemes: (a) cost incentives, (b) schedule
incentives, (c) performance incentives, and (d) safety incentives (Bubshait, 2003; Herten and
Peeters, 1986). It is also not uncommon to have multiple-incentives, where two or more of
these incentives are combined into the same contract (Lowe, 2007). Within industrial project
practitioners, Bubshait (2003) finds a general agreement among respondents on the
effectiveness of incentive contracts in encouraging the contractor performance. Based on a
case study of three collaborative projects with differing contracting strategies, Berends
(2006) also reached the same conclusion that incentive schemes enhanced the alignment of
owner and contractor objectives. Similarly, Meng and Gallagher (2012) find that the use of
incentive schemes can increase the contractor’s awareness of improvement, which in turn

152 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

leads to much greater emphasis on the collaborative working relationship. Building on the
aforementioned studies’ findings, we hypothesized:
H3. Incentive-based contracts for projects are likely to display better relational
attitudes toward collaboration than non-incentive contracts.
H4. Incentive-based contracts for projects are likely to display better teamworking
quality than non-incentive contracts.

6.2.3. Contract types, incentives, and project performance


It is often suggested that a more collaborative contract, i.e.: partnering/alliance contract
leads to better construction performance than traditional contracts like lump-sum or
reimbursable contract (Bennet and Peace, 2006; ECI, 2003; Thompson and Sanders, 1998).
However, upon a sample of 318 industrial megaprojects, Merrow (2011) shows that the
success of projects executed with alliance contract was not better than those with lump-sum
or reimbursable contract. A survey study by Meng and Gallagher (2012) in the UK
construction firms also suggests that the performance (in terms cost, schedule, and quality)
of construction projects did not significantly associate with contract types (ranging from
fixed price to cost plus fee).

Analyzing the historical development of the UK defense procurement, Parker and Hartley
(1997) posit that a partnering/alliance contract does not necessarily lead to superior results
compared to traditional contracting. Likewise, a number of case studies suggest that a
partnering/alliance contract does not always eliminate the underlying adversarial attitude
between owner and contractor (Aarseth et al., 2012; Alderman and Ivory, 2007; Bresnen and
Marshall, 2002; Chan et al., 2012; Ng, Rose, Mak and Chen, 2002). In line with this view,
Lowe (2007) posits that the performance of a project depends upon the relationships
between the parties and not by and large on the contract. Some scholars argue that
different contract types have a different consequence on the degree of owner and
contractor collaboration which ultimately might influence project performance (Berends,
2007; Meng, 2011; Müller and Turner, 2005). Müller and Turner (2005), for example,
postulate that lump-sum and reimbursable contracts, compared to partnering/alliance
contract, tend to create a situation in which the owner and the contractor do not consider
the need to align their interests. As a result the owner-contractor collaboration becomes
limited and eventually leads to lower project performance. Recent study by Suprapto et al.,
(2015a) has empirically substantiated the positive effect of the owner-contractor
collaboration, in terms of relational attitudes and teamworking quality, on project
performance. Hence, it is arguable that the performance of the projects executed with
partnering/alliance contract is likely to be better than those with lump-sum or reimbursable
contract as the parties are able to work together more collaboratively. We hypothesized:

Collaborative contracting in projects 153


Chapter 6

H5. Partnering/alliance contracts for projects, through the more positive relational
attitudes and teamworking quality, are likely to perform better than (a) lump-sum or
(b) reimbursable contracts.

Contrary to a common belief that incentive schemes might have positive effect (Berends,
2006; Bubshait, 2003; Herten and Peeters, 1986), Merrow (2011) finds that contractual
incentives do not have any effects on project success. The success rate of projects with
incentives, although not statistically significant, was lower than those without incentives.
The assumption that there is a great deal of financial gain (incentives) to be saved through
efficient execution is a flawed idea. Merrow argues that execution is about to achieve the
targeted value (cost and schedule) that has been created and not to create new value. But it
would be a mistake to believe that incentives must always have a negative effect on
performance or make that the contractor cannot be motivated by both additional financial
rewards and interest in the work itself. It might be that the use of incentive schemes does
not directly affect project performance, but at a minimum, they can work under certain
circumstances. Explicit incentive schemes are designed to align the financial interests of the
contractor with those of the project goals (Berends, 2006; Bubshait, 2003; Meng and
Gallagher, 2012). Because achieving the project goals better is also improving their
commercial success (better profit), the contractor is more motivated to focus their effort in
managing and controlling factors that influence the team productivity which is critical for
achieving project duration and/or project cost (Bubshait, 2003). In the end, the effect of
contractual incentive on project performance can be explained by this indirect mechanism:
the aligned interests of owner and contractor ensure the attention on effective
teamworking, which in turn, enhances the project performance (Meng and Gallagher, 2012).
We therefore hypothesized:
H6. Incentive-based contracts for projects, through the more positive relational
attitudes and teamworking quality, are likely to perform better than non-incentive
contracts.

An integrative conceptual model shown in Figure 6-1 brings all the above hypotheses
together. The conceptual model applies a mediation structure with contract types and
contractual incentives as independent variables, relational attitudes and teamworking
quality as serial mediators and project performance as dependent variable. We cannot
justify theoretically the hypotheses regarding the direct effects of contract types and
contractual incentives on project performance but we explore these direct effects in the
analyses.

154 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

Contract types
PAL RE LS
Relational
D1 0 0 -1
attitudes
D2 0 -1 0 (M1)
H1a: a11
H1b: a21
H3: a31 b1
PAL vs. LS
(D1)

c’1
Project
PAL vs. RE c’2 performance
(D2) (Y)
d21
c’3

Contractual
H2a: a12 b2
Incentives
(X2) H2b: a22

H4: a32
Teamworking
H5a: a11b1, a11d21b2, a12b2 quality
H5b: a21b1, a21d21b2, a22b2 (M2)
H6: a31b1, a31d21b2, a32b2

Figure 6-1. Research model: Contract type, relationship quality, and performance. Note: PAL =
Partnering/alliance contract; RE = Reimbursable contract; LS = Lump-sum contract.

6.3. Research methodology


6.3.1. Data collection
The study population consisted of practitioners who have been involved in the execution of
capital projects within the Dutch Process Industry Competence Network (NAP-Netwerk). This
network brings together more than 120 organizations from the entire value chain in the
Dutch process industry, including asset owners, engineering and construction firms,
suppliers, consulting firms, and universities/research institutions. We invited around 450
practitioners to participate in an online questionnaire during a period from October to
December 2013. The response rate was 26.4% with 119 completed responses. Due to strict
anonymity reason, we were unable to exercise follow-up calls to assess non-responders. As
the proxy to assess potential non-response bias, we follow two methods of Lindner, Murphy
and Briers (2001): (1) the comparison of early to late respondents (t-test) and (2) using ‘days
to respond’ as the predicator to regression equations of the main constructs. The results
indicate that neither the mean difference of the constructs between early and late
respondents nor the ‘days to respond’ are significantly different.

After cleansing the responses with more than 15% missing values, we have 113 responses.
Among this dataset, there are 1.45% missing values of the total number of values. Little’s
MCAR test (Little and Rubin, 2002) suggests that the missing values were missing completely
at random (X2 = 4066.93; df = 3963; p = 0.122). This suggests no hidden systematic pattern of
missing values and thus any imputation method could be used (Hair., Black, Babin and

Collaborative contracting in projects 155


Chapter 6

Anderson, 2010). We then applied the regression imputation method to replace the missing
values in the dataset.

The sample varied widely in type of industry, type and size of projects, and type of
respondents. The majority of the respondents were project directors (19.5%), project
managers (46%), and team leaders/managers (24.8%) and the rest were functional managers
and project board members (9.7%). With regard to the company’s role, 41.6% of the
respondents represented owner companies, and 58.4% represented contractors. In terms of
industry, the majority of the projects were in oil, gas, and petrochemicals (60.4%); the rest
were in civil construction (8%), infrastructure, power, and utilities (10.6%), food and
consumer products (7.1%), electronics, ICT, and semiconductors (3.5%), pharmaceuticals
(2.7%), and manufacturing (2.7%). In terms of total project costs, 10.6% were up to €1
million, 30.1% were €1–10 million, 25.7% were €10–100 million, 24.8% were €100–1000
million, and 8.8% were more than €1 billion. Finally, in terms of contract types, 54.0% were
lump-sum, 33.6% were reimbursable, and 12.4% were partnering/alliance.

6.3.2. Method
We applied partial least square structural equation modeling (PLS-SEM) to test our research
model. We choose PLS-SEM in this study due to the following reasons. First, PLS-SEM is
suggested over covariance-based SEM (CB-SEM) when analyzing research models that are in
exploratory stage or an extension of existing structural theory (Hair, Ringle and Sarstedt,
2013b; Reinartz, Haenlein and Henseler, 2009). Because the underlying theory of our
research model is still ‘less developed’, PLS-SEM is the appropriate approach. Secondly, PLS-
SEM exhibits higher statistical power than CB-SEM when used in complex models with
smaller sample size (Hair, Sarstedt, Pieper and Ringle, 2012; Hair, Hult, Ringle and Sarstedt,
2013a; Reinartz et al., 2009). Hair et al. (2012; 2013a) recommend a minimum sample size of
10 times the maximum number of paths aiming to endogenous constructs. This study’s
sample size, 113 observations was relatively small but still above the minimum 100 samples
(10 times 10 paths directed at the construct project performance). Post-hoc statistical power
analysis also indicated that our sample size was above the commonly accepted threshold of
0.8 (Hair et al., 2013a). Prior investigations had also shown that the PLS-SEM algorithm
remains robust for non-normal or skewed data and formative measures (Rigdon, Ringle and
Sarstedt, 2010; Ringle, Götz, Wetzels and Wilson, 2009).

6.3.3. Statistical model


Because our hypotheses entail the comparison of three different contract types (lump-sum,
reimbursable, and partnering/alliance contracts), there is no single path coefficient that
represents contract type’s effect on the mediators or project performance. We followed
Hayes and Preacher’s (2014) guideline on statistical mediation analysis with multi-categorical
independent variable. The contract types can be transformed into k – 1 dummy variables or
2 (k = 3 is the number of contract types) dummy variables D1 and D2. D1 codes the lump-sum

156 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

contract, D2 codes the reimbursable contract, and the partnering/alliance contract serves as
the reference group and receives a code of 0 on both D1 and D2 (see Figure 6-1). The double-
headed arrow connecting D1 and D2 in Figure 6-1 indicates that the two variables should
always be simultaneously included in the analysis. Using these codes for contract types, the
mediation model can be parameterized with three equations:
𝑀𝑀1 = 𝑖𝑖11 + 𝑎𝑎11 𝐷𝐷1 + 𝑎𝑎21 𝐷𝐷2 + 𝑎𝑎31 𝑋𝑋2 + 𝑒𝑒𝑀𝑀1 (1)
𝑀𝑀2 = 𝑖𝑖12 + 𝑎𝑎12 𝐷𝐷1 + 𝑎𝑎22 𝐷𝐷2 + 𝑎𝑎32 𝑋𝑋2 + 𝑑𝑑21 𝑀𝑀1 + 𝑒𝑒𝑀𝑀2 (2)
𝑌𝑌 = 𝑖𝑖2 + 𝑐𝑐1′ 𝐷𝐷1 + 𝑐𝑐2′ 𝐷𝐷2 + 𝑐𝑐3′ 𝑋𝑋2 + 𝑏𝑏1 𝑀𝑀1 + 𝑏𝑏2 𝑀𝑀2 + 𝑒𝑒𝑌𝑌 (3)

for relational attitudes (M1), teamworking quality (M2), and project performance (Y)
respectively where X2 is contractual incentive; i11, i12, and i2 are constants; 𝑒𝑒𝑀𝑀1 , 𝑒𝑒𝑀𝑀2 , and 𝑒𝑒𝑌𝑌
are error terms.

Estimation of Eq. (1) yields three coefficients quantifying differences between the contract
types and incentive on relational attitudes (a11, a21, and a31 or H1a, H1b, and H3 respectively).
Eq. (2) estimates three coefficients quantifying differences between the contract types and
incentive on teamworking quality (a12 a22, and a32 or H2a, H2b, and H4 respectively) and one
coefficient quantifying the effect of relational attitudes on teamworking quality (d21). Eq. (3)
estimates three coefficients quantifying the mean group differences in project performance
due to contract types (c'1 and c'2) and contractual incentive (c'3) holding both relational
attitudes and teamworking quality constant. These three coefficients, also called relative
direct effects, correspond to H5a, H5b, and H6, i.e.: the relative direct effects of
reimbursable (c'1) and partnering/alliance contract (c'2) on project performance over lump-
sum contract, and the relative direct effect of incentive-based contract on project
performance over non-incentive contract (c'3).

Eq. (3) also estimates two coefficients quantifying the effects of relational attitudes and
teamworking quality on project performance (b1 and b2) while statistically equating the
groups on average on contract type. Taking into account all coefficients estimated from Eqs.
(1), (2), and (3); we can estimate the relative indirect effects of contract types and incentive
on project performance through relational attitudes and teamworking quality. H5a
corresponds to the relative indirect effect of a partnering/alliance contract on project
performance over lump-sum contract through relational attitudes and teamworking quality
and is captured by three specific indirect effects: a11b1 (D1→M1→Y), a11d21b2
(D1→M1→M2→Y), and a12b2 (D1→M2→Y). H5b or the relative indirect effect of
partnering/alliance contract on project performance over reimbursable contract is captured
in a21b1 (D2→M1→Y), a21d21b2 (D2→M1→M2→Y), and a22b2 (D2→M2→Y). In a similar
manner, the relative indirect effect of contractual incentive on project performance through
relational attitudes and teamworking quality (H6) is captured by a31b1 (X2→M1→Y), a31d21b2
(X2→M1→M2→Y), and a32b2 (X2→M2→Y).

Collaborative contracting in projects 157


Chapter 6

For each independent variable (D1, D2, or X2), summing up its relative direct effect and three
specific indirect effects is equal to its relative total effect (ci) on project performance. For
example, the relative total effect of partnering/alliance over lump-sum contract on project
performance is c1 = c'1 + a11b1 + a11d21b2 + a12b2.

6.3.4. Measures
Most of the key constructs were measured through multi-item scales. We relied on existing
measurement scales that have been validated in prior research. All items were designed with
responses on a five-point scale ranging from 1 (representing a zero of the trait; e.g., not
satisfied at all) to 5 (representing a perfectly positive assessment of the trait; e.g.,
completely satisfied). All measurement items are listed in full in Appendix 6-1.

We followed Merrow’s (2011) basic forms of contract and used three categories of
contracts: lump-sum, reimbursable, and partnering/alliance. Lump-sum contract includes
the variants like convertible lump-sum and provisional lump-sum. Reimbursable contract
also includes unit rate or schedule rate and any cost plus contracts. Partnering/alliance
contract includes both partnering and alliancing contracts. Contractual incentive was
operationalized as a categorical variable and reflects whether or not the contract includes
any explicit incentive schemes.

Relational attitudes were operationalized as a higher-order construct consisting of 2 first-


order reflective constructs: senior management commitment and relational norms. The
measures for these constructs have been developed by Suprapto et al. (2015a) with 3 items
for senior management commitment (i.e.: commitment to provide resources and support,
leadership, active involvement in resolving conflict) and 5 items for relational norms (i.e.:
aligned interests and objectives, mutual trust, no blame culture, and openness).

Teamworking quality was operationalized as a higher-order construct consisting of 7 first-


order reflective constructs: communication, coordination, cohesion, balanced contribution,
aligned effort, mutual support, and affective trust. The first 6 constructs used reflective
scales adapted by Hoegl and colleagues (Hoegl and Gemuenden, 2001; Hoegl and
Parboteeah, 2007; Hoegl et al., 2004). The affective trust construct used reflective scales
adapted from Lau and Rowlinson (2011), Pinto et al. (2009), and Silva, Bradley and Sousa
(2012). In total, there were 27 items to measure teamworking quality: communication (4
items), coordination (4 items), cohesion (4 items), balanced contribution (3 items), aligned
effort (3 items), mutual support (3 items), and affective trust (6 items).

Project performance was operationalized as a formative construct of 4 items. The first


measurement item was an index of performance reflecting project efficiency and
effectiveness indicators, i.e.: cost, schedule, quality, safety, and operability performance.
This index was calculated as an average value of the five indicators weighted by their relative
importance in the eye of respondents. The other three distinct items were perceived

158 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

satisfaction on the overall results, perceived business success to owner, and perceived
commercial success to contractor (Pinto et al., 2009; Hoegl and Gemuenden, 2001).

Finally, we included five control variables: perceived front-end definition, project size, firm
size, prior relationship duration, and early contractor involvement to control for potential
confounders. The first three control variables are also considered as the proxy to
characterize the complexity factors (Bosch-Rekveldt et al., 2011). The perceived front-end
definition includes four reflective items adapted from Merrow’s (2011) front-end loading
criteria: the perceived clarity of the project goals, clarity of the project scope, quality of the
basic design and quality of the execution plan. The project size was measured with two
reflective items, the project duration and total installed cost. The firm size was measured
with two reflective items, the firm’s number of employees and annual turnover. Prior
relationship duration refers to number of years in which the owner and the contractor had
been working in the previous projects. Finally, the contractor’s early involvement variable
reflects whether the contractor was already involved during the front-end development
stage of the project.

6.4. Results
We used SmartPLS 2.0 (Ringle, Wende and Will, 2005) to estimate the measurement models
and the structural models. In assessing the measurement and structural models, we
followed the procedures suggested by Chin (2010) and Hair et al. (2012, 2013a, 2013b).

6.4.1. Measurement models


As indicated in section 6.3.4, our measurement models consist of two types of latent
constructs, i.e.: 11 reflective constructs and 1 formative construct. Each type of construct
requires different evaluation criteria. Hair et al (2013a; 2013b) recommend that all reflective
constructs should be evaluated against (a) indicator reliability (indicator loadings ≥ 0.70), (b)
internal consistency reliability (Cronbach’s alpha and composite reliability ≥ 0.70), (c)
convergent validity (AVE – average variance extracted ≥ 0.50), and (d) discriminant validity
(Fornell-Larcker criterion). For formative constructs, Hair et al. recommend to assess (a) the
statistical significance or the relevance of the indicators (significant relative weight or
indicator loadings ≥ 0.50), and (b) multicollinearity among indicators to identify/remove
potential redundancy (variance inflation factors among indicators - VIFs < 5.0).

The assessment of the measurement models indicates that all 11 reflective constructs are
completely satisfactory. First, all 41 reflective indicators reach sufficient levels of indicator
reliability as all indicators’ loadings on their corresponding constructs are above 0.707
(Appendix 6-1). Second, all reflective constructs also satisfy internal consistency reliability as
all constructs’ Cronbach’s alpha and composite reliability are equal and above 0.708 and
0.868 respectively (Appendix 6-1). Third, all reflective constructs achieve convergent validity
as the AVE values surpass the 0.5 level (Appendix 6-1). Finally, the Fornell-Larcker criterion

Collaborative contracting in projects 159


Chapter 6

analysis shows that all reflective constructs attain discriminant validity as the square roots of
AVE of all reflective constructs (the diagonal elements) are larger than their inter-
correlations (the off-diagonal elements) (see Appendix 6-2).

The assessment of the formative construct, project performance, indicates that 2 indicators
do not have significant relative weights, however, all loadings are above 0.5 (see Appendix 6-
1). Through multiple regressions, we obtained the average VIF values of the four formative
indicators ranging from 1.424 to 2.503. VIF values are below the threshold value of 5 thus
multicollinearity is not an issue. Overall, all 4 indicators attain the formative criteria.

6.4.1.1. Common method variance


Because the data originated from single respondents answering an online questionnaire,
common method variance (CMV) might influence some hypothesized relations in the PLS
path model. To test for the potential existence of common method variance, Harman's
(1976) single-factor test was conducted. The first factor accounts for only 35.4% of the
overall variance, which indicates that common method variance unlikely affects the results
(Podsakoff and Organ, 1986). Because this traditional test suffers some limitations, the
marker variable approach (Podsakoff, MacKenzie, Lee and Podsakoff, 2003; Richardson,
Simmering and Sturman, 2009; Williams, Hartman and Cavazotte, 2010) was also applied.
More specifically, we applied Rönkkö and Ylitalo's (2011) PLS marker approach. Using a
marker variable with six indicators, we estimated the method variance correlation by
calculating a mean of the correlations between the marker indicators and the study
indicators. The mean correlation is 0.03 which is smaller than the suggested threshold of
0.05 and indicates that the common method variance has a negligible effect (Rönkkö and
Ylitalo, 2011). To ensure this, we ran the baseline model both without the marker variable
and with the marker variable (with paths to all endogenous constructs). A comparison of the
results shows trivial differences (ranging from 0.002 to 0.021) on all path coefficients and no
changes in their level of statistical significance. We therefore continued the PLS analysis
without the marker variable.

6.4.1.2. Potential endogeneity bias


Like most empirical studies on inter-firm alliances in strategic management literature
(Hamilton and Nickerson, 2003), our research model is analogous to the performance effect
of the strategic choice model with discrete strategies (contract types) and continuous
performance outcomes (the degree collaboration and project performance). The contract
choice was decided by managers based on known ex-ante factors such as the perceived
uncertainty, complexity, and therefore risks of the project (Berends, 2007; Lowe, 2007;
Merrow, 2011; Smith, 2002), trust and norms that arise from expectation of continuity
(Poppo et al., 2008) and prior relationship (Gulati, 1995; Lui and Ngo, 2004), and the parent
firm’s capability (Hamilton and Nickerson, 2003). To control for these known ex-ante factors,
we included in the PLS-SEM structural model five control variables: the perceived front-end

160 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

definition, project size, firm size, prior relationship duration, and early contractor
involvement. Still, senior managers’ decision on contract type is also affected by their
expectation of the outcomes due to some other factors unobserved that may actually drive
the outcomes. In economics and strategic management literature this is also called ‘self-
selection bias’ (Antonakis, Bendahan, Jacquart and Lalive, 2010; Hamilton and Nickerson,
2003).

To check whether this endogeneity biases the accuracy of the structural model, we
performed the Heckman’s (1976, 1979) two-step procedure to control for endogeneity bias
(similar to the approach performed by Gopal et al., 2003). Specifically, in the first stage we
applied Heckman’s probit model for predicting the binary variable contractual incentives,
and Lee’s (1983) multinomial logit model for multi-categorical variable contract type. In both
models we included the aforementioned control variables and five additional instrumental
variables as predictors. The instrumental variables are the perceived technological risk,
regulatory challenges, market volatility, location remoteness, and pressure from external
stakeholder that might affect contract choice but do not directly impact the endogenous
constructs (relational attitudes, teamworking quality, and project performance). We then
calculated the Inverse Mills Ratio for contractual incentives (IMRIC) and contract type (IMRCT)
as endogeneity bias correction variables. In the second stage, we included IMRIC and IMRCT
into the structural models for predicting the endogenous constructs and applied
bootstrapping to obtain the corrected standard error and coefficient estimates. The results
suggest that the coefficients of the IMRIC and IMRCT for all three endogenous regression
models are not significantly different from zero. Hence the potential endogeneity bias is not
a concern. We continue the analyses of the PLS structural model without correcting for
endogeneity bias.

6.4.2. Structural model


We performed a two-steps analysis to provide a detailed picture of all hypotheses testing. In
the first step, we focused on the PLS-SEM structural model that estimates the direct path
coefficients between all constructs (hypotheses 1 to 4; see Figure 6-2 and Table 6-1).
Subsequently, in step 2, we performed statistical mediation analysis (Hayes, 2013; Hayes and
Preacher, 2014) to assess the indirect effects of contract types and incentives on project
performance mediated by relational attitudes and teamworking quality (hypotheses 5 and 6;
see Table 6-2). We also included five control variables: front-end definition, project size, firm
size, prior relationship duration, and early contractor involvement. The significance of all
path coefficients were assessed through bootstrapping with 113 cases, 10,000 subsamples
and no sign changes option (Hair et al., 2013a, 2013b).

Collaborative contracting in projects 161


Chapter 6

Relational
attitudes (M1)
R2 = 0.331
a11= 315*
a21 = 0.341* b1 = 0.034 ns
PAL vs. LS
a31 = 0.225*
(D1)

c’1 = 0.062 ns
Project
PAL vs. RE c’2 = 0.059 ns performance
(D2) (Y)
d21 = 0.573*** R2 = 0.524
c’3 = (-0.176) ns

Contractual
a12=0.125 ns b2 = 0.465**
incentives
(X2) a22 = (-0.019) ns

a32 = (-0.014) ns
Teamworking
quality (M2)
R2 = 0.641

Figure 6-2. Structural model diagram. Note: PAL = Partnering/alliance contract; RE = Reimbursable
contract; LS = Lump-sum contract; all path coefficients are unstandardized; *sig. at p < .05; **sig. at p < .01;
***sig. at p < 0.001; ns = not significant, based on bootstrapping of 10,000 subsamples; control variables are
not shown in the diagram.

The main criteria to assess the structural model in the PLS-SEM are the coefficient of
determination R2 and the predictive relevance Q2 (Henseler and Sarstedt, 2012). As shown in
Figure 6-2, the structural model accounts for 33.0% of the variance in relational attitudes,
64.1% of the variance in teamworking quality, and 52.4% of the variance in project
performance. These R2 values substantiate the model’s predictive validity (Hair et al., 2013a,
2013b). The blindfolding procedure (Henseler, Ringle and Sinkovics, 2009) results in the Q2
values of 0.540, 0.458, and 0.277 for relational attitudes, teamworking quality, and project
performance respectively. Since all Q2 values for endogenous constructs are positive, the
structural model attains sufficient predictive relevance. The mediators, relational attitudes
and teamworking quality contribute to f2 effect size = 0.26, a medium to large effect size
according Hair’s et al. (2013a, 2013b) guideline. It is supported that the structural model has
a significant level of predictive validity on project performance.

162 Collaborative contracting in projects


Table 6-1. Unstandardized paths coefficients
Relation Outcome
To Relational attitudes (M1) Teamworking quality (M2) Project performance (Y)
From coeff. SE p coeff. SE p coeff. SE p
Constant i11 1.873 *** 0.343 0.000 i12 0.738 *** 0.222 0.001 i2 0.279 ns 0.424 0.512
PAL vs. LS (D1) a11 0.315 * 0.148 0.036 a12 0.125 ns 0.095 0.193 c'1 0.062 ns 0.144 0.666
PAL vs. RE (D2) a21 0.341 * 0.161 0.037 a22 -0.019 ns 0.106 0.856 c'2 0.059 ns 0.156 0.708
a
RE vs. LS (D1-D2) a12-a21 -0.026 ns 0.118 0.827 a12-a22 0.144 ns 0.083 0.084 c'1-c'2 0.004 ns 0.115 0.973

Collaborative contracting in projects


Contractual Incentives (X2) a31 0.225 * 0.111 0.045 a32 -0.014 ns 0.077 0.856 c'3 -0.176 ns 0.109 0.109
Relational attitudes (M1) d21 0.573 *** 0.098 0.000 b1 0.034 ns 0.148 0.820
Teamworking quality (M2) b2 0.465 ** 0.175 0.009
Control variables:
Front-end definition f1 0.419 *** 0.083 0.000 g1 0.139 ns 0.070 0.051 h1 0.391 *** 0.086 0.000
Project size f2 0.022 ns 0.033 0.511 g2 -0.011 ns 0.018 0.544 h2 -0.030 ns 0.037 0.417
Firm size f3 0.026 ns 0.039 0.505 g3 0.057 * 0.025 0.027 h3 0.049 ns 0.043 0.256
Prior relationship f4 0.004 ns 0.005 0.391 g4 0.002 ns 0.003 0.506 h4 -0.005 ns 0.005 0.318
Early contractor involvement f5 -0.030 ns 0.106 0.781 g5 0.086 ns 0.068 0.210 h5 -0.148 ns 0.100 0.142
2 2 2 2 2 2
Predictive relevance R = 0.331; R adj = 0.280 R = 0.641; R adj = 0.610 R = 0.524; R adj = 0.477
Omnibus test F(8,104) = 9.650, p < .001 F(9,103) = 28.108, p < .001 F(10,102) = 12.813, p < .001

Note: PAL = Partnering/alliance contract; RE = Reimbursable contract; LS = Lump-sum contract; *significant at p < 0.05, **p < 0.01, ***p < 0.001 based on bootstrapping
of 10,000 subsamples; ns = not significant.
a
estimated separately by changing the reference category to RE.

163
How do contract types and incentives matter to project performance?
Chapter 6

6.4.2.1. The relative direct effects of contract types and incentives on relational attitudes and
teamworking quality
The results in Figure 6-2 and Table 6-1 show that the projects with partnering/alliance
contract are associated with better relational attitudes than those with lump-sum (a11 =
0.315, p < 0.05) and reimbursable contracts (a21 = 0.341, p < 0.05). However, the projects
with lump-sum contract do not have better relational attitudes than those with
reimbursable contract (a21 - a11 = -0.026, p = 0.827). Adjusting for the differences in relational
attitudes, the projects with partnering/alliance contract do not differ in teamworking quality
from those with lump-sum (a12 = 0.125, p = 0.193) and reimbursable contract (a22 = -0.019, p
= 0.856). The results suggest that only hypothesis 1a and 1b are supported. Hypotheses 2a
and 2b are not supported.

The effects of contractual incentives on relational attitudes and teamworking quality seem
to follow a similar pattern. The projects with contractual incentives are significantly
associated with better relational attitudes compared to those without incentive (a31 = 0.225,
p < 0.05) but not different in terms of teamworking quality (a32 = -0.014, p = 0.856).
Hypothesis 3 is supported and hypothesis 4 is not supported.

6.4.2.2. The relative direct effects of contract types and incentives on project performance
Although not explicitly hypothesized, we analyzed how different contract types and
contractual incentives might have different direct effects on project performance controlling
for relational attitudes and teamworking quality. The direct paths from two contract types
and contractual incentive to project performance in Figure 6-2 and Table 6-1 suggest that
the performance of projects with partnering/alliance contract is not significantly different
from those with lump-sum (c’1 = 0.062, p = 0.666) or reimbursable contract (c’2 = 0.059, p =
0.708). Similarly, the performance of projects with lump-sum contract is not different from
those with reimbursable contract (c’2 – c’1 = 0.004, p = 0.973). Also with regard to contractual
incentive, the projects with incentive-based contract do not perform better than those
without incentive (c’3 = -0.176, p = 0.109).

6.4.2.3. The effects of relational attitudes and teamworking quality on project performance
Figure 6-2 and Table 6-1 show that after controlling for contract types and contractual
incentives, relational attitudes significantly increase teamworking quality (d21 = 0.574, p <
0.001). Teamworking quality, in turn, significantly increases project performance (b2 = 0.460,
p < 0.01). Independent of the effects on teamworking quality, however, relational attitudes
do not affect project performance (b1 = 0.103, p = 0.408).

Because our model involves a mediation mechanism with two mediators, the structural
model should meet the no-interaction assumption or homogeneity of regression (Hayes and
Preacher, 2014), i.e.: the effects of the mediators (relational attitudes and teamworking
quality) on the dependent variable (project performance) should be invariant across the

164 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

values of independent variables (contract types and contractual incentives). If the


assumption is violated, any indirect effect does not accurately characterize the effects of
relational attitudes and teamworking quality on project performance because these effects
(b1 and b2) are dependent on contract types or contractual incentive. To test this assumption
we included six interaction terms between independent variables and mediators into the
regression model to estimate project performance (Equation 3). The difference in R2
between two estimations of project performance with and without six interaction terms (R2
= 0.536 and R2 = 0.524 respectively) is ∆R2 = 0.012 and non-significant (F(6,96) = 0.421, p =
0.863). Thus, the homogeneity of regression assumption is maintained and any interaction
effects can be ruled out. This also implies that the effects of teamworking quality and
relational attitudes (through teamworking quality) on project performance are independent
of contract type and contractual incentive.

6.4.2.4. The relative indirect effects of contract types and incentives on project performance
mediated by relational attitudes and teamworking quality
Hypotheses 5 and 6 assume that different contract types or contractual incentives might
have different relative indirect effects on project performance through their effects on
relational attitudes and teamworking quality. Using PROCESS tool (Hayes, 2013; Hayes and
Preacher, 2014), we estimated these relative indirect effects with 10,000 bootstrap
subsamples as shown in Table 6-2. There are three specific pathways where contract types
and contractual incentives may indirectly affect project performance: via M1→Y (relational
attitudes then project performance), via M1→M2→Y (relational attitudes then teamworking
quality and finally to project performance), and via M2→Y (teamworking quality then project
performance).

The results in Table 6-2 indicate that the projects with partnering/alliance contract
significantly perform better than those with lump-sum contract through the pathway
D1→M1→M2→Y or through better relational attitudes which in turn lead to better
teamworking quality (a11d21b2 = 0.084, CI = 0.019 to 0.222). Likewise, the projects with
partnering/alliance contract significantly perform better than those with reimbursable
contract due to the pathway D2→M1→M2→Y or through better relational attitudes which in
turn lead to better teamworking quality (a21d21b2 = 0.091, CI = 0.017 to 0.239). With regard
to the difference between reimbursable and lump-sum contracts, only the specific pathway
through teamworking quality, (D1-D2)→M2→Y is significant ((a12-a22)b2 = 0.067, CI = 0.003 to
0.190).

Finally, the projects with incentive-based contracts significantly perform better than those
without incentive (a31d21b2 = 0.060, CI = 0.010 to 0.155) as the results of better relational
attitudes which in turn lead to better teamworking quality (X2→M1→M2→Y). To sum up,
hypotheses 5a, 5b, and 6 are empirically substantiated.

Collaborative contracting in projects 165


166
Table 6-2. Relative total, direct, and indirect effects of contract types and contractual incentive

Relative total effect Relative direct effect Relative indirect effect


Chapter 6

95% BCB-CI
coeff. SE p coeff. SE p coeff SE LL UL
PAL vs. LS (D1) c1 0.215 ns 0.150 0.155 c'1 0.062 ns 0.134 0.666
Total indirect effect: c1-c'1 0.152 sig. 0.065 0.047 0.306
Ind1 (D1→M1→Y): a11b1 0.011 ns 0.045 -0.057 0.136
Ind2 (D1→M1→M2→Y): a11d21b2 0.084 sig. 0.046 0.019 0.222
Ind3 (D1→M2→Y): a12b2 0.058 ns 0.051 -0.011 0.192
PAL vs. RE (D2) c2 0.152 ns 0.159 0.343 c'2 0.059 ns 0.156 0.708
Total indirect effect: c2- c'2 0.093 ns 0.077 -0.041 0.265
Ind1(D2→M1→Y): a21b1 0.012 ns 0.048 -0.063 0.146
Ind2(D2→M1→M2→Y): a21d21b2 0.091 sig. 0.052 0.017 0.239
Ind3 (D2→M2→Y): a22b2 -0.009 ns 0.050 -0.112 0.088
a
RE vs. LS (D1-D2) c1-c2 0.063 ns 0.129 0.625 c'1-c'2 0.004 ns 0.115 0.973
Total indirect effect: (c1-c’1)-(c2-c'2) 0.059 ns 0.056 -0.044 0.179
Ind1 (D2-D1→M1→Y): (a11-a21)b1 -0.001 ns 0.017 -0.051 0.023
Ind2 (D2-D1→M1→M2→Y): (a11-a21)d21b2 -0.007 ns 0.030 -0.074 0.048
Ind3 (D2-D1→M2→Y): (a12-a22)b2 0.067 sig. 0.045 0.003 0.190
Contractual incentives (X2) c3 -0.115 ns 0.121 0.341 c'3 -0.176 ns 0.101 0.109
Total indirect effect: c3-c'3 0.061 ns 0.055 -0.035 0.174
Ind1 (X2→M1→Y): a31b1 0.008 ns 0.035 -0.035 0.110
Ind2 (X2→M1→M2→Y): a31d21b2 0.060 sig. 0.034 0.010 0.155
Ind3 (X2→M2→Y): a32b2 -0.007 ns 0.035 -0.070 0.071
Note: PAL = Partnering/alliance contract; RE = Reimbursable contract; LS = Lump-sum contract; M1 = relational attitudes; M2 = teamworking quality; Y = project
performance; *significant at p < 0.05, ** p<0.01, *** p < 0.001 based on bootstrapping of 10,000 subsamples; ns = not significant, sig. = significant based on 95% bias-
corrected bootstrap confidence interval (95% BCB-CI).
a
estimated separately by changing the reference category to RE.

Collaborative contracting in projects


How do contract types and incentives matter to project performance?

6.5. Discussion
6.5.1. Contribution and theoretical implications
In this study we hypothesized that different contract types and contractual incentives can
have different effects on project performance directly or indirectly through owner-
contractor relationship quality (i.e.: relational attitudes and teamworking quality). Such a
conceptual model was not considered in prior research. By analyzing the direct and indirect
effects of contract types and contractual incentives on project performance, our study
provides some important insights into the current literature on project contracting and
collaboration.

The first important finding clarifies the effect of partnering/alliance contract compared to
lump-sum and reimbursable contracts. The partnering/alliance contract, on average, is
indirectly associated with better project performance compared to lump-sum or
reimbursable contract through better relational attitudes and teamworking quality. This
corroborates the findings of partnering and alliance studies reporting that the performance
of partnering or alliance projects are strongly determined by commitment, trust, no blame
culture, and openness shared by senior management representing owner and contractor;
and effective teamworking (Chan et al., 2004; Chan et al., 2012; Green, 2003; Laan, Voordijk
and Dewulf, 2011; Walker and Lloyd-Walker, 2015). Apart from its indirect effects through
relational attitudes and teamworking quality, the direct effect of partnering/alliance
contract on project performance does not differ from lump-sum and reimbursable contracts.
Considering both the indirect and direct effects as the total effect (see Table 6-2),
partnering/alliance projects, although not statistically significant, are likely to perform better
than those with lump-sum or reimbursable contract. This finding partly contradicts Merrow’s
(2011) conclusion that partnering/alliance projects tend to perform worse than those with
lump-sum and reimbursable contracts. Unlike Merrow (2011), this study analyzes both
indirect and direct effects of different contract types rather than on the total effect only.

The second important finding is regarding the influence of contractual incentives. There are
two perspectives that appeared to be inconsistent regarding the effects of incentive-based
contracts on project performance. The first perspective represented by Berends (2006;
2007) and Meng and Gallagher (2012), suggests that the use of an explicit incentive structure
facilitates trust and open communication (better relational attitudes) between owner and
contractor which in turn enhances the teams’ performance in executing the project
management processes (better teamworking quality) and finally leads to better project
performance. The second perspective reflects Merrow’s (2011) finding that the success rate
of projects with incentives is actually lower than those without incentives, although not
statistically significant. He concludes that the effect of incentives on project success simply
occurred by chance. Our finding clarifies the above seemingly contradictory views. Firstly,
incentive-based contracts are indirectly associated with better project performance relative
to those without incentive through its positive effect on relational attitudes which in turn

Collaborative contracting in projects 167


Chapter 6

lead to enhanced teamworking quality. This indirect mechanism supports the first
perspective (Berends, 2007; Meng and Gallagher, 2012). Apart from this indirect mechanism,
we also found that incentive-based contracts, although not statistically significant, have
negative direct effect on project performance. When we consider both the indirect and the
direct effects of contractual incentives, they are canceling each other leading to non-
significant total effect on project performance (see Table 6-2). This supports the first
perspective (Merrow, 2011) that contractual incentives have no effect on project
performance. In summary, both perspectives are actually not contradictory.

The third important finding relates to a common belief that the relationships in projects with
lump-sum contract tend to be more adversarial than those with reimbursable contract (e.g.:
Smith, 2002). Although not explicitly hypothesized, we also compared the relative effect
between the two contract types. The results do not provide empirical support for this
notion. We found virtually no difference in the degree of relational attitudes and
teamworking quality between reimbursable and lump-sum projects. This finding concurs
Parker and Hartley’s (1997) view that traditional contracting does not always result in
adversarial attitudes. On the other hand, we found that through better teamworking quality,
projects with reimbursable contract perform better than those with lump-sum contract. This
is not a surprise since a reimbursable contract entails the larger owner’s team to steer,
coordinate, and support the contractor’s team toward the achievement of the project
objectives (Berends, 2007; Merrow, 2011).

Last but not least, after controlling for contract types and incentives, we found that
relational attitudes significantly lead to enhanced teamworking quality which in turn
improves project performance. This implies that apart from the effects of contract types and
incentive, the quality of owner-contractor collaboration positively contributes to project
performance. This finding also illuminates the notion “no contracting approach guarantees
success; most contracting approaches can succeed” (Merrow, 2011, p.253). What matters
more is the ability of both parties to develop relational attitudes and translate this into real
teamworking (Suprapto et al., 2015a).

6.5.2. Managerial implications


This study provides some important implications for senior management, business or
contract managers, and project managers of firms who are seeking and developing
appropriate contracting strategies for capital project execution.

The first implication is related to the effects of different contract types on project
performance. Relative to lump-sum or reimbursable contract, partnering/alliance contract is
positively associated with higher degree of relational attitudes and teamworking quality
which in turn translates into better project performance. If there is freedom to select a
contract type for a project, we advise senior management and/or project managers to use a
partnering/alliance contract because it enhances relational attitudes leading to more

168 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

effective teamworking and eventually better project performance. However, managers


should be aware that such a contract does not directly increase project performance on its
own but indirectly through its effect on relational attitudes and then teamworking quality.
Partnering/alliance and contractual incentives do have a positive influence on the project
but they also come at a cost. Managers from both sides need to ensure ongoing support
from senior management and translate their shared norms into effective teamworking
throughout the project life cycle (see also Chan et al., 2012; Laan et al., 2011; Walker and
Lloyd-Walker, 2015). Failure to do so, the project performance might not change as with
other contract types.

The second implication is related to the influence of relational attitudes and teamworking
quality on project performance. We found that after controlling for contract types and
incentives, the quality of owner-contractor relationship (relational attitudes at inter-
organizational and teamworking at team levels) significantly influences project performance.
Although the results suggest that partnering/alliance contract is relatively better, in many
cultures, a lump-sum contract remains the most chosen contract type followed by
reimbursable contract (this study and Merrow, 2011). If a lump-sum or reimbursable
contract is already predetermined for a project, we advise managers from both sides to put
extra attention on developing relational attitudes and ensuring effective teamworking. Also
because relational attitudes do not directly improve project performance but through
teamworking quality, project managers need: (a) to secure the ongoing parent
organizational support by catalyzing a joint commitment and norms of trust and respect
between senior management, and (b) to ensure ongoing effectiveness of teamworking by
fostering communication, coordination, cohesion, balanced contribution, mutual support,
aligned effort, and affective trust.

Finally, managers need to be cautious when considering using incentive schemes. Our
findings suggest that contractual incentives have significant positive indirect effect but also
negative direct effect, although not statistically significant. The implication is clear,
contractual incentives are no substitute for real collaborative relationship and should not be
used to limit the owner’s involvement in the process of collaboration (Berends, 2014; Meng
and Gallagher, 2012). Contractual incentives cannot improve performance if the managers
(senior management and project managers) from both sides do not share equitable
commitment, respect and trust and properly manage to articulate a direction persuasively
on the extent the teams work together, contribute solutions to problems, and confront
difficulties whenever they arise at.

6.5.3. Limitations and future research


This study has some limitations in its results and conclusions. The first limitation is related to
the research design employed in this study. This study was observational hence could not
establish the causal ordering. Our findings should not be interpreted as evidence of causality
but rather as supporting a predictive scheme.

Collaborative contracting in projects 169


Chapter 6

Other limitations are related to the characteristics of the data used in this study. The data
was based on the respondents’ observation thus all constructs and their relations should be
interpreted as the phenomenon as perceived by the practitioners. The representativeness of
the sample may limit the generalizability of the findings. Although the sample includes
practitioners’ reflection on projects in various countries in different continents, the majority
(64%) of them were based in the Netherlands. Some projects executed in countries like Asia,
Middle East, South America, and North America regions can have different characteristics
given different country-specific regulations and cultures. The same limitation also applies to
the project type due to the strong presence of oil, gas, and petrochemicals projects (60%) in
the sample. Future studies should aim to replicate the findings with a larger sample, in
different countries and project types. Another promising avenue for future study is to
extend our research model by considering complexity and cultural factors as potential
moderators.

Another limitation is concerning the partnering/alliance contract. This study did not
distinguish partnering from ‘pure’ alliance contract. The proponents of ‘pure’ alliance argue
that alliance is a legally enforceable form of relational contracting with formal charter,
governance and management structures (see Ross, 2003; Walker and Hampson, 2003).
Despite this limitation, we are confident that our finding remains supported for the relative
advantages of alliance contract over lump-sum or reimbursable contract. Nonetheless,
future studies with a larger sample could extent the analysis by further comparing the
performance of alliance with partnering contract.

Finally, although our comprehensive model includes important constructs reflecting two
types of relationships, relational attitudes at inter-firm level and teamworking quality at
inter-team level, we were unable to include other types of relationships, for example, the
relationship between the parent organization (senior management) and the corresponding
team members that could potentially affect project performance. Future research should
explore the effect of these other types of relationships.

6.6. Conclusions
Researchers and practitioners have acknowledged the importance of the more collaborative
contracts to achieve better project performance by promoting a better working relationship
between owner and contractor. However, mixed results of different contract types on
project performance suggest the need for research on intermediate mechanisms linking the
effects of contract types to project performance. This study applies a mediation model in
which relational attitudes and teamworking quality mediate the effects of contract types and
contractual incentives on project performance. The results support the notion that a
partnering/alliance contract is likely to be more collaborative than a lump-sum or
reimbursable contract. However, there is no evidence that a reimbursable contract is more
collaborative than a lump-sum contract. Furthermore, it is supported that through better
relational attitudes and teamworking quality, projects with a partnering/alliance contract are

170 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

likely to perform better than those with lump-sum and reimbursable contracts. In the same
way, projects with contractual incentives are likely to perform better than those without
incentives through better relational attitudes and teamworking quality. The results also
suggest the positive effects of relational attitudes and teamworking on project performance
regardless of the contract types and the presence of incentives. All in all, contract types and
contractual incentives per se are not the game changer but the parties’ attitudes toward
collaborative relationship and how they play out throughout the project into actual
teamworking behavior.

Collaborative contracting in projects 171


Chapter 6

References
Aarseth, W., Andersen, B., Ahola, T., Jergeas, G., 2012. Practical difficulties encountered in attempting to
implement a partnering approach. International Journal of Managing Projects in Business, 5 (2), 266-
284.
Alderman, N., Ivory, C., 2007. Partnering in major contracts: paradox and metaphor. International Journal of
Project Management, 25 (4), 386-393.
Antonakis, J., Bendahan, S., Jacquart, P., Lalive, R., 2010. On making causal claims: A review and
recommendations. The Leadership Quarterly, 21, 1086-1120.
Beach, R., Webster, M., Campbell, K.M., 2005. An evaluation of partnership development in the construction
industry. International Journal of Project Management, 23 (8), 611-621.
Bennet, J., Peace, S., 2006. Partnering in the Construction Industry: A Code of Practice for Strategic
Collaborative Working. Butterworth-Heineman, Burlington.
Berends, T.C., 2006. Cooperative contracting on major engineering and construction projects. The Engineering
Economist, 5, 35-51.
Berends, T.C., 2007. Engineering and construction projects for oil and gas processing facilities: Contracting,
uncertainty and the economics of information. Energy Policy, 35, 4260-4270.
Berends, T.C., 2014. Contracting, in: Bakker, H.L.M., de Kleijn, J.P. (Eds.), Management of Engineer Projects:
People are Key. NAP - The Process Industry Competence Network, Nijkerk, The Netherlands, pp. 157-
173.
Bosch-Rekveldt, M., Jongkind, Y., Mooi, H., Bakker, H., Verbraeck, A., 2011. Grasping project complexity in large
engineering projects: The TOE (Technical, Organizational and Environmental) framework. International
Journal of Project Management, 29 (6), Pages 728-739.
Bresnen, M., Marshall, N., 2002. The engineering or evolution of co-operation? A tale of two partnering
projects. International Journal of Project Management, 20 (7), 497-505.
Bubshait, A.A., 2003. Incentive/ disincentive contracts and its effects on industrial projects. International
Journal of Project Management, 21 (1), 63-70.
Chan, A.P.C., Chan, D.W.M., Chiang, Y.H., Tang, B.S., Chan, E.H.W., Ho, K.S.K., 2004. Exploring critical success
factors for partnering in construction projects. Journal of Construction Engineering and Management,
130 (2), 188-198.
Chan, P.W., Johansen, E., Moor, R., 2012. Partnering paradoxes - A case of constructing inter-organisational
collaborations in infrastructure projects. Project Perspectives 2012, XXXIII, 28-33.
Cheung, S.O., Yiu, K.T.W., Chim, P.S., 2006. How relational are construction contracts? Journal of Professional
Issues in Engineering Education and Practice, 132 (1), 48-56.
Chin, W.W., 2010. How to write up and report PLS analyses, in: Vinzi, V.E., Chin, W.W., Henseler, J., Wang, H.S.
(Eds.), Handbook of Partial Least Squares: Concepts, Methods and Applications. Springer, Heidelberg,
Dordrecht, London, NewYork, pp. 655-690.
CII, 1986. Impact of Various Construction Contract Types and Clauses on Project Performance. Construction
Industry Institute.
Cowan, B., Davis, J., 2003. Relationship contracting: What is it and where is it going? Southern Pacific Alliance
Network.
Davis, P.R., Walker, D.H.T., 2008. Trust, commitment and mutual goals in Australian construction industry
project alliances, in: Walker, D.H.T., Rowlinson, S. (Eds.), Procurement System: A cross-industry project
management perspective. Taylor & Francis, Abingdon, pp. 378-399.
Drexler, J.A., Larson, E.W., 2000. Partnering: Why project owner-contractor relationships change. Journal of
Construction Engineering and Management, 126 (4), 293-297.
ECI, 2003. Long-term Partnering: Achieving continuous improvement and value. European Construction
Insititute, Loughborough, UK.
Faems, D., Looy, B.V., Janssens, M., Vlaar, P.W.L., 2012. The process of value realization in asymmetric new
venture development alliances: Governing the transition from exploration to exploitation. Journal of
Engineering and Technology Management, 29 (4), 508–527.
Feller, J., Parhankangas, A., Smeds, R., Jaatinen, M., 2013. How companies learn to collaborate: Emergence of
improved inter-organizational processes in R&D alliances. Organization Studies, 34 (3), 313-343.
Gil, N., 2009. Developing cooperative project client-supplier relationships: How much to expect from relational
contracts? California Management Review, 51 (2), 144-169.
Gopal, A., Sivaramakrishnan, K., Krishnan, M.S., Mukhopadhyay, T., 2003. Contracts in offshore software
development: An empirical analysis. Management Science, 49 (12), 1671-1683

172 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

Green, R., 2003. Measuring goodwill trust between groups of people: three years of an oil industry alliance.
Strategic Change, 12, 367-379.
Gulati, R., 1995. Does familiarity breed trust? The implications of repeated ties for contractual choice in
alliances. Academy of Management Journal, 38 (1), 85-112.
Hair, J.F., Sarstedt, M., Pieper, T.M., Ringle, C.M., 2012. Applications of partial least squares path modeling in
management journals: A review of past practices and recommendations for future applications. Long
Range Planning, 45 (5-6), 320-340.
Hair, J.F., Hult, G.T.M., Ringle, C.M., Sarstedt, M., 2013a. A Primer on Partial Least Squares Structural Equation
Modeling (PLS-SEM). Sage, Thousand Oaks.
Hair, J.F., Ringle, C.M., Sarstedt, M., 2013b. Partial least squares structural equation modeling: rigorous
applications, better results and higher acceptance. Long Range Planning, 46 (1-2), 1-12.
Hair., J.F., Black, W.C., Babin, B.J., Anderson, R.E., 2010. Multivariate Data Analysis. A Global Perspective, 7th
ed. Pearson Prentice Hall, Upper Saddle River, New Jersey.
Hamilton, B.H., Nickerson, J.A., 2003. Correcting for endogeneity in strategic management research. Strategic
Organization, 1 (1), 51-78.
Harman, H.H., 1976. Modern Factor Analysis. University of Chicago Press, Chicago.
Hartmann, A., Bresnen, M., 2011. The emergence of partnering in construction practice: an activity theory
perspective. Engineering Project Organization Journal, 1 (1), 41-52.
Hayes, A.F., 2013. Introduction to Mediation, Moderation, and Conditional Process Analysis. The Guilford Press,
New York.
Hayes, A.F., Preacher, K.J., 2014. Statistical mediation analysis with a multicategorical independent variable.
British Journal of Mathematical and Statistical Psychology, 67 (3), 451-470.
Heckman, J.J., 1976. The common structure of statistical models of truncation, sample selection and limited
dependent variables and a simple estimator for such models. Annals of Economic and Social
Measurement, 5 (4), 475-492.
Heckman, J.J., 1979. Sample selection bias as a specification error. Econometrica, 47 (153-161).
Henseler, J., Ringle, C.M., Sinkovics, R.R., 2009. The use of partial least squares path modeling in international
marketing, in: Sinkovics, R.R., Ghauri, P.N. (Eds.), Advances in International Marketing. Emerald Bingley,
pp. 277-320.
Henseler, J., Sarstedt, M., 2012. Goodness-of-fit indices for partial least squares path modeling. Computational
Statistics, 28 (2), 565-580.
Herten, H.J., Peeters, W.A.R., 1986. Incentive contracting as a project management tool. International Journal
of Project Management, 4 (1), 34-39
Hoegl, M., Gemuenden, H.G., 2001. Teamwork quality and the success of innovative projects: A theoretical
concept and empirical evidence. Organization Science, 12 (4), 435-449.
Hoegl, M., Weinkauf, K., Gemuenden, H.G., 2004. Interteam coordination, project commitment, and teamwork
in multiteam R&D projects: A longitudinal study. Organization Science, 15, 38-55.
Hoegl, M., Parboteeah, K.P., 2007. Creativity in innovative projects: How teamwork matters. Journal of
Engineering and Technology Management, 24, 148-166.
IPA, 2010. Contracting in the changing world of projects. The IPA Institute, pp. 1-46.
Laan, A., Voordijk, H., Dewulf, G., 2011. Reducing opportunistic behaviour through a project alliance.
International Journal of Managing Projects in Business, 4 (4), 660 - 679.
Larson, E., 1995. Project Partnering: results of study of 280 construction projects. Journal of Management in
Engineering, 11 (2), 30-35.
Lau, E., Rowlinson, S., 2011. The implications of trust in relationships in managing construction projects.
International Journal of Managing Projects in Business, 4 (4), 633 - 659.
Lee, L.F., 1983. Generalized econometric models with selectivity. Econometrica, 51, 507-513.
Lindner, J.R., Murphy, T.H., Briers, G.E., 2001. Handling nonresponse in social science research. Journal of
Agricultural Education, 42 (4), 43-53.
Little, R.J.A., Rubin, D.B., 2002. Statistical Analysis with Missing Data. John Wiley & Sons, New Jersey.
Lowe, D., 2007. Contract Management, in: Morris, P.W.G., Pinto, J.K. (Eds.), The Wiley Guide to Project
Technology, Supply Chain, and Procurement Management (The Wiley Guides to the Management of
Projects). John Wiley & Sons, Inc., Hoboken, New Jersey, pp. 317-346.
Lui, S.S., Ngo, H.-y., 2004. The role of trust and contractual safeguards on cooperation in non-equity alliances.
Journal of Management, 30 (4), 471-485.
Macbeth, D.K., 1994. The role of purchasing in a partnering relationship. European Journal of Purchasing &
Supply Management, 1 (1), 19-25.

Collaborative contracting in projects 173


Chapter 6

McLennan, A., Scott, G., 2002. Relationships in project delivery, Civil Contractors Federation 2002 Annual
Conference. Civil Contractor Federation, Hamilton Island, Australia.
Meng, X., 2011. The effect of relationship management on project performance in construction. International
Journal of Project Management, doi:10.1016/j.ijproman.2011.04.002.
Meng, X., Gallagher, B., 2012. The impact of incentive mechanisms on project performance. International
Journal of Project Management, 30 (3), 352-362.
Merrow, E.W., 2011. Industrial Megaprojects: Concepts, Strategies, and Practices for Success John Wiley &
Sons, Inc., Hoboken, New Jersey.
Miller, R., Lessard, D.R., 2000. The Strategic Management of Large Engineering Projects: Shaping Institutions,
Risks, and Governance. Massachusetts Institute of Technology, Cambridge, USA.
Morris, P.W.G., Pinto, J.K., 2007. The Wiley Guide to Project Technology, Supply Chain, and Procurement
Management (The Wiley Guides to the Management of Projects). John Wiley & Sons, Inc., Hoboken,
New Jersey.
Müller, R., Turner, J.R., 2005. The impact of principal–agent relationship and contract type on communication
between project owner and manager. International Journal of Project Management, 23, 398-403.
Naoum, S., 2003. An overview into the concept of partnering. International Journal of Project Management, 21
(1), 71-76.
Ng, S.T., Rose, T.M., Mak, M., Chen, S.E., 2002. Problematic issues associated with project partnering -- the
contractor perspective. International Journal of Project Management, 20 (6), 437-449.
Parker, D., Hartley, K., 1997. The economics of partnership sourcing versus adversarial competition: a critique.
European Journal of Purchasing & Supply Management, 3 (2), 115-125.
Pinto, J.K., Slevin, D.P., English, B., 2009. Trust in projects: an empirical assessment of owner/contractor
relationships. International Journal of Project Management, 27 (6), 638-648.
PMI, 2008. A guide to the Project Management Book of Knowledge (PMBoK guide) - Fourth ed. Project
Management Institute, Inc., Pennsylvania.
Podsakoff, N.P., Organ, D.W., 1986. Self-report in organizational research: problems and prospects. Journal of
Management, 12 (4), 531-544.
Podsakoff, P.M., MacKenzie, S.B., Lee, J.Y., Podsakoff, N.P., 2003. Common method biases in behavioral
research: A critical review of the literature and recommended remedies. Journal of Applied Psychology,
88, 879-903.
Poppo, L., Zhou, K.Z., Ryu, S., 2008. Alternative origins to interorganizational trust: an interdependence
perspective on the shadow of the past and the shadow of the future Organization Science, 19 (1), 39-55.
Rahman, M.M., Kumaraswamy, M.M., 2008. Relational contracting and teambuilding: Assessing potential
contractual and noncontractual incentives. Journal of Management in Engineering, 24, 48-63.
Reinartz, W.J., Haenlein, M., Henseler, J., 2009. An empirical comparison of the efficacy of covariance-based
and variance-based SEM. International Journal of Research in Marketing, 26 (4), 332-344.
Richardson, H.A., Simmering, M.J., Sturman, M.C., 2009. A tale of three perspectives: Examining post hoc
statistical techniques for detection and correction of common method variance. Organizational
Research Methods, 12, 762-800.
Rigdon, E.E., Ringle, C.M., Sarstedt, M., 2010. Structural modeling of heterogeneous data with partial least
squares, in: Malhotra, N.K. (Ed.), Review of Marketing Research. Sharpe, Armonk, pp. 255-296.
Ringle, C.M., Wende, S., Will, S., 2005. SmartPLS 2.0 (M3) Beta. http://www.smartpls.de, Hamburg.
Ringle, C.M., Götz, O., Wetzels, M., Wilson, B., 2009. On the use of formative measurement specifications in
structural equation modeling: A monte carlo simulation study to compare covariance-based and partial
least squares model estimation methodologies, METEOR Research Memoranda (RM/09/014).
Maastricht University.
Rönkkö, M., Ylitalo, J., 2011. PLS marker variable approach to diagnosing and controlling for method variance,
ICIS 2011 Proceedings, Shanghai.
Ross, J., 2003. Introduction to project alliancing: on engineering and construction projects, Alliance Contracting
Conference, 30 April 2003. PCI Alliance, Sydney, pp. 1-42.
Salas, E., Sims, D.E., Burke, C.S., 2005. Is there a ''Big Five'' in teamwork? Small Group Research, 36 (5), 555-
599.
Sanderson, J., 2012. Risk, uncertainty and governance in megaprojects: A critical discussion of alternative
explanations. International Journal of Project Management, 30 (4), 432-443.
Scott, B., 2001. Partnering in Europe: Incentive Based Alliancing for Projects. Thomas Telford, London.
Silva, S.C.e., Bradley, F., Sousa, C.M.P., 2012. Empirical test of the trust–performance link in an international
alliances context International Business Review, 21 (2), 293-306.

174 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

Smith, N.J., 2002. Engineering Project Management. Blakwell Science Ltd., Oxford.
Smyth, H., Edkins, A., 2007. Relationship management in the management of PFI/PPP projects in the UK.
International Journal of Project Management, 25 (3), 232-240.
Smyth, H., Pryke, S., 2008. Managing collaborative relationships and the management of projects, in: Smyth, H.,
Pryke, S. (Eds.), Collaborative Relationships in Construction: developing frameworks and networks.
Blackwell Publishing Ltd, West Sussex, pp. 1-23.
Smyth, H., Gustafsson, M., Ganskau, E., 2010. The value of trust in project business. International Journal of
Project Management, 28 (2), 117-129.
Suprapto, M., Bakker, H.L.M., Mooi, H.G., 2015a. Relational factors in owner–contractor collaboration: The
mediating role of teamworking. International Journal of Project Management, 33 (6), 1347–1363.
Suprapto, M., Bakker, H.L.M., Mooi, H.G., Moree, W., 2015b. Sorting out the essence of owner-contractor
collaboration in capital projects delivery. International Journal of Project Management, 33 (3), 664-683.
Thomas, G., Thomas, M., 2005. Construction Partnering & Integrated Teamworking. Blackwell Publishing Ltd,
Oxford.
Thompson, P.J., Sanders, S.R., 1998. Partnering continuum. Journal of Management in Engineering, 14 (5), 73-
78.
Turner, J.R., Simister, S.J., 2001. Project contract management and a theory of organization. International
Journal of Project Management, 19 (8), 457-464.
Turner, J.R., 2003. Contracting for Project Management. Gower Publishing Limited, Hampshire.
Turner, J.R., 2009. The Handbook of Project-based Management: Leading Strategic Change in Organizations -
3rd ed., 3rd ed. The McGraw-Hill Companies, Inc.
Walker, D.H.T., Hampson, K., 2003. Enterprise networks, partnering and alliancing, in: Walker, D.H.T.,
Hampson, K. (Eds.), Procurement Strategies: A Relationship-based Approach. Blackwell Science, Malden,
pp. 30-73.
Walker, D.H.T., Rowlinson, S., 2008. Project types and their procurement needs, in: Walker, D.H.T., Rowlinson,
S. (Eds.), Procurement System: A cross-industry project management perspective. Taylor & Francis,
Abingdon, pp. 32-69.
Walker, D.H.T., Lloyd-Walker, B.M., 2015. Collaborative Project Procurement Arrangements. Project
Management Institute, Newtown Square, PA.
Williams, L.J., Hartman, N., Cavazotte, F., 2010. Method variance and marker variables: A review and
comprehensive CFA marker technique. Organizational Research Methods, 13 (3), 477-514.
Winch, G.M., Maytorena, E., 2011. Managing risk and uncertainty on projects: A cognitive approach, in: Morris,
P.W.G., Pinto, J.K., Söderlund, J. (Eds.), The Oxford Handbook of Project Management. Oxford University
Press, Oxford, pp. 345-364.
Young, R., Poon, S., 2013. Top management support—almost always necessary and sometimes sufficient for
success: Findings from a fuzzy set analysis. International Journal of Project Management, 31 (7), 943-
957.
Zaheer, A., McEvily, B., Perrone, V., 1998. Does trust matter? Exploring the effects of interorganizational and
interpersonal trust on performance. Organization Science, 9 (2), 141-159.

Collaborative contracting in projects 175


Chapter 6

Appendix 6-1. Measurement model specification


Constructs/ Indicators Loadings AVE CR α
a
1. Project performance (formative construct) - - -
Weighted average of schedule, cost, quality, safety, and operability 0.804 Weight = 0.421, p<0.01
This project made a positive impact on the owner’s business 0.593 Weight = 0.119, ns
This project was a commercial success to the contractor 0.787 Weight = 0.389, p<0.01
Both owner and contractor were satisfied about the project outcomes 0.855 Weight = 0.334, ns
nd
2. Relational attitudes (2 -order formative construct)
2.1. Senior management commitment (1st-order reflective construct) 0.732 0.891 0.817
Senior management committed to provide necessary resources and 0.843
support
Senior management shown consistent and passionate leadership 0.896
Senior management actively resolved potential conflicts when 0.826
needed
2.2. Relational norms (1st-order reflective construct) 0.671 0.911 0.877
The contractor was enthusiastic in achieving the owner’s objectives 0.773
The contractor felt confident that owner is reliable and trustworthy 0.843
The owner believed the contractor made its best efforts 0.876
Both parties adopted ‘no blame culture’ whenever problems arise 0.830
Both parties intentionally being open and honest in any interactions 0.769
3. Teamworking Quality (2nd-order formative construct)
3.1. Communication (1st-order reflective construct) 0.690 0.898 0.849
Both teams communicated directly with each other 0.707
Project-relevant information was shared openly by both teams 0.882
Whenever a problem is detected, it was immediately communicated 0.870
Both teams were satisfied with the usefulness of the information 0.850
shared
3.2. Coordination (1st-order reflective construct) 0.689 0.898 0.848
The work done on tasks within the project was synchronized 0.810
There were comprehended goals for tasks between the teams 0.872
The goals for tasks were accepted by both teams 0.863
There was no conflict between the teams regarding tasks and goals 0.771
3.3. Cohesion (1st-order reflective construct) 0.631 0.872 0.805
Core team-members were personally engaged to this project 0.819
Core team-members were integrated as one team 0.731
Core team-members felt proud to be part of the teams 0.844
Core team-members felt responsible for maintaining relationships 0.779
3.4. Balanced contribution (1st-order reflective construct) 0.716 0.883 0.802
Both teams recognized each other's specific strengths/weaknesses 0.816
Both teams contributed in accordance with their specific potential 0.857
There were balanced contributions that prevented conflicts 0.865
3.5. Mutual support (1st-order reflective construct) 0.694 0.872 0.779
Both teams supported each other as best as they could 0.872
Whenever problems occurred, they were resolved constructively 0.850
Every critical decision was made jointly by both teams 0.774
3.6. Aligned effort (1st-order reflective construct) 0.738 0.894 0.823
Every team made this project their highest priority 0.872
Both teams put their best effort into this project 0.883
There was no conflict regarding the effort that one team put into 0.822

176 Collaborative contracting in projects


How do contract types and incentives matter to project performance?

Appendix 6-1. Measurement model specifications (continuation)


Constructs/ Indicators Loadings AVE CR α
3.7. Affective trust (1st-order reflective construct) 0.635 0.913 0.885
Both teams were comfortable being dependent on each other 0.736
Both teams had kept their promises 0.778
Both teams had high levels of integrity 0.829
Both teams had been fair to each other 0.855
Both teams had looked out for each other companies’ interests 0.797
Both teams could rely on each other to not taking advantage 0.781
4. Front-end definition (reflective construct) 0.624 0.869 0.802
Clarity of the project goals and objectives 0.796
Clarity of the project scope 0.781
Quality of the project basic engineering design 0.754
Quality of the project execution plan 0.827
5. Project size (reflective construct) 0.767 0.868 0.708
Total installed cost 0.926
Project duration 0.823
6. Firm size (reflective construct) 0.898 0.946 0.890
Number of employees 0.965
Annual revenues 0.930
a
Note: AVE = average variance extracted; CR = composite reliability; α = Cronbachs alpha; Formative construct,
each indicator is retained if the weight is significant or the loading above the threshold 0.5; all loadings are
significant at p < 0.001; ns = not significant.

Collaborative contracting in projects 177


Appendix 6-2. Constructs intercorrelations and discriminant validity

178
Latent Construct Mean SD 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Chapter 6

Senior management commitment 1 3.74 0.77 0.86


Relational norms 2 3.67 0.75 0.55 0.82
a
Relational attitudes (M1) 3 3.70 0.67 0.78 0.95 N/A
Communication 4 3.83 0.70 0.45 0.58 0.61 0.83
Coordination 5 3.64 0.76 0.47 0.56 0.59 0.68 0.83
Cohesion 6 3.62 0.69 0.49 0.64 0.66 0.61 0.62 0.80
Balanced contribution 7 3.53 0.65 0.48 0.60 0.63 0.63 0.65 0.66 0.85
Aligned effort 8 3.61 0.74 0.51 0.50 0.57 0.50 0.55 0.60 0.54 0.86
Mutual support 9 3.70 0.74 0.44 0.63 0.63 0.63 0.65 0.61 0.66 0.67 0.83
Affective trust 10 3.52 0.68 0.49 0.73 0.73 0.63 0.65 0.73 0.71 0.63 0.76 0.80
a
Teamworking quality (M2) 11 3.62 0.59 0.57 0.74 0.76 0.81 0.83 0.83 0.82 0.75 0.85 0.90 N/A
Front-end definition 12 3.55 0.75 0.47 0.46 0.52 0.44 0.48 0.37 0.44 0.31 0.44 0.50 0.52 0.79
Project size 13 4.09 1.62 0.18 -0.04 0.04 0.02 0.02 0.12 0.02 0.20 -0.08 -0.10 0.01 -0.06 0.88
Firm size 14 3.62 1.40 0.12 0.09 0.11 0.23 0.19 0.17 0.18 0.12 0.19 0.20 0.22 0.02 0.30 0.95
c
Prior relationship duration 15 8.76 9.97 0.04 0.17 0.14 0.14 0.17 0.09 0.14 0.10 0.12 0.19 0.17 0.12 0.02 0.02 N/A
c
Early contractor involvement 16 0.66 0.48 0.19 0.31 0.30 0.22 0.27 0.39 0.31 0.39 0.28 0.36 0.38 0.25 0.11 0.16 0.15 N/A
c
PAL vs. RE (D1) 17 0.34 0.48 0.00 0.07 0.05 0.12 0.17 0.12 0.09 0.05 0.19 0.15 0.16 -0.08 -0.08 0.06 0.18 0.17 N/A
c
PAL vs. LS (D2) 18 0.54 0.50 0.06 0.10 0.09 0.01 -0.02 0.03 0.04 -0.02 -0.04 -0.04 -0.01 0.16 -0.07 -0.01 -0.19 -0.07 -0.77 N/A
c
Contractual incentive (X2) 19 0.37 0.49 0.24 0.19 0.23 0.15 0.18 0.22 0.08 0.22 0.10 0.16 0.19 0.09 0.13 0.13 0.14 0.20 0.17 -0.15 N/A
b
Project performance (Y) 20 3.40 0.73 0.29 0.54 0.51 0.52 0.51 0.45 0.40 0.42 0.55 0.56 0.60 0.62 -0.08 0.13 0.03 0.16 0.02 0.10 -0.01 N/A

Note: N = 113; values below diagonal (in italics) are correlations; values on diagonal (in bold) are the square root of average variance extracted (AVE), not applicable
a b c
(N/A) for higher-order formative construct, formative construct, and single item construct; PAL = Partnering/alliance contract; RE = reimbursable contract; LS =
lump-sum contract.

Collaborative contracting in projects


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 7 ! overview
This chapter discusses the front-end development phase(s). First, it is explained why focus on the
early project phases is so important and what the front-end phase actually entails. Subsequently,
it is questioned whether we could approach all projects in the same manner. Given one of the
two main themes of this book (fit-for-purpose), this is obviously not the case. Project complex-
ity is introduced as one of the variables on which you can adapt your project management
approach. What are Value Improving Practices (VIPs) and what matters most in applying VIPs is
discussed in the next paragraph. Here the second theme of the book (a people process) is clearly
recognised. How to further develop project performance is discussed next, on the basis of the
VIPs Benchmarking and Lessons Learnt that have their origins in the front-end phases. This chap-
ter is concluded with some particularly interesting (new) focus areas in front-end development:
safety and sustainability. Lifecycle thinking and how this connects to front-end development is
also elaborated in this paragraph.

Chapter 7 ! outline
7.1 Why focusing on front-end?
7.2 What does the front-end phase entail?
7.3 Project complexity
7.4 Value Improving Practices
7.5 Developing performance
7.6 New focus areas
7.7 The Wind Farm

118

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

Chapter 7
Front-end development 1

by Marian Bosch-Rekveldt

7.1 ! Why focusing on the front-end?


Think before you act. It is essential and may sound simple, but it proves to be rather difficult.
In essence this is what front-end development is about: preparing the future project phases.
Various books and articles show how the front-end development phase matters to the project
performance (Bosch-Rekveldt, 2011; Flyvbjerg, Bruzelius, & Rothengatter, 2003; Merrow, 2011;
Morris, 1994; Van der Weijde, 2008).

What is the goal of front-end development (FED)? As summarised in Bosch-Rekveldt, 2011: ‘The
main goal of FED is to provide owner representatives with a sufficiently complete image of the pro-
ject to enable them to decide whether or not the project is worth investing resources in’ (p. 24/25).
In the front-end phase, the image of the project is created, starting with the business needs that
have led to the initiation of the project and the way to meet these needs. This image also includes
objectives, setting the scope, design basis, project planning, required resources and risks involved.
How value is developed during the different project stages is shown in Figure 7.1.

Value realisation
Good Project
Execution
A

B
Poor Project
Value Execution

Phase 1 Phase 2 Phase 4 Phase 5


Identify Select Execute Operate
and assess

Figure 7.1: The influence of front-end development (Phase 1, 2, 3) on the value of a project according to
the oil and gas industry

1 This chapter draws upon the PhD thesis by the author of this chapter, (Bosch-Rekveldt, 2011)

119

925836-02_137_17-Feb-15_08:42:09_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

Figure 7.1 shows that value that is not created during the front-end project phases cannot be
recovered during execution. In other words: optimal project value is achieved with good project
definition and execution, where good definition is regarded as most essential. Good definition is
the enabler for good project execution: realisation follows identification. For the extremes (indi-
cated with A and D in Figure 7.1.) this seems reasonably true. The final performance of project B,
however, might also be lower than the performance of project C in case of a total failure in the
execution of B.

Although this chapter deals particularly with the front-end phases of projects, what then could
be causing failure in the process of project execution? To mention a few examples, think of:
• Geographical location (more remote, drives modularisation)
• Controlling safety with fewer sophisticated labour forces
• Distributed execution centres (shifting work to low-wage countries)
• Operating 24/7 (stressed time-zones from Asia to North America).

Value management or value engineering particularly focuses on value development throughout


the project, see for example the DACE website (www.dace.nl/value-management).

7.2 ! What does the front-end phase entail?


In most companies nowadays, a stage-gated project management approach is implemented
throughout the project lifecycle. It is recommended to implement formal stage gates to mark the
different phases through which the project is defined more precisely (McGee, DeFoe, Robertson,
& McConnell, 1999; Turner, 2008). Such a structured stage-gated project management process
is assumed to ensure that the right steps in the process of generating the information that is
required at the final investment decision (FID) are taken in the right order. In other words: a struc-
tured process is followed to make sure that the right information is available at the right moment.
As the project matures, uncertainties are likely to be reduced and it is important to reconsider
if the right project is undertaken in the right way. If some aspects of the project are not well
developed, this can be resolved before expenses have been made in areas that build upon this
aspect. And, most important: projects that do not meet the capital investment requirements or
that do not have a fit with the desired portfolio can be filtered out at the gates.

Each of the front-end development phases builds upon the previous front-end phase and pre-
pares for the next stage gate. The typical front-end development phases, in the process industry
for example indicated with front-end development phase 1, 2 and 3 (FED1, FED2, FED3) are named
differently in literature, see Table 7.1 (and also Chapter 1).

In the front-end development phases, a clear scope that optimally suits the project objectives
needs to be developed. The scope is preferably frozen (as much as possible) early in the project,
ultimately when the final investment decision is taken (Love, Holt, Shen, Li, & Irani, 2002). Note
however that new, important inputs from the business perspective should not be discarded by
definition. In case of very high-tech projects, a certain percentage of unidentified scope might be
accepted and seen as a given for the project.

120

925836-02_138_17-Feb-15_12:16:21_walter
the scene and money at work

Table 7.1: Names for typical FED phases (Bosch-Rekveldt, 2011)

Source FED1 FED2 FED3

(Turner, 2008) Concept Feasibility Design

(Morris & Hough, 1987) Prefeasibility Feasibility Design

(De Groen, Dhillon, Kerkhoven, Janssen, &


Define business Do conceptual Do basic
Bout, 2003; Oosterhuis, Pang, Oostwegel, &
case design engineering
De Kleijn, 2008)

(IPA, 2009) Appraise Select Define

Identify and
Oil & Gas industry Select Define
assess

Note that a plea for the opposite of early scope freeze, flexible and resilient projects, was observed
in recent literature (Priemus, Bosch-Rekveldt, & Giezen, 2013). The idea is to develop (mega)pro-
jects that can cope with changing circumstances, for example by keeping options open as long
as possible and developing different parallel alternatives. Also recent developments from ICT
management agile project management or SCRUM methods, (Chow & Cao, 2008) seem bet-
ter able to flexibly deal with changing circumstances, although the performance figures of ICT
projects are often disappointing so far (Van Dijk, White, & Comley, 2013). For the scope of this
chapter, however, primarily the concept of early scope freeze is adopted.
For each of the FED phases, suggested key deliverables and key activities are determined; see
Table 7.2 for an example from the process industry. These key deliverables and key activities
together comprise the ‘standard’ front-end activities in the process industry.

Can parallels to other industries be drawn? The majority of the activities in Table 7.2 can be found
in project management handbooks such as PMBoK (PMI, 2008), APM (APM), The Gower Handbook
of project management (Turner, 2014) or can be recognised in standard project management
methods including PRINCE2 (Murray, 2009); ICB (IPMA, 2003), etc. See also the introduction
chapter of this book on general definitions of and developments in project management. Note
the strong influence of systems engineering in current project management methods, through-
out. To some basic level, the majority of the activities seem universally applicable.

An important question that arises is to what extent one should perform all possible activities in
a project, regardless of the project’s characteristics. Compare a multibillion greenfield initiative
with a small product development project. Could or should the front-end approach be the same?
Projects are by definition unique. How can a universal approach ever be adopted? Rather, a
contingency approach is proposed, in which the management approach is adjusted to specific
variables or project characteristics (Bosch-Rekveldt, 2011; Howell, Windahl, & Seidel, 2010; Sauser,
Reilly, & Shenhar, 2009; Shenhar, 2001). In the next paragraph, project complexity is considered a
factor based on which the front-end development phase can be adapted.

121

925836-02_139_17-Feb-15_08:42:12_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

Table 7.2: Standard recommended front-end activities in the process industry (Bosch-Rekveldt, 2011): Key
deliverables and key activities in the different FED phases, based upon (Oosterhuis et al., 2008)

Key activities Key deliverables

FED1

Translate business objectives into required Business goals


project performance Project objectives
Preliminary cost and revenue assessment Requirements on project premises
Prepare level 1 schedule Front-end loading strategy
Analyse safety issues Cost estimate (± 40 %)
Risk identification and management WBS level 1 schedule
Determine contract strategy Initial Hazard and Operability study (HAZOP)
Feedback to and from stakeholders Risk register
Plan the FED phases Contracting strategy
Set up the FED organisation Technology review
Project execution plan (incl. human factors, alliances,
benchmarking, innovation)

FED2

Define the scope Evaluation report stage gate previous phase


Select the site Basis of design
Select technology Process design basis
Define main equipment Cost estimate (± 20 %)
Identify critical unit operations WBS level 2 schedule
Cost and revenue assessment Update HAZOP
Prepare level 2 schedule Update risk register
Analyse safety issues Project execution plan (incl. human factors, alliances,
Risk identification and management benchmarking, innovation)
Compose the project team

FED3

Basic engineering Evaluation report stage gate previous phase


Cost and revenue assessment Basic design engineering package
Prepare level 3 schedule Cost estimate (± 10 %)
Analyse safety issues WBS level 3 schedule
Risk identification and management Update HAZOP
Define project funding strategy Update risk register
Prepare the contracting plan Project implementation plan
Define project strategic interfaces Execution schedule
Team building

122

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

7.3 ! Project complexity


In the 2000s project complexity was assumed to be the cause of lots of management problems
in (large) engineering projects (Neleman, 2006; Williams, 2005). Project complexity was often not
well understood or underestimated, while projects at the same time were (and are!) becoming
increasingly complex. What this complexity actually comprised of, was unclear. Research was
undertaken to improve the understanding of project complexity (Bosch-Rekveldt, 2011; Geraldi,
2009; van der Lei, Kolfschoten, & Beers, 2010; Vidal & Marle, 2008); or to attempt to, after under-
standing project complexity, even play with the project’s complexity (Hertogh & Westerveld,
2010; Bosch-Rekveldt, Jongkind, Bakker, Mooi, & Verbraeck, 2011).

One of the research results was the TOE (Technical, Organisational, External) framework to grasp
project complexity (Bosch-Rekveldt, 2011), see Figure 7.2. The TOE framework distinguishes
47 potential complexity sources that are clustered in the three categories T, O and E. It can provide

Technical Complexity (17 elements) Organizational Complexity (17 elements)


• High number of project goals • High project schedule drive
• Non−alignment of project goals • Lack of Resource & Skills availability
• Unclarity of project goals • Lack of Experience with parties involved
• Uncertainties in scope • Lack of HSSE awareness
• Strict quality requirements • Interfaces between different disciplines
• Project duration • Number of financial sources
• Size in CAPEX • Number of contracts
• Number of locations • Type of contract
• Newness of technology (world−wide) • Number of different nationalities
• Lack of experience with technology • Number of different languages
• High number of tasks • Presence of JV partner
• High variety of tasks • Involvement of different time zones
• Dependencies between tasks • Size of project team
• Uncertainty in methods • Incompatibility between different pm methods /tools
• Involvement of different technical disciplines • Lack of trust in project team
• Conflicting norms and standards • Lack of trust in contractor
• Technical risks • Organizational risks

External Complexity (13 elements)


• External risks
• Number of external stakeholders
• Variety of external stakeholders’ perspectives
• Dependencies on external stakeholders
• Political influence
• Lack of company internal support
• Required local content
• Interference with existing site
• Remoteness of location
• Lack of experience in the country
• Company internal strategic pressure
• Instability of project environment
• Level of competition

Figure 7.2: TOE framework to grasp project complexity (Bosch-Rekveldt, 2011)

123

925836-02_141_17-Feb-15_08:42:18_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

a ‘complexity footprint’ of a project. In several industries (process industry, construction industry,


ICT and high-tech product development), it was investigated which elements mostly determine
the complexity of a project. From a comparative study (Bosch-Rekveldt, Hertogh, Bakker, & Mooi,
submitted), some complexities seem to appear ‘universally’ in projects throughout the different
sectors, for example high pressure on the project’s schedule and the involvement of (a lot of)
external stakeholders with very different perspectives. In the comparative study, other elements
of the TOE framework appeared only in one sector, like the long duration of projects in the
construction industry, the high technical risks in projects in the high-end product development
industry and uncertainties in the project goals and un-alignment of these goals in projects in the
process industry.

Based on the expected project complexities, the additional effort in specific front-end activities
could be determined. For example, in the earlier mentioned research in the process industry
(Bosch-Rekveldt, 2011) it was found that in case of a technically complex project, specific atten-
tion could be paid to goal setting, alignment and monitoring, risk management, and timely
involvement of the stakeholders. In case of an organisationally complex project, specific atten-
tion could be paid to goal setting and alignment, timely involvement of the stakeholders and
teambuilding. In case of a project with expected external complexity, specific attention could
be paid to risk management and, again, teambuilding. For other projects with different (com-
binations of) complexities, another set of activities could be highly beneficial; this is a topic of
on-going research. These specific front-end activities are known as Value Improving Practices,
which are further explained in the next paragraph.

Note that project complexity as such is highly dynamic and subjective: it will evolve throughout
the different phases of the project and is heavily based on prior experiences and knowledge.
What is considered as very complex by one practitioner could be perceived as very simple by
others. Being aware of each other’s complexity perspectives turned out an eye-opener in recent
research (Kool, Bosch-Rekveldt, Hertogh, & Kraneveld, 2014).

How fit for purpose project management then could look like in practice, is, again, topic of on-go-
ing research. Complexity could be a selection criterion to decide what management activities to
undertake in order to manage the project ‘fit for purpose’, but also other project characteristics
could be made decisive. The fundamental difficulty and even tension is that fit for purpose pro-
ject management, by definition, is adapted to the specific project context and hence cannot
be simply generalised. Probably this is where the people aspect comes across: an experienced
project manager is able to make the right decisions about fit-for-purpose project management, if
there is freedom to take these decisions.

7.4 ! Value Improving Practices


In case a company has a project management system in place, key deliverables and key activities
will be similar to those presented in Table 7.2. Next to these ‘standard’ front-end activities, also
so-called Value Improving Practices can be applied. Value Improving Practices (VIPs) are the ‘out
of the ordinary activities’ that provide input and add value to the standard activities and delivera-
bles (IPA, 2014). VIPs could be seen as the normal practices of the (near) future.

124

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

Because of the special nature of VIPs, IPA recommends to facilitate the execution of these prac-
tices by a person external to the project team, who possesses the skills to maximise the outputs
that can be gained (IPA, 2014). Despite IPA’s own interest in external facilitation, external facili-
tation could indeed add value because of the ‘fresh’ external view. VIPs would be best suited for
application in the front-end phase of a project, to maximise the value that is created (De Groen
et al., 2003).
Different organisations have developed lists of value improving practices, sometimes confusingly
also referred to as best practices, see Table 7.3. These organisations only list those practices for
which they have gained evidence that indeed the practice adds value to projects. They however
use different datasets (not publicly available), which explains the differences between the lists.

Table 7.3: Value Improving Practices as identified by IPA and CII

IPA VIP’s (IPA, 2014) CII Best practices (CII, 2014)

Strategic Business Objectives Alignment


Technology selection Benchmarking and metrics
Classes of facility quality Change management
Constructability
Capital cost (Scope) Dispute prevention and resolution
Process simplification Front End Planning
Value engineering Implementation of CII research
Design-to-capacity Lessons learnt
Customizing standards and specifications Materials management
Partnering
Execution efficiency (Cost and Schedule) Planning for start-up
Constructability review Project Risk Assessment
3-D CAD Quality management
Teambuilding
Operating cost (Uptime, Utilities, Maintenance) Zero accidents Techniques
Process reliability modelling
Predictive maintenance
Energy optimisation
Waste minimisation

Several of the CII Best practices would better fit the base practices from Table 7.2, but most of
the proposed activities in Table 7.3 go beyond the important base practices like start with a good
project definition and implement project controls. Regardless of the specific content, the lists
have one thing in common: they only can add value if they are applied correctly and by the right,
competent, people (Chapter 4). In earlier research, the application of VIPs in engineering projects
was investigated (Bosch-Rekveldt, Smith, Mooi, Bakker, & Verbraeck, 2011). Results showed a wide
variety in the level of application of the VIPs. Specifically the way how VIPs were applied seemed
to make the difference for achieving good project performance.

Like one of the main themes of this book: it is all about the people involved. It seems that a
formal structure of performing VIPs, or best practices, is necessary, for example in company
work processes, but this is not necessarily sufficient to achieve a good project performance.

125

925836-02_143_17-Feb-15_08:42:21_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 keywords are integration and involvement. Integration refers to integration of the results of
different VIPs, integration of the different disciplines in a multidisciplinary team and integration
of the different parties involved, for example close collaboration between contractor and pro-
ject owner. Involvement refers to involvement of team members in the execution of the VIPs:
jointly setting project goals, jointly performing risk workshops, etc. Preferably, the same parties
(and even better: persons) are involved in the different phases of the project lifecycle, including
technical specialists and future users. Of course the specific needs, in terms of required skills and
knowledge in each project phase, should be carefully looked at.

Spending joint efforts in executing VIPs, with an integrated project team, enables the develop-
ment of trust within such an integrated project team. When working together, interpersonal
relations are built that can be helpful in solving problems later on. It is not only about the result
of applied VIPs, but also about the fact that joint awareness is created by performing a VIP with a
truly integrated project team.

Turner already stated: ‘To a large extent people are the key elements and yet so many books
concentrate on methods, tools and computing capability’ (Turner, 2003). People are the key in
projects. Still, formally and truly (e.g. not as ‘tick the boxes’ exercises) applying VIPs is beneficial
as these VIPs provide the guidance in performing activities that are relevant for achieving project
success. These lists of VIPs to some extent could be considered as ‘just’ checklists, but the people
factor then plays an important role in how the different VIPs are applied and how results of the
VIPs are implemented and integrated in the project. Integrated teams, in which the parties trust
each other, seem more open to share knowledge and seem more alert to anticipate on changes
in the highly dynamic and challenging project environment (Bosch-Rekveldt, Smith, et al., 2011).

So a formal structure of performing VIPs can be considered as a first step in professionalising


project management. Necessary, but not necessarily sufficient. What else, with origins in the
front-end phase, could help improve project performance?

7.5 ! Developing performance


This paragraph discusses two relevant activities that can take place in the early project phase and
which do have demonstrated positive influence on project performance. First, the ins and outs of
benchmarking are presented and second, the challenges and opportunities in applying lessons
learnt in early project phases are discussed.

7.5.1 Benchmarking
Benchmarking is widely applied in several industries. A study originating from the construction
industry reports that benchmarking can support project management, by learning from best
practices of others and by stimulation of continuous improvement within the organisation (Luu,
Kim, & Huynh, 2008). In the process industry, application of benchmarking is rather common
nowadays. Project owners might even oblige their contractors to show (external) benchmarking
results in their projects, in order to assure project performance. That is the idea of benchmarking:
looking where you are in terms of performance, compared to others in your company / sector /
industry / database of comparable projects. It is about introducing an external view on your pro-
ject in order to assess the performance throughout the project lifecycle.

126

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

There are different forms of benchmarking: internal benchmarking consisting of company-in-


ternal reviews and external benchmarking, in which another company or independent party is
involved in the review process. The ‘outside view’ in the case of internal benchmarking might
seem limited, but since a company is likely to perform comparable projects, still this can be
helpful in improving project performance: it opens the project for other views. Companies might
choose internal benchmarking because they are not willing to share their intellectual property or
competitive advantage with the outside world and the benchmarking company, they are afraid
of the additional effort external benchmarking requires and/or they simply do not want to spend
additional money on external benchmarking companies.

Some companies do not choose any form of benchmarking, because in their opinion their pro-
jects are unique and do not have any comparable counterparts. Nonsense, most often. Even
the most unique projects do have certain aspects or activities that are comparable to what has
happened in other projects. Still the value of benchmarking should exceed its cost in order to
be effective, hence small projects might not be a logical target group for external benchmark-
ing. Several commercial companies nowadays completely focus on performing benchmarks for
the industry, of which IPA2 is the most prominent example of such a company. Lessons learnt
from performing benchmarks during the last decades are widely discussed in the book Industrial
Megaprojects – Concepts, Strategies, and Practices for Success (Merrow, 2011). These lessons
learnt are a valuable result of their benchmarking activities.

The Construction Industry Institute (CII) has developed the Project Definition Rating Index (PDRI)
which can be used as a tool for measuring the degree of scope development during the front-
end development phases in industrial projects (Dumont, Gibson Jr, & Fish, 1997). Using the PDRI
by both clients and contractors, and preferably as a joint activity as was argued in the previous
paragraph as well, could ensure better awareness of quality and completeness of project scope
in early project phases.

From a case study, performed with five projects selected from companies active in the Dutch
NAP Network (Bosch-Rekveldt, Smith, et al., 2011), it was concluded that although application
of benchmarking at the time of research was relatively poor (in quantity and quality), exter-
nal benchmarking still showed potential to contribute to success of projects. Details about this
research are given below.

Case research into application of benchmarking (Bosch-Rekveldt, Smith, et al., 2011)


The application of certain Value Improving Practices (VIPs) in the Front End Development
(FED) phase of five engineering projects was investigated in-depth. One of the VIPs under
consideration was the VIP External Benchmarking. Semi-structured interviews were held
with 11 project managers and team members from 5 projects across different companies.
Each project was considered a case in a multiple-cases explanatory case study approach.
The cost estimates in these projects ranged in size between € 7 – 100 million.

2 IPA: Independent Project Analysis, Inc. www.ipaglobal.com/

127

925836-02_145_17-Feb-15_12:16:21_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

Although to some companies external benchmarking is an important tool to improve


themselves, it was substantially applied in only three of the five cases. And from these
three cases, only in one case it was directly contributing to improving the project results,
in view of the interviewees. In this case, the outcomes of the benchmarking study
were beneficially used to prepare optimally for execution in the later project phases. In
view of the interviewees, the external party, objectively assessing the project fitness,
contributed to the development of trust in this truly integrated project team. The project,
seen as the result of joint effort of contractor and owner, was objectively evaluated on
its performance by this external party. Another project case illustrated a more traditional
owner – contractor relation. Here the contractor did not see the value of applying
external benchmarking: it was applied simply because it was requested by the project
owner. In case of real integrated teams (not present in this project), more feedback of the
benchmarking results and integration of these results in the project is to be expected. In
one other case, external benchmarking was applied but it seems the application in that
project was simply too late to be effectively included in the project itself.

The reason why, in the remaining two cases, external benchmarking was not substantially
applied was either that it was not a common practice in the industry or it was not desired
to benchmark because of the patented and unique products involved, in view of the
interviewees. Still, applying external benchmarking could have enabled early anticipation
in the FED phase on the negative developments in a specific case and hence would,
most probably, positively have influenced its performance. For example, an external
benchmarking study could have recommended paying more attention to interface and
stakeholder management.

The VIP External Benchmarking is closely connected to another important VIP, the VIP Lessons
learnt. An organisation will only optimally benefit from applying Benchmarking if the bench-
marking results are implemented in the organisation and are used in the (subsequent) projects.
Hence it touches upon learning from previous experiences – Lessons learnt.

7.5.2. Lessons learnt


The relevance of applying lessons learnt of previous projects in the early project phases seems
obvious from practice as well as literature (Bosch-Rekveldt, 2011; Cooke-Davies, 2002; Williams,
2003). Still there seems something to gain when it comes down to truly applying lessons learnt.
When a project is completed, a next project is calling the attention of the project team (if the
project manager not already had left the team, even prior to completion).

The VIP Lessons learnt implies ‘a structured process for capturing, interrogating, analysing,
making systemic corrections, archiving and implementing lessons learnt during the inception,
development and execution of an engineering project.’ Hence it is about capturing lessons learnt,
but also about implementing those lessons learnt, throughout all project phases. Too often les-
sons are captured, but not truly used, learnt nor implemented.

128

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

In complex engineering projects two types of knowledge play a role: explicit knowledge and
tacit knowledge (Geisler & Wickramasinghe, 2009; Hertog & Huizenga, 2005). Explicit knowledge
can be stored, it is concrete, formalised and transferrable. Tacit knowledge, however, cannot be
stored: it is implicit knowledge, routed in the experiences, expertise and abilities of an individual,
it is more difficult to communicate. Converting tacit knowledge into explicit knowledge is seen
as a major challenge to modern organisations (Jashapara, 2011).

The VIP Lessons Learnt obviously catches the explicit part of knowledge obtained in a project,
but also explicating tacit knowledge is aimed for. For example, at project close-out (see Chapter
13), a project team might be obliged to perform a project evaluation including written lessons
learnt (sharing explicit knowledge) but the team might also be asked to demonstrate some of the
project findings (sharing tacit knowledge).

The main question to be answered remains how an organisation can motivate its employees to
actively share and use lessons learnt. Just providing a tool or database to store lessons learnt
is not sufficient, more important is the culture involved. An employee should be rewarded for
sharing any mistakes, rather than being punished for her openness. Again it comes down to the
people side of project management.

A nice example of lessons learnt from practice is the publication of King / Dienst Metro on the
lessons learnt from the North/Southline project in Amsterdam so far (Raats, 2013). This publica-
tion very well illustrates how the implementation of lessons learnt during the project execution
actually contributed to improving its performance. Whereas at some point, the public opinion
was very negative about the project and its problems, at current stage the public opinion is rather
positive. Further implementation of these lessons learnt in subsequent projects, from early pro-
ject phases onwards, offers opportunities to improve project performance.

7.6 ! New focus areas


This chapter on front-end development concludes with some trends related to the early project
phases. First the topic of safety is discussed, which deserves attention throughout the project
lifecycle and hence also in the front-end phase. With foreseen scarcity of (energy) resources in
future, the theme of sustainability becomes increasingly important. Therefore sustainability is
discussed subsequently. This chapter ends with a plea for a lifecycle approach, in which an inte-
gral view is applied to project management, including asset management.

7.6.1. Safety
Only disasters trigger industry and government to actually, and in some cases finally, take action.
From aviation industry to infrastructure, from oil and gas industry to construction: all industries
do have their disasters in the field of safety. Think of the Challenger disaster in 1986 that triggered
NASA to change the organisation structure and professionalise project management. Think of
the Deepwater Horizon oil spill in the Gulf of Mexico in 2012, where organisations were blamed
for their poor safety systems. Think of the Texas refinery disaster in 2005. Or the fire in the Mont
Blanc Tunnel in 1999, where a lack of coordination was said to hamper the tunnel safety and
measures were taken to improve the situation.

129

925836-02_147_17-Feb-15_08:42:24_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

Throughout project phases, safety needs serious attention. It is about the safety of all employees
involved, on the project site as well as in the project offices. It is about the safety of the future
operations but also about safety during project construction or implementation.

A recent PhD study deeply investigated structural safety in the construction industry (Terwel,
2014). Critical factors appearing most important to assure structural safety were found to be:
communication and collaboration, risk management, control, allocation of responsibilities, safe-
ty culture and knowledge infrastructure. More details on the findings of this study are provided
below.

Structural Safety – Study into critical factors in the design


and construction process (Terwel, 2014)
‘The main aim of this study was to determine factors in the design and construction
processes within current Dutch building industry that need improvement with respect to
structural safety. The current Dutch building industry is complex with a variety of actors,
like clients, advisors, contractors, subcontractors and suppliers, who work on projects in
various forms of collaboration. In addition, projects tend to become increasingly complex,
due to clients’ wishes and opportunities of computational design.

Based on a national survey, six critical factors for structural safety were identified:
communication and collaboration, risk management, control, allocation of responsibilities,
safety culture and knowledge infrastructure. Measures were suggested that can lead to
improvement of each factor. It was concluded that for many of these factors measures
have been suggested before in Dutch publications, without proper implementation.

It appeared that especially for structural risk management of product and process in
current building practice more guidance is needed. For allocation of responsibilities
and control mechanisms, implementing already suggested measures needs attention.
Furthermore, increased liability of advisors might lead to improvements in the way tasks
are performed and covered.

For safety culture it is believed that process industry and aviation provide useful examples
of a developed safety culture, with mandatory failure reporting and a high level of safety
awareness. Adequate application of BIM, and increase of chain integration and integrated
contracts can improve communication and collaboration in the current building industry.
Best practices of knowledge management need to be shared and implemented to improve
knowledge infrastructure.

It is expected that extra attention to the critical factors and usual attention to the other
influencing factors will ensure improved structural safety in projects and in the Dutch
building sector.’

130

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

7.6.2. Sustainability
Next to the traditional project drivers of cost, time, quality and scope (see also Chapter 1 and
Chapter 6), sustainability is mentioned as an important future project driver (Oehlmann, 2010)
that needs attention also in the front-end project phase.

The business principle behind sustainable development is often expressed as ‘People’, ‘Planet’,
‘Profit’, or as the triple bottom line (Redclift, 1987; Mulder, 2006). The project manager should find
a good balance between these three aspects but the focus so far tends to be placed on the ‘Profit’
value (Dijkstra-Hellinga, 2009) rather than on the environment value (Planet) or social value
(People). In projects, trade-offs do not only have to be made between the high level notions of
‘People’, ‘Planet’ and ‘Profit’, but also a choice needs to be made between the project manage-
ment constraints of scope, time, quality and budget (Meredith & Mantel, 2006; Turner, 2014).
Where does sustainability fit in these lists?

In other words: how to include sustainability aspects in projects in general and in the front-end
development phase in particular? The Sustainable Footprint Methodology is presented in Figure
7.3 (Oehlmann, 2010). The methodology distinguishes three rough project phases to take into
account: project pre-phase (in fact front-end development), project execution and operation of
the asset. The Triple Bottom Line (People, Planet, Profit) forms the other dimension of the matrix.
All cells in the matrix provide attention points to include sustainability considerations in project
management. This matrix could be seen as an extensive checklist, with the danger of being con-
sidered as just another tick-the-box exercise to be completed in a project.

The Triple Bottom Line

1. People 2. Planet 3. Profit


1.3.1 Expected Economic
1.1.1 Stakeholders 1.2.1 Design Options
Performance
1.3.2 Expected Financial Health and
Level 1 1.1.2 Customers 1.2.2 Land and Biodiversity
Stability
Project
1.3.3 Expected Shareholder
Pre-Phase 1.1.3 Politics and Legislation 1.2.3 Environmental Plan
Involvement
1.1.4 Team Participants 1.2.4 Product
1.1.5 Health and Safety Plan
2.1.1 Stakeholders 2.2.1 Transport 2.3.1 Market Presence
2.1.2 Society 2.2.2 Emissions and Waste 2.3.2 Macro Economic Effect
Level 2 2.1.3 Suppliers 2.2.3 Materials 2.3.3 Commercial Performance
Project
Execution 2.1.4 Communication 2.2.4 Water 2.3.4 Capability Management
2.1.5 Human Resources 2.2.5 Energy 2.3.5 Environmental Expenditures
2.1.6 Health and Safety 2.2.6 Noise and Vibrations
3.1.1 Stakeholders 3.2.1 Transport 3.3.1 Market Presence
3.1.2 Society 3.2.2 Emissions and Waste 3.3.2 Macro Economic Effect
Level 3 3.1.3 Suppliers 3.2.3 Materials 3.3.3 Efficiency of Asset
Operation
3.1.4 Community Capital 3.2.4 Water 3.3.4 Environmental Expenditures
of the
Asset 3.1.5 Human Resources 3.2.5 Energy 3.3.5 Long-Term Planning
3.1.6 Occupational Health and Safety 3.2.6 Maintenance of the Asset 3.3.6 Realised Economic Performance
3.2.7 Decomposing of the Asset

Figure 7.3: The Sustainable Footprint Methodology (Oehlmann, 2010)

131

925836-02_149_17-Feb-15_08:42:31_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

Perhaps the most important conclusion of Oehlmann’s study is the need for an integrated
approach in which the dominant paradigm of profit, profit, profit is replaced by a true triple P of
people, planet, profit.

7.6.3. A lifecycle approach


In the front-end development phase, the fundaments of the project are created as was shown
throughout this chapter. In the front-end phase, more and more attention is paid towards a life-
cycle approach of projects. By including maintenance considerations in the design phase, one
can for example avoid the problem of non-accessible windows for a window cleaner by chang-
ing the design upfront, rather than having to install additional equipment to facilitate the window
cleaner. By including the operations’ staff in the design phase, one can for example optimise the
design to best answer the needs of the future operator upfront, rather than to redesign after the
investment decision with all related cost consequences. This ‘integrated thinking’ requires an
integral view on what needs to be done. In a way, it is front-end development 2.0: not only pre-
paring the project execution but also the future use of the project’s output and outcome.

In infrastructure projects, the recent Design-Build-Finance-Maintenance (DBFM) contracts can be


seen as examples of a lifecycle approach. Such contracts span the design, construction, financing
and maintenance for a period of up to 30 years. The idea is to optimally exploit the knowledge
available at contractors, but the long-term contracts also imply that contractors have to commit
to long-term debts (Herrala & Pakkala, 2011) potentially resulting in higher overall costs because
of risks involved – (contractors want to be paid for bearing the increased financial risks).

Lifecycle costing (LCC) could help in making long-term impact decisions but currently, decisions
in various industries are based on short-term budgets (Perrons & Richards, 2013), which also can
have an adverse effect on the total lifecycle cost. Note that some value of a project is hard to
express in simple money anyway (see also Chapter 2 of this book). Maybe this is why the imple-
mentation of LCC across various industries is slow (Woodward, 1997); (Korpi & Ala-Risku, 2008),
although the concept of LCC already was developed in the seventies.

Throughout this chapter, it was shown that integration and involvement are key. Integration of
people from different companies in truly integrated teams, integration of key players in the differ-
ent project phases and integration of maintenance consideration in the design phase(s).
It is about the true involvement of the people within the team. To achieve quality of the front-
end development phase, structure is a necessary, but insufficient precondition. On top of the
structure, the people can make the difference.
And last but not least the need for integration of the triple P (people, planet and profit) in a
project context was stressed.

132

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

7.7 ! The Wind Farm


In order to decide which activities need (additional) efforts in the front-end phases,
performing a complexity assessment on this project might be helpful. Because of the
inherent subjective character of project complexity, it is important to involve several
relevant parties in the assessment. At least representatives of Allwind Energy, the project
team and the Participants Windenergy Vento are invited to participate in the complexity
assessment.

This project appears particularly complex due to external complexities like a high variety
of external stakeholders’ perspectives (perhaps not all parties are equally enthusiastic
about having wind turbines near-shore and onshore), political influence (political
atmosphere might influence the process of obtaining the necessary permits) and
remoteness of location (approaching the 80 wind turbine locations might be difficult).
Organisational complexities might also play a role such as organisational risks (because
of these different locations) or lack of experience with the parties involved (in case Allwind
has not worked with the contractors before). In terms of technical complexities, the
newness of technology might play an important role because non-proven technology
will be included.

After an inventory of potential complexities and discussion between different parties


about their complexity perceptions, measures will be taken to deal with the identified
complexities. For example, by paying more attention towards stakeholder management
to make sure that perspectives are aligned as much as possible (or at least be aware of
distinct differences). The application of VIPs will also be tailored to the particularities of
this project.

133

925836-02_151_17-Feb-15_08:42:33_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

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
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 9 ! overview
A contract is a legally binding, enforceable and reciprocal commitment governing the collabora-
tion between two (or more) parties.
In this chapter the focus is on the development and execution of fit-for-purpose contractual
arrangements between owner and contractor, characterised by an equitable allocation of risk.
Such an arrangement needs to be robust; i.e. it needs to be effective throughout contract exe-
cution despite changes that will inevitably occur. The main streams in contract theory and
their application in practice are discussed. The development of an optimal contracting strategy,
breaking up the project work scope into contract packages, is considered in the light of owner
capability. The main forms of remuneration and their application are described, together with the
tendering and award process as well as subsequent contract management.
Throughout this chapter relevant terms and conditions are used to illustrate how the various
concepts are formalised in the contract.

Chapter 9 ! outline
9.1 What constitutes a contract?
9.2 Contract theory
9.3 The contracting framework
9.4 Strategy development
9.5 Forms of remuneration
9.6 Sourcing and contract management
9.7 The Wind Farm

156

925836-02_174_17-Feb-15_08:43:06_walter
the scene and money at work

Chapter 9
Contracting
by Kees Berends

9.1 ! What constitutes a contract?


Contracts mean different things to different people. To a lawyer, a contract is a reciprocal commit-
ment between two (or more) parties that is legally binding and enforceable; the contract defines
the rights and obligations of the parties involved. In economic terms a contract is primarily a
bilateral coordination arrangement that sets out how parties will work together. Here, contracting
is discussed from a project management perspective, considering economic and legal aspects
relevant to the practitioner, but with a focus on contracting as a tool to achieve effective project
control. With this in mind, the following definition will be used:

A contract is a legally binding, enforceable and reciprocal commitment


governing the collaboration between two (or more) parties.

In project management the term contracting (contract, agreement) is often used for services
(e.g. engineering, construction) and the term procurement (purchase order) is used for goods
(e.g. bulk materials and equipment items). From a legal perspective however there is no distinc-
tion; they are contracts. Essential elements of contract formation are (Buchem-Spapens, 2011):
a) The intent to create a legal relationship and the legal capacity to act
b) An offer and an acceptance; and
c) Compliance with established practice and the law.

In economic transactions an underlying assumption is that a party’s declared intent corresponds


with the actual intent. This means that even in the case of an error by one party, a contract exists
if the other party had good reasons to rely on that declaration. In principle all adults and ‘legal
entities’ (e.g. corporations) have the capacity to enter into a contract, but the number of people
authorised by a company to do so will be limited. If an unauthorised person has entered into a
contract on behalf of a company, a contract will still exist if the other party had good reason to
believe the signatory was authorised to represent the company.

157

925836-02_175_17-Feb-15_08:43:08_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

Scope

Tendering
&
Award

Price Terms

Figure 9.1: Contract triangle

The concept of offer and acceptance is at first sight simple and straightforward. In practice, how-
ever, complications arise on a regular basis. A statement can only be qualified as an offer, if it
defines the following main elements: (i) Scope of work; (ii) Price and payment provisions; and
(iii) Terms and Conditions. As illustrated in Figure 9.1, these elements are interrelated. In the
contract a fit-for-purpose balance is established through an iterative process of qualifications
and negotiation during the tendering and award process. An offer is revocable, unless explicitly
defined otherwise; e.g. ‘this offer is valid until ….’. The most important consequence of such an
irrevocable offer is that the offering party cannot withdraw the offer during the specified period.
An offer which is free of engagement or without obligations on the other hand, can be revoked
by the offering party at any time. Acceptance is sometimes also complicated. For instance, it
is quite common to ‘accept the offer subject to the following qualifications …’. This constitutes
a counteroffer rather than acceptance and the contract is not established until the counter-
offer has been accepted without qualification. Finally it is worth mentioning that the moment at
which the contract is established is not always obvious. Here the main rule is that the declaration
of intent becomes effective upon reaching the party addressed. Whether or not it has come to
the other party’s attention is irrelevant (Dop, 2013). This illustrates that people are key in con-
tracting procedures; e.g. if the letter in which the offer has been accepted has not been opened
by the recipient, the contract has still been established.

The term ‘offer’ is typically used by lawyers whereas contracting professionals tend to speak of
‘tender’ or ‘bid’. Here these terms are used interchangeably.

In principle, parties have freedom of contract which means they can stipulate anything they like
in their contract, provided it does not contravene the law and it is feasible. A contract to build a
perpetual motion machine for instance would not be possible. Contracts are only binding on the
contracting parties and generally not subject to any format. This means they can be oral as well
as written. Obviously, the main problem with oral contracts is that it can be hard to prove what
exactly has been agreed. This is the main reason why contracts are usually written.

158

925836-02_176_17-Feb-15_08:43:10_walter
the scene and money at work

9.2 ! Contract theory

9.2.1 Origins of contract theory


Contract parties are economic entities and consequently economists have taken a keen inter-
est in analysing contracting through economic models. The starting point is the basic model
of a business enterprise called the theory of the firm. Initially, the primary goal of the firm
was thought to be (short-term) profit maximisation. Later on this was broadened to incorpo-
rate uncertainty and time. The behaviour of the firm in economic models is governed by value
maximisation. The practical application of the initial models developed in the 1930s based on
the theory of the firm, was limited due to the underlying restrictive assumptions such as a per-
fect equilibrium between prices and quantities at all times, parties being equally and completely
informed, perfect verifiability by an external party (e.g. arbiter or judge). Within the context of this
book, there is no room for a comprehensive review of the relevant economics literature however
some of the most salient developments are outlined below.

In 1937, Coase was one of the first to introduce the concept of coordination mechanisms and
cost. Building on this early work, in the 1970s Williamson developed the transaction cost theory,
focusing on parties’ inability to compose complete contracts in the face of (i) Incomplete and
asymmetric information; and (ii) Limited enforceability due to independent arbiters not being
able to verify contract performance reliably and in a timely fashion (Brousseau et al., 2002).

In recent decades, game theory has attracted a lot of attention. The most important event in
its early development was the publication in 1944 of the book Theory of games and economic
behaviour by Von Neumann and Morgenstern. In the early 1950s Nash developed the concept
now known as the ‘Nash equilibrium’ and the game theory of bargaining, which proved to be
an important building block. A famous early game, the ‘prisoner’s dilemma’, was contrived by
Dresher and Flood around the same time, involving two players where the self-interest of each
player leads to both being worse off than if they had collaborated.

An important milestone in the development of incentive theory, which is such a large part of
the contracting economics literature today, is the concept of moral hazard (from the insurance
market) introduced by Arrow in the 1960s. This incorporates the notion that individual actions
may damage the general welfare and cost to society as a whole (Macho-Stadler, 2001). In 1964,
Scherer published his seminal paper on contractual incentives when the Department of Defence
in the USA started to use these extensively (Scherer, 1964). In 1970, Akerlof described the hidden
characteristic problem in the market for used cars. Owners of new cars often place these on the
market when expensive repairs start to appear frequently; they are ‘lemons’. Consequently the
market for used cars contains a disproportionate number of lemons. This depresses the price of
used cars, discourages good quality cars being put on the market, which decreases the equilib-
rium price and so on.

The theories described above focus entirely on material incentives and their impact on indi-
vidual and corporate decisions. In the 1970s, Kahneman and Tversky introduced psychological
research into economics, particularly regarding judgement and decision making under uncer-
tainty, leading to what is currently known as behavioural economics. This builds on the work
of Arrow, acknowledging that contracting is a human process where individual biases affect

159

925836-02_177_17-Feb-15_08:43:10_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

corporate decision making. These biases include the representative heuristic (favouring salient
data), availability heuristic (reference to examples) and the anchoring and adjustment heuristic
(bias in favour of existing beliefs, initial estimates, etc.). These heuristics do not mean people are
irrational but rather that their behaviour is governed by ‘bounded rationality’. In most cases the
available information is incomplete and the time for analysis limited, which impacts the decision
making process at individual as well as corporate level.

An early example of operationalising economic theory is the work of Friedman on competitive


bidding in the 1950s (Friedman, 1956). However despite the enormous advances in contracting
economics during the last 40 years, the interaction between theorists and contracting practition-
ers remains limited. The latter tend to rely on best practices and standards based on operational
experience as for instance described by Clough and Sears in their reference work which has
been used in the industry for over 45 years (Clough et al., 2005). Fortunately, the value of an
interdisciplinary approach, operationalising theoretical concepts from contracting economics is
increasingly recognised (Berends, 2007).

9.2.2 The principal – agent model


The prevailing model in contract theory today is the ‘principal-agent’ paradigm, which draws on
the theories discussed above. The principal (i.e. the owner) is the party that proposes the contract
and the agent (i.e. the contractor) is the party that has to accept or reject the contract. The main
concepts in the principal-agent model are:
a) Hidden information; and
b) Hidden action.

Hidden information and hidden action are frequently referred to as ‘adverse selection’ and ‘moral
hazard’ respectively.
A hidden information problem exists when the contractor has characteristics or knowledge that
are not known to the owner prior to contract award and that affect the contracting framework
and contractor selection. This can relate to the financial status of a contractor, his workload or
technical capability. The owner engages the contractor because the latter has technical capabil-
ities and or resource capacity the owner does not possess. This inherently means that in many
cases the owner does not have the competence or the capacity to carry out a comprehen-
sive assessment. After issuing the invitation to make an offer (invitation to tender), but before
acceptance (contract award) ‘signalling’ by the contractor may occur (e.g. the type and num-
ber of contract qualifications and the resourcing plan) revealing his hidden characteristics. It is
important that the owner interprets these signals correctly, taking into account possible biases of
the staff involved, to ensure the right contractor is selected.
Hidden action pertains to a situation where (i) The owner cannot verify whether the contrac-
tor has executed the work properly; or (ii) The contractor obtains certain relevant information
after contract award without sharing this with the owner. On engineering and construction
projects, the description of the scope of work will never be ‘complete’ and usually there are time
constraints as well. Also the owner may not be able to assess the quality of the work in a timely
fashion as certain defects may only become apparent after completion of the work or during
operation. Also it may not be possible for a third party (e.g. arbiter or court) to verify the work
in which case the contract will effectively be non-enforceable. In this context, it is important to
realise that the interests of the contractor and the owner are different. For the owner, the project

160

925836-02_178_17-Feb-15_08:43:13_walter
the scene and money at work

is a means to realise an asset that will generate revenue over a long period. The contractor’s rev-
enue is linked to the execution of the project. Consequently the bargaining (negotiating) position
of the owner after contract award is in many cases weak as the consequences of poor quality
and delays in completing the project are much bigger for the owner than for the contractor.

9.3 ! The contracting framework

9.3.1 Contracting in context


Whilst a contract is only binding for the parties to the contract (i.e. owner and contractor), it exists
and operates within a context of related contracts and stakeholders, as indicated in Figure 9.2.

The authorities play an important role through the applicable law, rules and regulations as
well as requirements on participation of local companies, subsidies, etc. Non Governmental
Organisations (NGOs) may also play a role. The interests of these stakeholders are in many cases
(but not always) aligned with those of the local community. Their role pertains to the boundary
conditions for project execution and early engagement with them is critical to project success.
Insurers and lenders facilitate the execution of the project, they play a more direct role in the
contractual relationship between owner and contractors (incl. licensors).

Licensors

3
Insurers Community
4

Contractors 5 Owner 2 Shareholders

7 6 1
Lenders Authorities Contracts

Influence

1 Legal requirements 5 Engineering, Procurement and


2 Shareholders’ agreement Construction (EPC) contracts
3 License agreement 6 Loan agreement
4 Construction All Risk (CAR) insurance 7 Direct agreement

Figure 9.2: Contracting map

9.3.2 Liabilities and guarantees


On most projects the design depends to a certain extent upon information provided by the
owner; this is commonly called rely-upon-information. The owner needs to identify those
design elements for which it is responsible under the EPC contracts and to examine the recourse
that it has to third parties (e.g. process licensors). It will also be important to address the question
as to whether the design obligations of the contractor are absolute, like ‘fitness for purpose’ of

161

925836-02_179_17-Feb-15_08:43:13_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 asset, or less stringent like ‘best endeavours in accordance with accepted industry standards’
or the use of ‘reasonable skill and care’.

The profitability of the project (and possibly the owner’s ability to repay its loans) depends upon
the facility fulfilling certain performance criteria. If the process technology is obtained from a third
party licensor, the license agreement will stipulate: (i) Rights of the owner to use the technology
for the project; (ii) Warranties of the licensor with respect to any patent infringement; and (iii)
Performance guarantees with respect to the process technology. The performance guarantees
will be subject to the plant being constructed in accordance with certain design specifications
included in the license agreement. The liability of the licensor is typically related to a percentage
shortfall in performance (e.g. production capacity) and is limited to a percentage of license fee.

In the event of physical defects or damage to the work, the contractor will be liable for compensatory
damages to the owner. For an equitable contract, the contractor’s liabilities should be related to the
contract value; i.e. the revenue of the contractor and the risks associated with executing the work.
Compensatory damages can be difficult to determine exactly and therefore, so-called liquidated
damages may be included in certain contracts. These constitute a fixed amount per week’s delay
in completion and/or percentage shortfall in plant performance, that are payable by the contractor
to the owner for damages suffered, up to a certain maximum. The word ‘liquidated’ in this instance
merely signifies that the precise amount of the owner’s damages has been established by agreement
up front. Liquidated damages also are a way of limiting the liability of the contractor. It is normal to
include an overall cap on the liability of the contractor and to limit the length of the defects liability
period. Consequential loss (i.e. indirect losses such as loss of income or profit, loss of production,
etc.) is in most cases excluded. An important exception to limiting liability are claims resulting from
gross negligence and wilful misconduct of the contractor where it would be unjustified for the
contractor to act in this way and then hide behind the limitation of liability in the contract.

The payment provisions in the EPC contracts may include retentions that the owner may hold
back subject to completion of (part of) the work. The owner will wish to assess the adequacy of
the bank guarantees or other bonds given by institutions on behalf of the contractor(s). Where
the contractor is a subsidiary, the owner will often require a parent company guarantee.

Insurance is in many cases a key issue, particularly regarding deductibles. In case of project
financing, the loan agreement will contain detailed requirements in relation to insurance and
the lenders will usually wish the project insurances to be taken out by the owner rather than by
the contractor. In the case of a major loss or damage, the lenders may also require a provision
that insurance monies be available to repay the loan rather than continue with the project in the
event of a substantial loss.

9.3.3 Financing the project


The structure of the project financing arrangement needs to be fit-for-purpose and may involve
a number of different lenders with different lending terms and with different priorities in terms of
access to the security provided by the owner. The risk analysis for the lenders is in many ways
similar to that for the owner but their interests are not the same. The main difference is that
the lenders’ return is fixed. The lenders will generally not have an equity interest in the project
and therefore will not benefit from the success of the project beyond their fixed return. On the

162

925836-02_180_17-Feb-15_08:43:13_walter
the scene and money at work

other hand, if the owner becomes insolvent, the lenders face a substantial loss and will have the
administrative burden of enforcing and realising their security. Consequently, lenders tend to be
more risk averse than the owner.

The lenders will first seek to ensure that each risk has been clearly accepted by one of the other
stakeholders in the project. Secondly, the lenders will wish the risk borne by the owner to be
minimised, although this may involve costs (e.g. insurance) that the owner considers to be
uneconomic. Finally, where a risk is to be borne by another stakeholder (e.g. a contractor), the
lenders will need to be satisfied that the stakeholder concerned has the resources to bear the
additional cost which could arise if that risk materialises.

A key issue for the lenders will be the nature of the security given by the owner. Where the
owner defaults on its repayment obligations, the lenders will wish to be able to take over the
project and dispose of it to a third party. This will involve having appropriate security interests in
all the assets and contracts of the owner, necessary to execute the project (and also sometimes
over the shares of the owner).

The lenders will also want direct agreements, with the main parties contracting with the owner.
Such direct agreements have become a standard requirement of lenders in project financing.
The main purpose of these direct agreements is to ensure that if the lenders enforce their secu-
rity, the project can continue either under the control of the lenders or, after disposal, under the
control of a third party purchaser.

The loan documentation is likely to contain a large number of detailed obligations on the part
of the owner in relation to project management. These provisions may include (i) An obligation
not to alter the project contracts without the consent of the lenders; (ii) An obligation to enforce
those contracts; and (iii) Rights for the lenders to monitor and inspect the status of the project.
The shareholders of the owner may also be required to give certain undertakings. Breach of the
undertakings may give rise to the right of the lenders to call a default, enforce their security and
take over the project.

All in all, project financing will create significant contractual complications and it is important to
consider possible implications at an early stage.

9.4 ! Strategy development

9.4.1 Generic considerations


The contracting strategy defines the breakdown of the scope into contract packages and how
these will be contracted out. Key elements in establishing this breakdown are:
a) Marketability and commerciality of the packages
b) Project management considerations; and
c) Project specific constraints.

Some parts of the scope may be contracted out through competitive tendering, in order to obtain
offers (bids) at a commercially acceptable price. Here the availability of sufficient, competent

163

925836-02_181_17-Feb-15_08:43:16_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

bidders is an important consideration. Other packages may be contracted out through (exist-
ing) frame agreements or single source negotiation. From a project management perspective,
packaging scope elements can be attractive to minimise the number of interfaces. However the
contractor responsible for a certain package may contract a large part to sub-contractors with
the ‘single point responsibility’ and reduction of interfaces being a fallacy. Other considerations
relate to construction sequencing, which will have an impact on the time when contracts for
the various packages have to be placed. Project specific constraints may include the boundary
conditions imposed by the various stakeholders (see also 9.3). To take all these considerations
into account, it is essential to carry out a proper assessment of the requirements of all relevant
stakeholders in a timely fashion. After generating a number of credible ways for a breakdown into
contract packages (strategy options) the optimum strategy is selected based on certain criteria
(derived from the overall project objectives).

9.4.2 Developing contracting strategy options


For the development of a contracting strategy, project activities are typically broken down into:
• Front End Engineering Design (FEED)
• Detailed design and engineering
• Procurement of materials and equipment
• Fabrication and construction; and
• Commissioning and start-up.

When generating options, it is useful to start with the two archetypes, described schematically
below as strategy (a) and (b) and to subsequently develop a number of hybrids. The various
options can be visualised in the form of a so-called ‘contracting quilt’. In Figure 9.3, the contract-
ing quilts of two archetypical contracting strategies are depicted, with a breakdown into five asset
elements (general facilities, utilities, process plant 1/2 and storage tanks). The various blocks each
represent a contract. In reality the breakdown will be more detailed and capital cost estimates for
the various asset elements may be included to establish the size of the various packages.
Commissioning

Commissioning
Construction

Construction
Procurement

Procurement
Engineering

Engineering
FEED

FEED

General facilities

Utilities

Process plant 1

Process plant 2

Storage tanks

(a) (b)
Figure 9.3: Strategy archetypes

164

925836-02_182_17-Feb-15_12:16:24_walter
the scene and money at work

Under strategy (a) the owner awards a contract for FEED and subsequently a contract for
Engineering, Procurement and Construction (EPC). The contractor has an obligation to deliver
the asset specified in the FEED package and in many cases the EPC contract will be on the basis
of a lump sum / fixed price (see also 9.5). Commissioning and start-up activities are usually car-
ried out by the owner, with assistance from the EPC contractor.

Strategy (a) inherently creates a hidden information problem. Whilst the contract sum is relatively
small, FEED is critical for project success and therefore the owner will strive to select the most
competent contractor. The latter will also want to participate in the execution phase (commer-
cially the most interesting part of the project). Precluding the FEED contractor from participating
in the tendering for execution may result in competent contractors being unwilling to perform
FEED. On the other hand, allowing the FEED contractor to participate in competitive tendering
for the EPC will provide them with an unfair information advantage versus the other bidders.
Also, there is a risk of ‘gaming’ by the FEED contractor (i.e. manipulation of the FEED) to improve
its commercial position during EPC tendering. This may even lead to a situation where other
prospective bidders refuse to compete against the FEED contractor which participates in the ten-
dering process, because they do not believe they have a realistic chance of winning. Hence the
owner is at risk of finding itself at the end of FEED in a situation where strategy (a) is not market-
able with no other option than to negotiate single source with the FEED contractor. A ‘hostage’
situation where the contractor, having just executed the FEED work, will in most cases be better
informed about the project than the owner. This is particularly relevant in a constrained market,
with ample prospective contracts for contractors. It is therefore critical to collect reliable market
intelligence in a timely fashion. This may include pro-active engagement with the market and
maintaining the established relationships during FEED by keeping prospective bidders informed
about the status.

An alternative is to create a level playing field by having multiple contractors perform the FEED
in parallel, with all contractors submitting a proposal for execution at the end of FEED. This min-
imises the risk of not having a competitive tendering situation for the EPC work but results in
extra cost and an additional burden on the owner for managing multiple FEED processes.

Under strategy (b) the owner awards one contract for FEED and services for Engineering,
Procurement and Construction Management (EPCM). As the FEED/EPCM contract is awarded at
a time when the level of scope definition is limited, a reimbursable form of remuneration (see
9.5) will generally be used. Certain scope elements like storage tanks may still be contracted out
on an EPC basis as they are executed by specialised companies, providing an integrated supply
chain solution. Procurement of the other materials and equipment and construction activities is
executed by the contractor ‘for-and-on-behalf’ of the owner. Effectively the contractor carries
out the same activities as under strategy (a) but now at the owner’s risk with subcontracts in
the name of the owner. Strategy (b) potentially offers significant continuity and schedule bene-
fits (with FEED rolling into detailed engineering), but requires a (relatively) large and competent
owner’s team, particularly regarding progress/cost control and contract management. A disad-
vantage for the owner is that it has to select a (main) contractor very early in the project lifecycle.
However with EPCM services constituting only 10 - 20 % of total cost, the commercial exposure
is generally limited.

165

925836-02_183_17-Feb-15_08:43:20_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 two strategies described above are archetypes and in practice many ‘hybrid’ forms will exist.
As a variation of strategy (a), execution can be broken up into separate EPC contracts. This may
be prudent to increase the marketability, but creates a coordination issue between the various
packages. Similarly a variation of strategy (b), would be free issue of materials and equipment
to a single construction contractor. This will facilitate a phased contracting approach, but it also
means that the owner is responsible for (i) Timely completion of accurate construction drawings;
and (ii) The quality and timely delivery of materials and equipment. Any problems in these areas
will lead to claims of the construction contractor.

A concept that has received considerable attention during the last decades is ‘partnering’, where
owner and contractor seek to create a collaborative relationship, based on trust between the
parties rather than a formally structured arrangement; it is generally a non-binding process.
Sometimes used interchangeably with partnering arrangements is the term ‘alliances’ which per-
tains to a construct whereby owner and contractor share risk and rewards. This is often realised
through some form of incentive arrangement linked to target cost. In the domain of public
procurements, Public Private Partnership (PPP) projects are gaining ground (e.g. Commissie
Private Financiering van Infrastructuur (Commission Private Financing of Infrastructure), 2008).
This covers a variety of contracting frameworks that create a long-term relationship between the
public and private sector, including private financing of public service or infrastructure projects.

9.4.3 Selecting a fit-for-purpose solution


The criteria for selecting the optimum strategy have to be fit-for-purpose and are generally
derived from the overall project objectives; but they are not the same. Only those objectives that
are influenced by the contracting strategy are relevant. As indicated above, schedule for instance
is influenced by the contracting strategy and is therefore a selection criterion. Safety is not as this
is not primarily driven by the contracting strategy.

Various techniques are available for selecting the optimum contracting strategy. A common
approach is to carry out a Strengths, Weaknesses, Opportunities and Threats (SWOT) analysis. A
more quantitative technique is the Analytical Hierarchy Process (AHP) described by Saaty (Saaty,
2001). A comprehensive description of decision-making techniques and processes is beyond the
scope of this book. However, it is strongly recommended to follow a process with a balanced
group of decision makers to avoid personal biases like the latest experience of the key project
team members (see 9.2). This will involve professionals from project management, contracting,
cost estimating/control, scheduling and selected technical disciplines.

9.5 ! Forms of remuneration

9.5.1 The allocation and pricing of risk


The form of remuneration is an integral part of any contracting strategy, defining the pricing
and allocation of risk. Under a contract, the contractor will have an obligation to: (i) Achieve a
certain result (deliver an asset); or (ii) Use its best endeavours in providing services. The former is
generally associated with a lump sum/fixed price and the latter with a cost reimbursable form of
remuneration. For construction work so-called unit rate contracts are often used.

166

925836-02_184_17-Feb-15_08:43:22_walter
the scene and money at work

The main difference between these contracts lies in the allocation of risk and the time at which
risk is ‘priced’. With a lump sum/fixed price contract, the contractor is required to provide a price
guarantee; i.e. the contractor is acting as a ‘quasi-insurer’ whilst in most cases it is ill placed to
bear the consequences of risk materialising (Ward et al., 1995). With a reimbursable contract the
owner initially carries the overall project (capital) cost risk and in the course of project imple-
mentation this is (gradually) transferred to suppliers and construction contractors (see Figure 9.4).
Many different variations exist within these two groups. Here, only the ones most commonly
used for FEED, EPC, EPCM and construction are discussed.

Contractor’s risk

Lump Sum Unit Rate Reimbursable

Owner’s risk

Figure 9.4: Forms of remuneration

9.5.2 Lump sum/Fixed price


With a Lump Sum/Fixed Price (LSFP) contract the contractor is responsible for executing and
completing the work as defined in the scope of work for a fixed price; i.e. the contract sum is
established at the start of the contract. The risk of the actual cost exceeding the contract sum is
borne by the contractor. If the actual cost of the work exceeds the contract sum, the contractor
has to accept a reduced profit or even a loss. This provides an inherent incentive for the contrac-
tor to execute the work efficiently. The premium associated with the contractor carrying the risk
of cost and schedule escalation is included in the contract sum. The size of this risk premium is
dependent on the contractor’s assessment of the risks and on market conditions (i.e. competitive
pressure).

Usually a reimbursable remuneration scheme is included for pricing any changes. LSFP con-
tracts are generally used for EPC and construction work. Sometimes the term turnkey is also
used, but this refers to a contract where the contractor provides a comprehensive service to
owner (e.g. project financing, land purchase, EPC, commissioning and start-up); the remunera-
tion basis does not have to be LSFP. Payment under an LSFP contracts is made against a series
of milestones (based on completion of a certain event) and/or on a monthly basis against value
of work done.

167

925836-02_185_17-Feb-15_08:43:23_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

Table 9.1: LSFP/EPC Contracts

Strengths/Opportunities

Relative cost certainty Market feedback and commitment (in case of competitive tendering)

Simple arrangement Single point of responsibility; contractor accepting the cost and completion risk

Performance incentive Cost (inherently); schedule and plant performance through Liquidated Damages

Small owner’s team Progress monitoring and change management; limited executive decision points

Bankable Preferred contractual arrangement for project financing

Weaknesses/Threats

Scope definition Good definition required, with limited ‘rely-upon’ items

Sufficient tenders Approach only effective when sufficient credible tenders can be obtained

Risk premium Contractor not well placed to bear the consequences of cost escalation

Schedule Significant tendering period to enable risk pricing and FEED verification

Limited flexibility Requirements need to be agreed at the start of contract

The strengths/opportunities and weaknesses/threats of LSFP/EPC contracts are summarised in


Table 9.1. One of the main reasons why many owners prefer this approach is that it provides
relative cost certainty (in the form of an LSFP/EPC bid) at the time of the investment decision. It
should be noted that this certainty is not absolute, particularly on engineering and construction
projects with a long project execution time and changing market conditions. Hence, the ‘fixed
price’ under a lump sum contract may prove to be illusory if risks materialise and lead to change
orders and claims. Also, many lump sum contracts nowadays contain exclusions or limitations of
the contractor’s liabilities, particularly with respect to risks that are beyond its control (e.g. wage
increases, steel price, etc.) to limit the risk premium included in the contract sum.

9.5.3 Cost reimbursable contracts


A large number of different forms of cost reimbursable or Cost Plus Fee (CPF) contracts exist. All
of them have in common that the owner reimburses the contractor for (i) All costs, reasonably
incurred and directly associated with the project; plus (ii) A certain fee for the services provided.
CPF contracts are typically used when the scope of work cannot be defined accurately upfront
like FEED and EPCM services. The total contract sum remains unknown until completion of the
work, because payment to the contractor is made on the basis of work actually done.

The strengths/opportunities and weaknesses/threats of CPF/EPCM contracts are summarised in


Table 9.2. Differences between CPF contracts pertain to the way the fee is established. With a

168

925836-02_186_17-Feb-15_08:43:25_walter
the scene and money at work

Table 9.2: CPF/EPCM Contracts

Strengths/Opportunities

Marketability Service contracts are attractive when project risks are high

Risks allocated to the party best placed to carry the risk


Risk allocation
Optimum timing of contract award, when work packages are defined

Lowest cost Limited risk premium

Continuity Continuity between FEED and detailed design and engineering

Flexibility Changes during execution can easily be accommodated

Weaknesses/Threats

Cost uncertainty No overall ‘fixed’ contract sum at the investment decision

Performance incentive No inherent performance incentive

Complex arrangement Extensive control required by the owner

Bankability Additional guarantees from the owner may be required

Cost Plus Percentage Fee (CPPF) contract the fee is calculated as a percentage of the man-hour
cost of the EPCM services. This can also take the form of an all-inclusive hourly rate. A major
disadvantage of a CPPF contract is that it effectively provides an incentive for the contractor to
increase the overall project scope, as the amount of services (and the contractor’s profit in abso-
lute terms) is related to the overall scope. This requires extensive owner involvement to control.
An alternative is a Cost Plus Fixed Fee (CPFF) contract whereby a single, fixed fee is agreed for
all services. This means that when the number of service hours increases, the contractor’s profit
margin (i.e. fee divided by the service hour cost) decreases, which discourages it from unduly
inflating the number of hours. Another alternative is to make the fee (in part) subject to perfor-
mance against a number of criteria defined at the start through a Cost Plus Incentive Fee (CPIF)
contract. This can indeed provide a mechanism to align the interest of owner and contractor
through the contractual arrangement. In practice however, it is often difficult to define crite-
ria and set performance targets that are meaningful and robust. Many incentive schemes are
‘over-engineered’. Whilst they have a place in the toolkit of the contracting professional, they are
generally only used on large projects and after careful analysis and modelling of the fee potential
versus the expected outcome of the criteria.
An inherent problem with CPFF and CPIF contracts is that the actual cost and fee (profit) for
the services have to be separated. This is in many cases not easy and requires specific financial
(owner) competencies to establish whether the cost build-up (salaries, payroll burden and over-
heads) is fair and reasonable.

169

925836-02_187_17-Feb-15_08:43:25_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

9.5.4 Unit rate or bill of quantities


Unit rate contracts are typically used for construction work. The units used (e.g. in a tunnelling
contract: a cubic meter of material excavated or a meter of tunnelling completed) and prices are
specified in a schedule of unit rates or ‘bill of quantities’. Unit rate contracts can be used when the
overall scope of work is unknown at the time of contract award, but the scope of each unit can
be defined. Therefore they require less scope definition at the outset than lump sum contracts,
although a reasonable estimate (by the owner) of the quantities is important for having an effec-
tive tendering process. With a unit rate contract, the contractor carries the ‘productivity risk’ of
executing the work as the owner is paying a fixed price for each unit. The owner carries the risk
of the quantity of work and must ensure it has the resources to carry out measurement of the
actual quantities executed. Tendering of unit rate contracts requires a significant effort from both
owner and contractor and is therefore only used on large projects or an existing production site
where it can be applied for a number of smaller projects and maintenance work.

9.6 ! Sourcing and contract management

9.6.1 Prospective contractors


The sourcing process requires a significant effort from contractors and the associated transac-
tion costs have to be recovered at some point in the supply chain. Therefore it is good practice
for owners to follow a staged process which ensures that contractors do not incur unnecessary
costs in pursuing opportunities which they have no chance of winning. In general terms, the
owner also has an obligation to be clear about its intentions during the contracting process, and
failure to do so will provide the contractor with recourse under law even if the contract has not
been concluded.

The first step in contractor selection is establishing a ‘long list’ of contractors that could poten-
tially carry out the work. Potential contractors will be requested to indicate whether they wish
to participate in the project; the solicitation of interest. This is followed by a pre-qualification
process leading to a ‘short list’ of potential bidders that will receive an Invitation To Tender (ITT).
Whereas the number of contractors on the ‘long list’ and the ‘short list’ will depend very much
on the work at hand, generally these should be 5 - 10 and 3 - 5 contractors respectively. The pur-
pose of the pre-qualification process is to establish whether prospective contractors are suitable
to execute the work, with respect to:
a) Financial health
b) General management and
c) Technical competence.

Contractors will be requested to submit general (e.g. financial data), as well as project specific
information (e.g. track record for this type of work, safety performance). The contracting strategy
will also have to be taken into account. For instance if the work pertains to FEED but the intention
is to ‘roll on’ into EPCM, competences for both have to be considered. The information under
a) and b) is mostly generic and may not be required if the owner frequently does business with
certain contractors.

170

925836-02_188_17-Feb-15_08:43:25_walter
the scene and money at work

To preserve the integrity of the pre-qualification process, it is important to establish the eval-
uation procedure prior to receipt of submissions. This procedure should define the selection
criteria, the process (avoiding undue bias), the responsibilities of the members of the evaluation
team, ‘checks-and-balances’, timing and a communication protocol. It is acceptable to request
clarification during the pre-qualification process in the case of ambiguity or missing items, pro-
vided a level playing field is maintained. Also, it is good practice for the owner to provide (general)
feedback to those contractors that have not been ‘shortlisted’.

9.6.2 The tendering and award process


As a general rule, the ITT compiled by the owner should be suitable for incorporation into the
final contract with minimum alteration. An ITT typically consists of the following main elements:
• Scope of work
• Admin instructions and
• Draft terms and conditions.

The scope of work describes the deliverable as well as the way the work will be executed and
the timing. For a FEED contract this will include the initial basis of design, standards, the level of
detail required, special studies, calculations and simulations, etc. In the case of an EPCM contract,
requirements regarding project execution (including monitoring, control and reporting) should
be specified as well. For an EPC contract or a construction contract, a FEED package, technical
specification and construction drawings (when available) will be included. Some of this informa-
tion may be ‘rely upon Information’ or information from licensors (see 9.3.2).

The admin instructions specify how the tendering process will be executed; management of
the information flow, clarification meetings, the format of the tender and the submission time.
The tender may be split into a technical proposal and a commercial proposal. The technical pro-
posal contains the deliverables and how the work will be performed. The commercial proposal
contains any qualifications to the draft contract included in the ITT and the pricing information.
It is recommended to evaluate them separately to avoid bias.

Included in the ITT are the terms and conditions proposed by the owner to provide a common
basis of the commercial proposals submitted by the bidders (see also 9.1). The so-called ‘bat-
tle of the forms’ should be avoided, i.e. bidders responding by submitting their own (different)
terms and conditions, as this leads to inefficiencies and difficulties regarding equalising the bids.
Included in the terms and conditions are the payment provisions; the time value of money has to
be considered for any alternatives proposed.

During the tendering period, bidders may be offered the opportunity to visit the site and the
owner will have to manage the process of clarifications, ensuring all bidders receive the same
information to maintain a level playing field. It is important to allow for sufficient time for bid
preparation; not doing so will have a detrimental effect on the quality of the bids and inevitably
lead to delays and cost escalation later on.

The bid evaluation process is in many ways similar to the pre-qualification process but the integrity
issues are more pronounced and the procedures for handling information more strict. Also the
owner will generally as part of the process compile a counter estimate prior to opening the bids.

171

925836-02_189_17-Feb-15_08:43:28_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

After the bid evaluation has been completed, negotiation will start with the ‘preferred bidder’ to
finalise the contract. It is critical that during this period of negotiation the other bids remain valid,
so the owner retains a fall-back position should it not be able to reach conclusion with the pre-
ferred bidder. For major contracts it is customary to jointly sign the contract upon conclusion of
the negotiations to avoid ambiguity regarding the time at which the contract is concluded (see
also 9.1).

9.6.3 Contract management


Starting with the tender and the signed contract, contract execution generates a lot of informa-
tion and documentation. Clear procedures and an efficient contract administration system are
essential for a fit-for-purpose contract management process. The contract management pro-
cedures will define the division of work and responsibilities between contract holder (i.e. the
person responsible for executing the work), contracting and procurement, finance (e.g. invoicing
and payments) and other stakeholders such as the legal department, tax, etc. The administration
system is used to store all relevant documentation and to assist in managing the information
flow. Many commercially available software packages exist ranging from simple database solu-
tions to advanced, integrated and interactive systems (accessible by owner and contractor) for all
contract correspondence (i.e. no communication via Email anymore). It is important however to
recognise that the operation of such a sophisticated system requires serious expertise and align-
ment with other IT systems at the owner’s organisation.

An important element of contract management is performance monitoring. In many cases this


will be limited to progress and cost control, but for a large contract other performance indicators
may be established that are tracked on a regular basis (e.g. regarding safety performance). As part
of the payment conditions, the contract may include an advance payment, made at the begin-
ning of construction to assist the contractor with the start-up costs. Payment during contract
execution can be through progress payments, milestone payments or a combination thereof.
These need to be in line with the ‘value of work done’ and milestone events completed in the
field and the contract will contain provisions allowing the owner to hold back payment in cases
of progress falling behind.

The area that requires specific attention – as it is often underestimated – is materials management
and logistics. This includes expediting, inspection and warehousing of materials and equipment
during construction as well as timely ordering of spare parts and handover to operations.

A change order or variation order occurs when during contract execution the owner requires
a change in the scope of work or if other changes occur for which the contractor is not liable
under the contract. For instance, certain technical issues, exchange rate fluctuations, increases
in labour rates, etc. may have been explicitly excluded. If it is not clear whether the contractor is
liable for the latter, the parties need to establish whether (i) The contractor could reasonably have
foreseen these changes or whether these should be considered as an inherent contractual risk;
or (ii) The contractor is entitled to a change/variation order. If the owner and contractor cannot
resolve the issue at working level, the issue is first referred to senior management of the parties.
If the issue still cannot be resolved, the contract will provide for the means of resolving what has
now become a dispute. This can be a form of mediation, a negotiation process facilitated by an
independent party, focusing on the commercial interests of the parties and not their legal rights.

172

925836-02_190_17-Feb-15_08:43:31_walter
the scene and money at work

Another private dispute resolution process is arbitration, but it differs in that it produces a bind-
ing result which is immediately enforceable. Finally, disputes can be resolved through litigation,
which comprises a public process.

Concluding observations
It is sometimes stated that contracting strategies and lump sum/fixed price forms of remunera-
tion (combined with competitive tendering) lead to a confrontational approach between owner
and contractor. Approaches based on a form of reimbursable contracts, on the other hand are
often believed to be more conducive to collaborative contracting. It is indeed true that in many
cases in the relationship between owner and contractor, both parties pursue their individual
interests rather than working together to maximise the overall value of the project. This mani-
festation of the ‘prisoner’s dilemma’ is however mostly caused by ineffective transmission of
information rather than the contracting strategy or the form of remuneration (see 9.2).

It is important for both owner and contractor to be clear about their expectations and to
acknowledge their different roles. The owner’s objectives are centred around the creation of the
asset (taking into account the various project stakeholders) whereas the contractor’s focus is on
realising value by executing the project. Alignment of objectives and collaborative contracting
is possible through various contracting strategies and forms of remuneration. The purpose
of the sourcing and contract management process is to clarify the parties’ intentions; translating
these into a contract is an outcome rather than an objective.

It is important for owner and contractor to get off on the right footing, building a constructive
relationship between key staff members based on trust and maintaining this relationship during
contract execution. By definition a project constitutes a change management process and during
its lifecycle the scope as well as the business environment (e.g. supply chain) changes. The
owner has to be realistic about what can be achieved during the various phases in the project
lifecycle and the contractual arrangement has to be robust with respect to accommodating these
changes. Also, it is critical that the owner has the competence required to identify and interpret
signals from the contractor. Both owner and contractor have a lot to gain by working together
effectively. Failing to do so comes at a high price and cannot be mitigated by ‘contractual fixes’
like increasing penalties and guarantees or monetary incentives.

173

925836-02_191_17-Feb-15_08:43:31_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

9.7 ! The Wind Farm


A key consideration in establishing the contracting strategy is that Participants
Windenergy Vento (the owner) lacks the expertise required in realising the project
and therefore it is looking to enter into a turnkey contract for execution. With project
development being dependent on the technology (and key equipment) used, Participants
Windenergy Vento may end up in a captive situation versus Allwind Energy. Taking this
into account, the following contracting strategy options can be identified:

a) Alliance
Participants Windenergy Vento and Allwind Energy enter into an (reimbursable) alliance
agreement, covering project development, execution, operation and maintenance. The
alliance agreement will include a performance based (incentive) fee to align parties’
objectives. If at the end of project development a (lump sum / fixed price) turnkey contract
cannot be agreed, the alliance will continue on a reimbursable (‘open book’) basis.

b) Project Management Contractor (PMC)


During project development, the PMC will work together with Allwind Energy and (lump
sum / fixed price) contracts will be concluded for the license and supply of turbines. If
a turnkey contract cannot be agreed at the end of project development, the PMC will
manage project execution, contracting out the separate scope elements, with an operator
being resourced during execution.

Strategy (b) has the disadvantage that it creates an additional management layer. The
PMC can contract out and manage certain scope elements (e.g. foundations for near-
shore turbines). However, the dependency on Allwind Energy will remain with the supply
of turbines being a large part of the scope. Strategy (a) provides good opportunities for
collaborative contracting, but a comprehensive and robust alliance agreement will be
complex. In view of the above, a variation of strategy (a) is recommended, with the owner
engaging a specialist consultant to set up the alliance agreement and to provide advice
during the initial phases.

174

925836-02_192_17-Feb-15_08:43: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

Chapter 10 ! overview
In this chapter the basics of project monitoring and control are explained, including some
straightforward examples to illustrate the most common methods being applied on projects.
It becomes clear that adequate project controls are a critical part of project success and that
the project controls team has an important role to play. Adequate control means applying the
right level of control for each scope element and associated risks during the subsequent project
phases.
Being the conscience of the project manager, the project controls team needs to provide reliable
information for timely decision making. This requires input from many different disciplines and
external parties that needs to be analysed, integrated and reported. To perform this essential task,
the project controls team needs to proactively engage with the project team and various exter-
nal stakeholders, while realising that they all have their own interest in measuring and reporting
project performance.
This chapter starts by explaining how to establish the right cost and schedule baseline, followed
by controlling the project as it develops. Next progress reporting, the role of the project controls
team and the importance of effective communication is being described.

Chapter 10 ! outline
10.1 Introduction
10.2 Cost estimating
10.3 Planning and scheduling
10.4 Cost and Schedule control
10.5 Progress reporting
10.6 Project controls team
10.7 Fit-for-purpose project controls

176

925836-02_194_17-Feb-15_08:43:37_walter
the scene and money at work

Chapter 10
Project monitoring
and control
by Maurits Gerver

10.1 ! Introduction
Most project managers will at least feel somewhat uncomfortable when they are asked if they are
fully in control of their project. Being risk-averse by nature, a project manager will immediately
think about matters that could go wrong, wondering whether she might have missed an uniden-
tified risk and of course think about the weak spots already known.
According to the online Oxford dictionary control can be defined as ‘the power to influence or
direct people’s behaviour or the course of events’. This is the essence of controlling a project,
being able to influence the course of a project by knowing where to go, knowing how to get
there and knowing which steps should be taken in case the project derails.

If a project is not in control, a variety of things can go wrong. Below some statements are listed
that will sound familiar to most project managers:
• The agreed schedule to deliver the project was unrealistic from the start.
• The stream of scope changes during construction never seemed to stop.
• We have significantly underspent budget.
• It took months before producing at design capacity.
• The operational cost turned out to be much higher than predicted.

Realising that projects should add value to a business, the above samples illustrate that there
are many ways to erode that value. This can be caused by poor definition of the initial premises,
for example committing to an unrealistic budget or schedule. But it can also be caused by poor
scope definition, lack of planning, or poor cost control. In the worst case a project gets out of
control and the initial business value has vanished by the time the project is delivered.
As a project develops from initial business opportunity to design and engineering, construction
and handover to the end-user, project controls mature accordingly. As the level of project defini-
tion grows over time project controls will be performed on a more detailed level.

The next paragraphs describe the key elements to control project planning and execution. They
also discuss the impact that human behaviour can have on project controls, both from within the
project controls team as from stakeholders outside the team.

177

925836-02_195_17-Feb-15_08:43:37_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

10.2 ! Cost estimating

10.2.1 Introduction
One of the most important elements to control during the lifetime of a project is cost, starting
with providing the right cost estimates.

The cost estimate covering the initial capital investment, also called Capital Expenditure (CAPEX),
is usually generated at the very beginning of a project, or even before project initiation, and is
subsequently updated and detailed during project development. The estimate covering the oper-
ational cost, also known as Operational Expenditure (OPEX) or Revenue Expenditure, includes
all cost incurred during normal operations once the project has been delivered. OPEX typically
includes the cost of operations, maintenance cost, consumables and cost of sales. Although this
chapter will primarily focus on estimating and controlling the capital investment, the operational
cost is also an important input to the project economics and can be used to make trade-offs
during design and procurement on the basis of lifecycle cost, also referred to as Total Cost of
Ownership.

The Wind Farm


As Allwind will be responsible for the turnkey realisation and the 20 years’ maintenance of
the offshore wind farm, they should look into optimising the lifecycle cost. Trade-offs can
be made between the initial capital investment (CAPEX) and maintenance cost (OPEX).
While making these trade-offs there could be a potential difference of interest between
Allwind and the owner’s organisation. Allwind could aim at optimising their combined
profit from the turnkey realisation contract and the maintenance contract, while the
owner would like to minimise the lifecycle cost and optimise the availability of the wind
farm.
For example if Allwind uses cheaper components they will reduce their CAPEX cost
under the turnkey realisation contract, while the maintenance cost will likely go up.
The owner could consider including specific performance targets in the maintenance
contract, to incentivise Allwind for optimising the availability of the wind farm, while
minimising maintenance cost. For example targets on wind farm availability, yearly
maintenance cost or response time in case of an unplanned outage.

The quality of a capital cost estimate is critical, as it impacts the economics of a project and can
determine the investment decision. Since funds and resources are constrained, a company can
only invest in a limited number of projects, depending on their business cases. Poor cost esti-
mates can either result in cancellation of economically sound projects, or in wasting money and
resources on non-profitable projects.

In this paragraph the different classes of estimates and their specific purposes are explained,
followed by describing a cost-estimate structure and the commonly applied estimating
methodologies.

178

925836-02_196_17-Feb-15_08:43:37_walter
the scene and money at work

10.2.2 Types of cost estimates


There are many different names and classifications of cost estimates, depending on their purpose
and required level of detail and accuracy. The estimate type or class is often related to a typical
set of deliverables in a project development phase like design and engineering documentation,
a project execution plan and schedule. The level of estimate accuracy depends on the level of
project definition and is an indication of the degree to which the final cost outcome for a given
project will vary from the estimated cost. Besides the level of project definition, the estimate
accuracy also depends on a variety of factors like for example applying new technology, project
complexity and quality of reference cost data.

Although there are many different cost estimate classifications used in the industry, the accuracy
ranges and required supporting project definition are comparable. However the end usage of
an estimate can vary per stakeholder. An owner’s company could use an estimate for project
sanctioning, while an EPCM contractor uses the same class of estimate to prepare a bid. Table
10.1 provides an overview of estimate classes, based on the Generic Cost Estimate Classification
Matrix as developed by AACE International (AACE, 2011).

Table 10.1: Estimate classes

Level of project definition


Typical purpose of
Estimate class deliverables ( % of Typical accuracy range
estimate
complete definition)

Class 5 0% – 2% Screening or feasibility > ± 30 %

Concept study or
Class 4 1 % – 15 % ± 20 %
feasibility

Budget authorisation or
Class 3 10 % – 40 % ± 10 %
control

Class 2 30 % – 75 % Control or bid/tender ±5%

Check estimate or bid/


Class 1 65 % – 100 % < ±5%
tender

It is important to realise that an estimate is never a single number, but it comes with a margin of
uncertainty or accuracy. Not seldom are cost estimate numbers treated as firm numbers, while
people forget the underlying risks and uncertainties.

Next each estimate class and its purpose will be explained in more detail.

Class 5: Screening estimate


The purpose of a screening estimate, also called a subjective estimate (Lester, 2014), is often
to provide a ballpark figure or order of magnitude number being used for strategic business

179

925836-02_197_17-Feb-15_08:43:40_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

planning, such as ranking of future investments. It enables management to prioritise projects by


comparing, amongst other drivers, the economics of each individual project. A screening esti-
mate is usually compiled even before project initiation, or during the first project development
phase. The level of project definition and available deliverables are limited at this stage, hence the
wide accuracy range. A screening estimate can be delivered relatively fast and does not require
much effort to deliver.

Class 4: Concept Study estimate


The purpose of a concept study estimate can be to determine project feasibility, concept evalu-
ation or to provide a preliminary budget. At this stage the project premises (e.g. objectives, key
assumptions, technical premises, etc.) are frozen, concepts have been developed and the first
engineering might have been completed to determine the technical design basis. For complex
projects it is also common to assess the feasibility of multiple options, supported by multiple
cost estimates to help management compare the concepts and select one. A preliminary budget
might be required to move to the next project phase.
Since a class 4 estimate is still based on limited information, it has a fairly wide accuracy range
and it still requires limited time and effort to deliver it.

Class 3: Budget estimate


The purpose of a budget estimate can be to support budget authorisation and/or project
sanctioning. The estimate is based on typical project deliverables like front-end engineering
documentation, a detailed project execution plan and a minimum percentage of firm quotes
from vendors and service companies. The estimate has a better accuracy range and can even
become the first control estimate against which cost performance is being monitored.

Class 2: Control estimate


A control estimate, also called an analytical estimate, provides the baseline for detailed cost
control during project implementation. It can also serve as a tender or bid estimate, used to
determine contract value. It is the most detailed estimate typically in place at the start of con-
struction and requires rigorous management of change to monitor variations to the budget.

Class 1: Check or Tender estimate


Class 1 estimates are generally prepared for discrete parts of the total project rather than for the
entire project. The parts of the project estimated at this level of detail will typically be used by
subcontractors for bids, or by owners for check estimates (bid checks, claims, change orders,
etc.). Depending on the cost changes, it can be used to update the control estimate and to
establish a new baseline for cost control. A project definition level of 100 % will normally only be
reached upon project completion, at which the actual cost are known.

10.2.3 Cost estimate basis and elements


The basis of an estimate is often described in a Basis Of Estimate document, stating the purpose
of the estimate, project scope, pricing basis, allowances, assumptions, exclusions, cost risk and
opportunities. It documents the communication and agreements that have been made between
the estimator and other project stakeholders about the cost estimate basis (AACE, 2013).

Building up the estimate requires input from the entire project team and even from outside the

180

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

project team. All disciplines are involved in defining the scope of work and the cost estima-
tor needs to interface with all of them to have a good understanding of this scope of work. In
practice it still happens too often that an estimator develops the estimate in isolation, without
proactively interfacing with the appropriate stakeholders. This can lead to an incomplete or mis-
understood basis of estimate and ultimately in surprises when the estimate is being released.

A Basis of Estimate document helps to document the collective understanding of the scope of
work, schedule milestones, key risks and underlying assumptions that impact the cost estimate.
Therefore an estimate should always be accompanied by a Basis Of Estimate document as a
reference.

Next it is explained how an estimate can be structured and which cost elements are typically
included.

Work Breakdown Structure (WBS)


A WBS defines the hierarchical decomposition of tasks and subtasks. A high-level WBS will be pro-
duced at the very beginning of a project and will become more detailed as the project matures.
The objective of defining a WBS is to be able to control the project by allocating resources
(human, material and financial) and giving time constraints to each (sub)task (Lester, 2014). So a
WBS provides the structure for cost allocation and scheduling.

WEP
Offshore Wind
Farm

Contracting & Test &


Design Permitting Construction
Procurement Commissioning

Wind Turbine Environmental


Wind Turbine Sub sea soil
Generator impact Test WTG’s
Generators preparation
(WTG) Assessment

Construction WTG Install


WTG fondation Test substation
permits foundations foundations

Operations Test in-field


Substation Sub station Install WTG’s
permits cabling

In-field In-field and Install Test power


cabling export cables substation export cables

Power export Offshore service Install in-field


cables suppliers cabling

Install export
power cables
Figure 10.1: Example Work Breakdown Structure

181

925836-02_199_17-Feb-15_08:43:43_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 some industries a Product Breakdown Structure (PBS) instead of a WBS is being used. A PBS is
based on products and defines the hierarchy of products and sub-products, rather than tasks and
subtasks. In practice many combinations of WBSs and PBSs are used.

Once a WBS has been drawn up, a bottom-up estimate can be produced by costing the individu-
al work packages at the lowest level and adding them up at the levels above. The result is a Cost
Breakdown Structure (CBS). Similarly cost can be allocated top-down, starting at the top level of
the WBS. In practice both ways are being applied, also depending on the purpose of the estimate
and required accuracy. In Figure 10.1 an example of a WBS is shown for the design and construc-
tion of the offshore wind farm.

Next the main elements of a capital cost estimate are described, being a base estimate, allowances,
contingency and escalation.

Base estimate
A base estimate, also called point estimate, is built up from the activities and deliverables iden-
tified in a Work Breakdown Structure (WBS). The more detailed the WBS becomes as the project
matures, the more accurate the estimate becomes. The base estimate can be defined as an esti-
mate including allowances, but excluding escalation, foreign currency exchange, contingency
and management reserves (AACE, 2014).
The estimate consists of many different cost elements, depending on the scope of work and type
of project. It includes all equipment, materials and labour required to execute the scope of work,
also considering the execution approach and schedule. Cost elements to be considered can be
split up in direct and indirect cost (Burke, 2003):
• Direct cost. These are costs that can be directly allocated to a specific scope of work or an
activity. For example:
– Equipment and material cost.
– Cost of project management team.
– Direct labour cost, like scaffolding, welders, fitters etc.
– Direct expenses, such as 3rd party services or sub-contractor fees.
• Indirect cost or overhead cost. These are costs not directly attributable to the completion of an
activity, which are typically allocated or spread across all activities on a predetermined basis
(AACE, 2014). For example:
– Field in-directs during construction, such as field administration, supervision, capital tools,
start-up costs, etc.
– Company overhead cost, like senior management, IT, human resource department, finance,
etc.
– Training cost, depreciation, insurance, taxes…etc.

The cost elements may be estimated using different estimating techniques depending on the
level of scope definition and the size and complexity of the project.

Allowances
As part of the base estimate and on top of the base cost, allowances can be added to cover lack
of scope detail or the ‘known unknowns’. Below are some examples that are typically included in
estimates as allowances:

182

925836-02_200_17-Feb-15_08:43:46_walter
the scene and money at work

• Design allowances for engineered equipment


• Material Take Off allowances, to cover differences between actual and calculated quantities
• Material inefficiencies, cutting and waste allowance
• Rework
• Non-productive construction time (poor productivity)
• Weather conditions

Contingency
Contingency is added to the cost estimate to cover the uncertainty and variability associated
with a cost estimate, and unforeseeable elements of cost within the defined project scope (AACE,
2013). Contingency covers inadequacies in project scope definition, estimating methods and
estimating data. The amount of contingency included in the estimate should be determined, as
well as the method used to derive the appropriate amount.
Contingency is typically estimated using statistical analysis or judgment based on past asset or
project experience. Contingency usually excludes:
• Major scope changes such as changes in end-product specification, capacities, building sizes,
and location.
• Unforeseen major events such as earthquakes, labour strikes, etc. Management reserves (addi-
tional budget to be allocated at management’s discretion).

The amount of contingency to add to the base estimate is usually related to the required confi-
dence level of an estimate. Management can for example choose for a certain confidence level to
fund a project. Most cost estimates have a P50 confidence level, which means that the amount of
contingency added to the base estimate results in a 50/50 chance to either overrun or underrun
budget.

In case a probabilistic risk analysis technique is applied to the base cost (see also Chapter 8), the
probability of achieving a certain point estimate can be determined. A Monte Carlo simulation
is the most commonly applied technique to analyse the impact of risks and uncertainties on
project cost and schedule. The simulation not only calculates the probability of achieving a cost
estimate, but it also calculates the associated required amount of contingency. It therefore uses a
cost estimate without any contingency as a starting point for the simulation (AACE, 2011).

Normally only the high risks are used for the simulation. Each risk is quantified by determining its
likelihood of occurring and potential cost impact. In more traditional approaches the impact of a
risk on the estimate is represented by a three-point estimate, resulting in a triangular distribution
as explained in Chapter 8.

According to Figure 10.2 there is a 30 % probability to achieve the base estimate (X). By adding
contingency C1 to the base estimate, the confidence level of the estimate (Y) increases to 50 %,
also called the P50 estimate. By adding even more contingency to the base estimate, for example
C2, the confidence level increases to 80 %, also called a P80 estimate. Sometimes part of the con-
tingency is allocated as a management reserve which is not freely available to the project team,
but instead will be allocated by management.

183

925836-02_201_17-Feb-15_08:43:49_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

Confidence level

Base estimate +
contingency C2
80%

Base estimate +
50% contingency C1

Base estimate +
30%

C1 C2

0%

X Y Z Cost estimate (€)

Figure 10.2: Estimate probability distribution curve

As contingency is related to uncertainties and risks, it is also possible to run down contingencies
in case specific risks do not materialise during project execution. An example: the material selec-
tion for a gas treatment plant depends on the specific composition of the gas produced by new
wells. This risk has been identified in the risk assessment and has been included in the overall
contingency. After drilling the new wells it turns out that the gas composition allows for cheaper
material to be applied. In that case the remaining contingency required till project completion
can be lowered and associated budget can be freed up for other investments.

Escalation
Escalation is a provision in costs or prices for uncertain
changes in technical, economic, and market conditions over
time (AACE, 2014). It is important to consider this ‘time value
of money’, since it can have an impact on purchasing power
and earning potential. The two main components of escala-
tion are inflation (or deflation) and market factors. Inflation
is the rate at which the general level of prices for goods and
services is rising over a certain period of time in an econ-
omy. It reflects the future value of money. Market factors
reflect future market developments that, for example, can
influence equipment and material prices.

Figure 10.3 shows the main components of a capital cost


estimate.

Figure 10.3: Capital cost estimate

184

925836-02_202_17-Feb-15_08:43:49_walter
the scene and money at work

The capital cost estimate as presented is also referred to as the Total Installed Cost, or Total
Capital Investment. The capital estimate is an important input for the project economics as
explained in Chapter 11.

Now that the estimate classes, structure and main elements have been defined, the most com-
mon cost estimating methodologies are described.

10.2.4 Cost estimating methodologies


Selecting the appropriate cost estimating methodology starts by determining the required level
of accuracy of the estimate. This depends on the purpose of the estimate in a specific project
phase and the available level of project definition. In this paragraph four common cost estimating
methodologies are described. Depending on the available project definition these methodolo-
gies include a stochastic or deterministic approach (AACE, 2011).

Stochastic methods are often applied during the early project development phases, making use
of estimating factors, metrics and models. For example, multiplying a (statistical) factor with
equipment cost to calculate the total installed cost of a specific piece of equipment. It can be
used for class 3 to 5 estimates, ranging from screening to budget estimates.

Deterministic methods are usually applied at a later stage when more scope detail is available
(control or tender estimates). In practice it is possible to end up with a mix of these estimating
methodologies in the same estimate, depending on the level of detail available for specific parts
of the scope.

Four common estimating methodologies are briefly explained (Lester, 2014) (Burke, 2003).

Subjective
This methodology, sometimes called ‘guestimating’, is applied to provide a ‘ballpark figure’ at the
early stages of a project. As there is no detailed information available yet, the accuracy of the
estimate strongly depends on the estimator’s experience of similar projects.

As an example the Lang Factor can be applied, being the ratio of the total cost of installation, or
Total Installed Cost, to the cost of its major technical components. This factor is widely used in
the process industry to help estimate the cost of new facilities. A typical Lang Factor for a new
chemical unit would be in the range of 3.0 to 5.0. This means that the sum of all major equipment
multiplied by a factor 3.0 to 5.0 gives a rough estimate of the total installed cost of the plant,
including equipment, materials, construction and engineering.

Analogous
The analogous method, or comparative method, is using similar past projects to estimate the cost
of a new project. It is applied when there is not sufficient data available to generate a detailed
estimate yet, but sufficient technical definition to make adjustments of estimates made for sim-
ilar projects. It is preferred to use quantifiable changes and apply factors to make the estimate
adjustments, for example using scaling factors.

185

925836-02_203_17-Feb-15_08:43:49_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


In the early phases of the wind farm project, an analogous or comparative cost estimate
could be made, based on similar offshore wind farms that have been built around the
world. Even local data could be obtained from the existing wind farm located next to the
selected location of the project.
Although the technical complexity of wind farms seems to be relatively low, compared to
for example chemical plants, there can be many differences between wind farm projects.
To provide a proper analogous estimate, the following technical and execution aspects,
amongst others, could be analyzed to make justifiable changes to estimates of similar
projects:
• Seabed conditions and water depth (could lead to different soil preparation and subsea
foundation)
• Weather conditions (impact of wind profile and sea state on design and construction
time)
• Distance to nearest port
• WTG size and technical novelty
• Distance to onshore power grid
• Power cable routing (buried, drilling, crossing pipelines/cables, sensitive areas…etc)
• Local opposition against the project (could impact permitting duration)

Parametric
Parametric estimating, also called factoring or component ratio method, is a technique that develops
cost estimates based upon the examination and validation of the relationships between a project’s
technical, programmatic, and cost characteristics as well as the resources consumed during its devel-
opment, manufacture, maintenance, and/or modification (ISPA, 2008). These relationships are known
as the Cost Estimating Relationships (CERs). Parametric models range from simple to very complex,
depending on the number of CERs and the complexity of the algorithms used.
CERs can be based upon many different parameters like functional design parameters, quantities
of equipment, hardware sizes and weight or operational environment, for example onshore ver-
sus offshore.

Analytical
The analytical method, also referred to as the detailed or engineering build-up method, is typi-
cally applied to generate the control estimate or a ‘bid’ estimate required by a contractor before
submitting a bid. It is the most accurate, deterministic estimating method, and it requires the
project to be broken down to the lowest WBS level. For each individual component the material
and labour cost are then estimated and the sum of all pieces, including overhead, becomes the
project estimate. The analytical method can be time-consuming and requires close cooperation
between the cost estimator and the engineers who have developed all the details including the
part lists, bill of material etc.

186

925836-02_204_17-Feb-15_08:43:52_walter
the scene and money at work

Front End Loading (FEL) Execution

Increasing estimate accuracy

Subjective Analogous Parametric Analytical

From stochastic to deterministic

Figure 10.4: Estimate accuracy development

Figure 10.4 illustrates the development of the cost estimate accuracy and estimating method as the
project matures from Front-End-Loading (FEL) to Execution. It also shows that the Subjective and
Analogous methodologies are typically applied in the early project phases, while the Parametric
and Analytical methodologies are used when there is a better project definition.

Human aspect
It is critical for an estimator to understand that estimating is not an activity to be performed in
splendid isolation. Understanding the project scope and assuring all project team members pro-
vide the right input, requires a very proactive and open approach. There needs to be a two-way
communication enabling the estimator to have a full understanding of the basis of estimate,
while the other project team members develop an understanding of the impact that their specific
scope or execution method has on the cost estimate. It should be an ongoing dialogue, start-
ing early in the project development phase to avoid misalignment amongst stakeholders and
unpleasant surprises when releasing the estimate. The discussed and agreed scope and execu-
tion assumptions need to be written down in a Basis of Estimate document.
It is also important to realise that stakeholders have different interests in the project and poten-
tially will try to influence the cost estimate or the way it is presented. For example, a business
manager is interested in submitting a competitive bid, aiming at winning a tender, so she will
push for a lower estimate. A project manager wants to deliver his/her project within budget, so
she will push for at least a realistic estimate, but perhaps even some additional pocket money.
Similar pressure can be experienced when classifying specific cost. Some would like to classify
training cost for operations as OPEX, while others would classify it as CAPEX. There are also
examples of estimates being decreased to an acceptable level by management to obtain project
sanctioning, resulting in a high chance of overrunning the approved budget.

187

925836-02_205_17-Feb-15_08:43:52_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

10.3 ! Planning and scheduling

10.3.1 Introduction
As already explained in Chapter 1, a project lifecycle exists of a number of distinct phases. In
each project phase many activities are taking place and many deliverables are produced. To
control the planning and execution of a project, all scope and activities need to be broken down
into manageable activities, linked to a WBS as explained in the previous paragraph. The WBS
forms the basis for compiling a schedule and brings scope, cost and schedule together. The WBS
work packages can be broken down into lists of activities and events that form the basis for the
project schedule. For each activity and event the predecessors, successors and the duration are
defined and these interdependencies can be graphically displayed in a network planning. Next
the network planning can be analysed to optimise the work sequence and project duration. Not
all activities need to be scheduled at the same level of detail. It depends on the specific risk of an
activity or work package and the level of control required.
There are many books written on how to create a network planning, explaining the different
techniques in detail. The following part is only meant to give a high-level overview of the most
common techniques, followed by an introduction into Gantt charts as a commonly applied
method for schedule representation.

10.3.2 Network Planning


A network planning shows the logical sequence of project activities and the transfer points from
one activity to another. There are two basic formats to draw a network:
• Activity-On-Arrow (AOA): activities are displayed as arrows and nodes represent the event or
transition between the activities. Nowadays AOA is often referred to as Arrow Diagramming
Method (ADM).
Activity Activity

Activity Activity

Figure 10.5: Activity-On-Arrow example

• Activity-On-Node (AON): activities are presented as nodes (rectangles or circles) and arrows
are representing their relationships.

Activity 2

Activity 1 Activity 4

Activity 3

Figure 10.6: Activity-On-Node example

188

925836-02_206_17-Feb-15_08:43:55_walter
the scene and money at work

In general the AON format seems to be favoured over the AOA format, as it has some graphical
advantages which make it easier to analyse and optimise the network.
There are two well-known network planning techniques, commonly used in projects:
• Program Evaluation and Review Technique (PERT)
• Critical Path Method (CPM)
Both techniques will be briefly explained.

Program Evaluation and Review Technique (PERT)


The PERT method was developed in the 1950s for the United States Navy. It was designed to ana-
lyse and represent the tasks involved in completing a project, using the AOA representation of
activities and relationships. It is a probabilistic methodology aiming at determining the minimum
time needed to complete the entire project.
The PERT method is usually applied on large-scale, non-routine projects, in conjunction with the
Critical Path Method (CPM). PERT differs from the CPM, because it uses a probabilistic approach
instead of adding up durations of critical activities to establish the critical path.
In the original PERT approach an estimate of the pessimistic (P), optimistic (O) and ‘most likely’
(M) duration is made for each activity. The expected duration of each activity is then calculated as
a weighted average of these three durations (O + 4M + P)/6. The most likely duration is weighted
four times as much as the other two values.

Critical Path Method (CPM)


CPM was developed around the same period as PERT and is commonly used in all kinds of
projects to determine the critical path of a project and to assess float or slack in non-critical
activities. It uses the AON representation of activities and relationships. The critical path consists
of continuous successive activities that determine the minimum overall project duration. Float is
the amount of time an activity may slip upon commencement and completion before becoming
critical. By definition there is no float on a critical path, so any delay in the critical activities will
directly impact the overall project duration accordingly. On complex projects there are often
multiple (almost) critical paths running in parallel.
Nowadays the Precedence Diagram Method (PDM) is often applied to analyse the critical path,
using the AON format to display the network planning. The PDM will be explained in more detail,
using a simplified example of the wind farm case.

Precedence Diagram Method (PDM)


PDM, based on the Activity On Node (AON) method, shows activities as nodes and the relations
between the activities as arrows connecting the nodes. The nodes can be displayed as boxes
(Figure 10.7), including activity name, start and finish dates, duration and float.

Activity: Short description of activity (possible to refer to WBS)


ES Duration EF Duration: Estimated time to complete the activity
ES: Earliest start
Activity EF: Earliest Finish
LS: Latest Start
LF: Latest Finish
LS Float LF Float: LS - ES

Figure 10.7: AON node format for PDM

189

925836-02_207_17-Feb-15_08:43: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

In projects it is common to have many complex relationships between the activities. There can
be specific start and finish restrictions like:
• Finish to Start: this is the most straightforward restriction, dictating that an activity cannot start
before its predecessor has been completed.
• Start to Start: an activity cannot start before its predecessor has started.
• Finish to Finish: an activity cannot be completed until its predecessor has been completed first.
• Start to Finish: an activity can only finish after the predecessor activity has started. So the pre-
decessor must start first and then the successor can finish. This restriction does not appear
very often, since there are usually easier ways to describe the relationship.

Usually there are also lead and lag times between activities. A start-to-start lag for example,
determines the minimum amount of time that must pass between the start of an activity and the
start of its successor.
Next PDM will be explained looking at a simplified example for the wind farm case.

The Wind Farm


In the table below some key activities of the wind farm project are listed, including their
duration and predecessors. As explained in the table, there are some execution restrictions
due to the limited availability of vessels. WTG testing can be performed in parallel with the
WTG installation, starting 3 months after the start of WTG installation (a Start-Start relation,
with a lag of 3 months).

Table 10.2: Network activities ‘Wind Farm’

No. Activity Duration (months) Predecessors Comments

1 Soil investigation 3

2 Wind study 3

3 Design foundation 3 1

All foundations will


be fabricated and
4 Fabricate foundations 9 3 delivered as one
batch before start of
installation

5 Soil preparation 12 3

Can only start after


completing the soil
6 Install foundations 9 4, 5
preparation, due to
vessel availability

WTG: Wind Turbine


7 Design WTG 6 2
Generator

190

925836-02_208_17-Feb-15_08:43:58_walter
the scene and money at work

Fabricate and Test


8 15 7
WTG’s

Can only start


after installing all
9 Install WTG’s 9 6, 8
foundations, due to
vessel availability

Testing can start 3


months after starting
10 Test WTG’s 7 9 the WTG installation
(Start-Start, lag +3
months)

The following network can be drawn using the AON format and connecting all activities
to their predecessors.

6 12 18
Soil preparation

6 0 18
0 0 3 3 3 6 18 0 27
Soil investigation Design foundations Install foundations

0 0 3 3 0 6 18 0 27 27 0 36 30 0 37 37 0 37
6 9 15
0 0 0 Fabricate Install WTG’s Test WTG’s End
foundations
Start 27 0 36 30 0 37 37 0 37
9 3 18
0 0 0

0 3 3 18 0 27 9 15 24 lag + 3 months
Wind study Design WTG Fabricate and test WTG’s

3 3 6 18 0 27 12 3 27

Figure 10.8: AON ‘Wind Farm’ network

A forward pass analysis will determine the early start and early finish of each activity. First
determine the ES and EF for activities at the beginning of the network (Soil investigation
and Wind study), next determine the ES and EF of the other activities following the
network relations from left to right.
To determine the latest start and latest finish of each activity, a backward pass analysis
has to be performed. The backward pass starts with determining the LS and LF of the last
activity (Test WTG’s) on the right, to then determine the LS and LF of all predecessors
following the network relations from right to left.
From the analysis it becomes clear which chain of activities determines the overall
duration, being the critical path (dark blue activities and blue arrows). In this case it takes
37 months to design and construct the Wind Farm.
For all activities the float can be calculated, being the difference between LS and ES.
For example ‘Fabricate foundations’ has a float of 3 months. So the fabrication could be
delayed by 3 months and still finish on time to start the installation of the WTG’s.

191

925836-02_209_17-Feb-15_08:44:01_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

To complete the example, one simple change is made. After 5 months of soil preparation
an additional vessel becomes available. The installation of the foundations could now
start after 5 months of soil preparation instead of 12 months. Unfortunately the additional
vessel cannot be used to install WTGs due to limited lifting capacity.

The Wind Farm


The only change made is the relation between ‘Soil preparation’ and ‘Install foundations’.
The relation has changed from a ‘Finish to Start’ to a ‘Start to Start’ relation with a lag of
5 months. All durations remain unchanged.
The updated network planning is shown below.

6 12 18
Soil preparation

10 4 22
0 3 3 3 3 6 15 9 24
Soil investigation Design foundations lag + 5 months Install foundations

0 0 3 3 0 6 15 0 24 24 9 33 27 7 34 34 0 34
6 9 15
0 0 0 Fabricate Install WTG’s Test WTG’s End
foundations
Start 24 0 33 37 0 34 34 0 34
6 0 15
0 0 0

0 3 3 3 6 9 9 15 24 lag + 3 months
Wind study Design WTG Fabricate and test WTG’s

0 0 3 3 0 9 9 0 24

Figure 10.9: Updated AON ‘Wind Farm’ network

Now that the soil preparation is not on the critical path anymore, the overall project
duration is reduced to 34 months. However almost all activities are critical now which
probably indicates that the chance of meeting the 34 months is smaller as there is no float
left in the schedule, except for the soil preparation. It would require a proper schedule risk
analyses and cost/benefit analysis to decide if it is worth investing in the additional vessel.

As shown in the example, a simple adjustment can easily change the network analyses, resulting
in a different critical path and overall duration.
Next a commonly used method to present a schedule is described, being the Gantt chart.

10.3.3 Gantt chart


The first bar chart was developed by a Polish engineer Karol Adamiecki in 1896. In the early 20th
century Henry L. Gantt introduced the Gantt chart, a time-scaled bar chart, to the western world.
It is a way to display the WBS and additional planning information in an easy-to-understand
manner. Activities are represented by straight horizontal bars and, depending on their start and
finish date, plotted against a calendar normally shown at the top. The relationships between the
activities can be displayed as well.

192

925836-02_210_17-Feb-15_08:44:01_walter
the scene and money at work

Qtr 1 2015 Qtr 1 2016 Qtr 1 2017 Qtr 1 2018


ID Task Name Duration Predecessors
jan may sep jan may sep jan may sep jan may sep jan may

1 Wind Farm 740 days

2 Soil investigations 3 mons

3 Wind study 3 mons

4 Design foundation 3 mons 2

5 Fabricate foundations 9 mons 4

6 Soil preparation 12 mons 4

7 Install foundations 9 mons 5; 6

8 Design WTG 6 mons 3

9 Fabricate and test WTG’s 5 mons 8

10 Install WTG’s 9 mons 7; 9

11 Test WTG’s 7 mons 10SS+3 mons

Figure 10.10: Gantt chart example Wind Farm

It is also possible to show progress per activity for example by colouring the baseline or drawing
a progress bar underneath the activity bar. By combining all this information in an easy-to-read
chart, management can have a good impression of the project at a glance.

Gantt charts can also be used to allocate resources to the activities. They can then be used to
analyse and optimise resources and create a fully resource loaded schedule, showing all required
disciplines and contractors over time. A common way to display resources over time is a histo-
gram. In Figure 10.10 a Gantt chart example for the wind farm case is shown.

The figure represents all activities and their relationships by bars against a timeline on the top.
The actual progress is shown as progress bars inside the activity bars and the critical path shows
up in dark blue.
Nowadays most Gantt charts are generated automatically by planning or scheduling software
like Microsoft Project or Primavera.

10.3.4 Probabilistic Scheduling


Similar to probabilistic cost estimating, probability distributions can be linked to the duration of
scheduled activities, depending on the uncertainty of these durations.
Nowadays it is also possible to combine the probabilistic cost and schedule analysis in the same
Monte Carlo simulation (see Chapter 8). It provides insight in the likelihood of meeting both pro-
ject cost and schedule, by analysing the cost and schedule impact of the identified risks.

The analysis requires a detailed, resource loaded schedule, including all work to be completed
and unbiased, most likely durations. The purpose of resource loading the schedule is to allocate
the entire ‘contingency-free’ budget to the scheduled activities. Experience shows that schedules
of 300 to 1000 activities can be used in the risk analysis. The number of risks is typically around
20 to 40.

193

925836-02_211_17-Feb-15_08:44:01_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

Monte Carlo Result – Cumulative Probability

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

Cost (€) / schedule (wks)

Figure 10.11: Cumulative probability curve

For each schedule risk the likelihood of occurring and the potential impact needs to be defined,
similarly to the cost risk as explained in Paragraph 10.2.3.

Next a Monte Carlo simulation will generate a great number of iterations, combining many
different cost and schedule impacts depending on their likelihood of occurring. This results in
probability distribution curves for both cost and schedule as shown in Figure 10.11.

Human aspects
Similar to cost estimating, scheduling requires a proactive approach to ensure all relevant inputs
are captured and that there is a good understanding of the execution assumptions and schedule
risks. Often reference is made to the difference between a ‘scheduler’ and a ‘planner’. A sche-
duler works in isolation and is very good at putting all activities in a scheduling software tool
to develop a ‘technically’ sound schedule. A planner continuously interfaces with all relevant
stakeholders to fully understand the phasing, priorities, execution approach, schedule risks and
underlying assumptions.

Also schedules are being influenced by stakeholders depending on their specific drivers. Some
stakeholders will have an interest to deliver the project as soon as possible, while a project mana-
ger would like to have a realistic schedule, taking into account specific schedule risks.

It is also not uncommon that some ‘wishful thinking’ creeps into the schedule during the early
development phases. When the project scope is not well developed yet and not all related sche-
dule risks are known, people tend to be too optimistic.

194

925836-02_212_17-Feb-15_08:44:04_walter
the scene and money at work

10.4 ! Cost and schedule control

10.4.1 Introduction
A project needs to have appropriate controls in place to make sure it is completed against the
agreed targets. Besides safety performance, risk management, quality and stakeholder satis-
faction, these have been described in other chapters, the key aspects to control are cost and
schedule.
Project control includes the following primary steps:
• Perform project planning, including establishing project cost and schedule baselines
• Measure project performance
• Compare measurements against the project plan and baselines
• Take corrective actions as may be determined through forecasting and further planning.

In essence it comes down to applying the well-known Deming circle; Plan, Do, Check, Act
(PDCA-circle).

10.4.2 Project Controls Plan


It is common to write a ‘project controls plan’ in which the above steps are described in more
detail. Depending on the size and complexity of a project, the project controls plan can also be
included in the overall project execution plan. A project controls plan typically includes:
• Project controls organisation (organisation chart, roles and responsibilities)
• Project planning, key milestones
• Project scope and execution strategy
• Schedule development and resource planning
• Cost estimating and budgeting
• Risk management
• Cost control
• Progress and performance measurement
• Forecasting
• Change management
• Project reporting

Sometimes additional topics, like document control or auditing, can be included, depending on
the tasks assigned to the project controls team.
It is also important to realise that there are possibly multiple contractors involved in the exe-
cution of the project, all performing their own project controls and reporting. Therefore large
complex projects require an integrated project controls plan that clearly describes the interfaces
with all contractors involved.
Another important aspect of project control is ‘management of change’. A project requires a for-
mal process to identify, assess and approve changes to the approved project plan and to capture
the impact on schedule and cost.
Next the basis of schedule control, cost control and management of change will be explained.

10.4.3 Schedule control


The first step is to establish a baseline schedule. This is normally the schedule that, together with
the project plan and baseline cost estimate, is authorised at project sanctioning. Although it is

195

925836-02_213_17-Feb-15_08:44:04_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

very well possible that more detailed execution schedules will be developed after sanctioning,
schedule performance will be measured against the approved milestones.

The schedule is based on the WBS and progress will be monitored for the individual WBS ele-
ments. The level of schedule detail for each element and the WBS level at which progress is
measured, depends on the complexity of the scope and schedule risks. For example applying
a new technology which is on the critical path of your project requires more rigorous progress
monitoring than a routine task with significant float.

To measure progress it is important to be able to measure real progress, or physical progress.


Physical progress is the percentage of work scope completed at a certain date. It is determined
by using predefined, objectively measurable achievements, like the number of completed engi-
neering documents, or meters of pipeline installed. To determine the overall project progress,
weighting can be applied to different WBS elements to reflect their relative contribution to the
physical progress.

In a complex project there may be many parties involved in providing progress data. Contractors
involved will normally monitor and report progress for their specific scope of work. The project
planner must check and integrate all progress data to determine the overall project progress. The
amount of involvement of the owner’s planner also depends on the type of contracts. A lump
sum turnkey contract requires less involvement from the owner than managing a reimbursable
contract.

During project execution it can be decided to re-baseline the schedule if the original baseline
schedule has become obsolete due to changes. If there are major changes of the project scope,
or the actual progress deviates significantly from the original baseline schedule, it can be decided
to establish a new baseline to measure progress. A need to re-baseline often results from poor
project definition and/or poor project control. Reassessment of the project control process going
forward is typically an element of re-baselining (AACE, 2014).

Besides monitoring progress and measuring schedule performance against the baseline, it is also
common practice to forecast the remaining project duration.

10.4.4 Cost control


AACE International defines cost control as ’the application of procedures to monitor expendi-
tures and performance against progress of projects or manufacturing operations; to measure
variance from authorised budgets and allow effective action to be taken to achieve minimum
costs’ (AACE, 2014).
During the early project development phases, prior to formal project sanctioning, cost control
basically comes down to managing all cost related to studies, design and engineering, owners
team and other third party services. As soon as a final investment decision has been taken and
there is an authorised budget to deliver the project, cost control becomes more advanced.

The first step is to establish a baseline estimate, usually being the authorised budget at project
sanctioning. The cost performance will be measured against the initially authorised budget and
any budget changes that were approved during project execution.

196

925836-02_214_17-Feb-15_08:44:07_walter
the scene and money at work

The level of detail at which cost control needs to be performed, depends on the specific scope of
work and associated risk. Since the cost estimate is broken down according to the WBS elements,
it can be decided for each element how to perform cost control and which supporting data to
collect. For example a low risk WBS element being executed under a lump sum contract (see
Chapter 9 for further explanation about contract types) requires less stringent cost control than
high risk scope being executed on a reimbursable basis.

Since the same WBS activities and deliverables as included in the cost estimate are also in the
schedule, the cost (CAPEX) phasing over time can be determined. The cost phasing can be visual-
ised in a typical S-curve, also often used for cost control and reporting.

Cumulative cost

S-curve

Time

Figure 10.12: Cost S-curve

Besides an S-curve presenting cumulative cost over time, many different S-curves are used
for project control and reporting. For example showing actual man hours, earned man hours,
installed quantities or resources over time.
Next a commonly used integrated cost and schedule method will be described, the Earned Value
Analysis.

Earned Value Analysis


Earned Value Analysis (EVA) is a quantitative method for evaluating project performance and
predicting final project results, based on comparing the progress and budget of work packages
to planned work and actual costs. The advantage of EVA is that both cost and schedule perfor-
mance can be analysed using one method based on cost or monetary value.

To explain the EVA method some key terms need to be defined (Dierick & Van Biezen, 2009).

• The Earned Value (EV) of a work package, or the whole project, equals the sum of budgeted
cost of the work performed to date. EV is also called the Budgeted Cost of Work Performed. So
EV is not the same as the actual cost of work performed.

197

925836-02_215_17-Feb-15_08:44:07_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 Planned Value (PV) equals the sum of budgeted cost of the work scheduled to date, also
called Budgeted Cost of Work Scheduled.
• Actual Cost (AC) is the sum of all actual cost to date, also called Actual Cost of Work Performed.
• Actual Time Spent (ATS) is the total duration from start to date.
• Budget At Completion (BAC) equals the sum of all budgeted cost till the end of the project.
• Time At Completion (TAC) is the planned overall duration from start till end of the project.

The definitions above can be used to analyse cost and schedule performance in the following
manner.
To analyse schedule performance the Schedule Variance (SV) or Schedule Performance Index
(SPI) can be determined. Both measures indicate whether the project runs ahead or behind
schedule.
• SV = EV – PV (positive number: ahead of schedule, negative number: behind schedule)
• SPI = EV/PV (number > 1: ahead of schedule, number < 1: behind schedule)

The cost performance can be analysed looking at the Cost Variance (CV) or Cost Performance
Index (CPI). Both measures indicate whether the project runs over or under budget.
• CV = EV – AC (positive number: under budget, negative number: over budget)
• CPI = EV/AC (number > 1: under budget, number < 1: over budget)

Next the overall project duration and cost can be forecasted, taking into account the project
performance to date.

The Estimated Time at Completion (ETAC) provides a forecast of the overall project duration,
taking into account the schedule performance to date.
• ETAC = TAC/SPI (a SPI > 1: forecasted duration shorter than planned, SPI < 1: forecasted dura-
tion longer than planned)
From the ETAC the Estimate To Complete (ETC) can be derived, being the remaining forecasted
time to complete the project.
• ETC = ETAC – Actual Time Spend (ATS)

The Estimated Cost at Completion (ECAC) gives a forecast of the total cost at completion of the
project, taking into account the cost performance to date.
• ECAC = BAC/CPI (a CPI > 1: forecasted cost at completion under budget, CPI < 1: forecasted
cost at completion over budget)
From the ECAC the CTC can be derived, being the remaining cost to complete the project.
• CTC = ECAC – Actual Cost (AC)

The importance of using Earned Value in the performance analysis will be illustrated by a simple
example, in which the contribution of the activities to the overall progress is weighted equally.

198

925836-02_216_17-Feb-15_08:44:10_walter
the scene and money at work

EVA example
The table below shows the planning of 5 activities over 10 months,
including the budgeted cost and planned spent per month for each activity.

Table 10.3: Activity planning and cost

Time (months) To date


Cost 1 2 3 4 5 6 7 8 9 10
Activity 1 € 5.000 5k
Activity 2 € 10.000 10k
Activity 3 € 25.000 5k 20k
Activity 4 € 75.000 5k 10k 15k 25k 15k 5k
Activity 5 € 10.000 5k 5k

The cumulative cost curve is shown below.

Cum. Planned Value € 120,000


Cum. Earned Value
Cum. Actual Value € 100,000

€ 80,000

€ 60,000

€ 40,000

€ 20,000
Figure 10.13:
Cost curve EVA 0
0 2 4 6 8 10
example
Months

For each activity the EV is calculated, using the actual % complete.


The table below shows the % complete, EV, PV and Actual Cost.

Table 10.4: EVA calculations

% complete EV PV AC
Activity 1 € 5.000 100% € 5.000 € 5.000 € 4.000
Activity 2 € 10.000 100% € 10.000 € 10.000 € 12.000
Activity 3 € 25.000 75% € 18.750 € 25.000 € 15.000
Activity 4 € 75.000 10% € 7.500 € 15.000 € 7.500
Activity 5 € 10.000 0% € - €-
€ 125.000 € 41.250 € 55.000 € 38.500

199

925836-02_217_17-Feb-15_08:44:13_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 project schedule and cost performance can now be calculated:


• SV = 41,250 – 55,000 = -13,750 (running behind schedule!)
• SPI = 41,250 / 55,000 = 0.75
• CV = 41,250 – 38,500 = 2,750 (budget underrun)
• CPI = 41,250 / 38,500 = 1.07

So although the project is running behind schedule, the cost performance looks positive.
The schedule and cost forecast can also be calculated:
• ETAC = 10 / 0.75 = 13.3 months
• ECAC = 125,000 / 1.07 = € 116,667

Looking at the EVA analysis management might decide to take measures to reduce the sche-
dule delay. Obviously this depends on the project’s value drivers and possibilities to speed up the
work. Adding more people to the job or introducing double shifts might be a solution, but will
come at a cost.

10.4.5 Management of change


From the early phases onwards it is critical to manage project changes adequately to avoid
scope creep, schedule delays and cost increases. Normally there is an approved project baseline
against which changes are being assessed and formally approved before implementation. Some
examples of changes are change of original business premises, additional safety or operational
requirements, change of execution plan etc. Depending on the change there can be several
disciplines, or even contractors, involved in assessing the impact of the change.
For most projects it is common to have a formal change management process to identify,
assess and approve changes to the project plan and to capture the impact on schedule and cost.
Depending on the impact of a change, project management or a more senior level approves the
implementation of the change.
To assess the cost impact, it is important to differentiate between changes due to already iden-
tified uncertainties and unexpected scope changes. The first category is likely already included
in the contingency and therefore does not require additional budget. If the change concerns
unforeseen additional scope, the budget needs to be raised.

Human aspect
Similar to the previous paragraphs on the human aspect, there are many stakeholders with differ-
ent interests when it comes to controlling a project. Just a few examples to illustrate situations
that have occurred in practice:
• Management decreasing the baseline cost estimate to have a project sanctioned.
• A construction contractor reporting more construction progress than is actually made to meet
a project milestone and receive an incentive fee.
• A project manager forecasting the overall project cost too optimistically to positively influence
his appraisal.
• An engineering contractor not making any effort to improve the engineering efficiency, aiming
to maximise the engineering man hours under a reimbursable contract.

200

925836-02_218_17-Feb-15_08:44:13_walter
the scene and money at work

It requires an experienced project team to recognise these different interests, and challenge the
data received for cost and schedule control.
Another known issue is the fact that most people are too optimistic about project execution
and resolving problems along the way. This often results in significant ‘wishful thinking’ when
forecasting project duration or the overall project cost. It takes experience to recognise these
situations and avoid over-optimistic estimates and schedules.
Management of change requires discipline from the project team and other parties involved.
All parties involved need to follow the formal change management process and all relevant
disciplines need to assess the impact of the change. It happens in practice that, due to time
pressure, changes do not follow the formal change process, which can lead to unsafe situations
or unpleasant schedule or cost surprises later on. A common reason not to follow the change
management process is simply because it is taking too long. Especially during construction there
is not much time to wait for the formal approval of a change before implementation. Therefore it
is key to structure the process such that the turnaround time is as short as possible, and at least
the relevant disciplines have reviewed a change prior to formal approval.

10.5 ! Progress reporting


In practice there are many different reports for many different purposes and audiences. Some
examples are listed below:
• Weekly internal project highlights
• Monthly progress reports
• Project portfolio updates
• External progress reports for investors and partners
• Management dashboards

Various stakeholders need to be informed and might ask for different information. Depending
on their interest and management level, the specific information, aggregation level and report-
ing frequency can vary. It also depends on the project development phase, because progress
reporting can become much more complex as the number of external parties increases towards
execution.

Many project teams consider progress reporting as a burden that not necessarily adds any value
to the project. Especially the sometimes many ad hoc requests for information or progress data
are disrupting the day-to-day project activities. Besides disruption, this ad hoc reporting can eas-
ily lead to mistakes or the provision of incomplete information. On top of that this information
could start to ‘live its own life’, being used and presented by stakeholders in their own interest.
The trick is to produce one simple, formal progress report that satisfies most of the stakeholders.
However there can still be good reasons to compile tailor-made reports, but always using the
same data as included in the formal progress report. Ad hoc requests should be minimised to
limit the additional reporting burden of the project team at any time.

The positive thing about reporting is that it requires the project team and third parties to fre-
quently review project performance and to update the cost and schedule forecasts. It forces
communication between all parties to first collect the required progress data and next to explain
project performance and required recovery measures to the various stakeholders.

201

925836-02_219_17-Feb-15_08:44:14_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

Figure 10.14: Example of a progress report of the Wind Farm Energy Polder

202

925836-02_220_17-Feb-15_08:44:16_walter
the scene and money at work

Progress reports can also have a contractual purpose, for example to formally document approved
scope changes or to document the status of earned incentives. The reports could even end up in
court, in case a claim needs to be settled after project completion.
The data and information in the progress report needs to be highly reliable as the project team
and other stakeholders must be able to take decisions based on this report. Example: A pro-
ject manager decided to introduce working shifts to catch up, following a progress report that
showed a poor construction progress. Two months later it turned out that there was a significant
delay in collecting and reporting construction progress data and that the actual
Construction progress was even ahead of schedule. Accurate progress reporting could have
prevented the additional cost of working shifts.
A progress report typically includes the following topics:
• Management summary
• HSE performance
• Project Key Performance Indicators (KPIs)
• Key risks and mitigation actions
• Schedule
• Cost control
• Quality
• Engineering
• Contracting and Procurement
• Construction
• Commissioning and Start-up
• Scope changes

For schedule and cost most reports include progress and cost curves, showing the planned,
actual and forecasted data. An example of a typical monthly progress report for the Wind Farm
project is given in Figure 10.14.

Human aspect
The quality of a progress report strongly depends on the competencies of the project controls
team and their understanding of the scope and execution. The team must be able to challenge
the received data and information and should understand how to integrate it into one overall
progress report. The project manager should take full ownership of the progress report, being
able to explain all information included.
For the project controls team it is important to realise that informal communication can be as
important as formal communication. For example a cost controller who really connects with
the project team, who understands the scope of work and knows what is going on during con-
struction, can fulfil his role much more proactively than a cost controller sitting behind his desk
all day.

The way progress is being presented and communicated can be influenced by many parties. A
project manager can benefit from presenting a success story, while a contractor would like to
report all mistakes and omissions from the owner. It is therefore important to ensure the report
reflects the actual situation and represents issues in a fair way. In the end it comes down to trust
between all parties involved, particularly between the owner and contractors. Since conflict-
ing interests will exist at all times, making money versus saving money, it works best to openly

203

925836-02_221_17-Feb-15_08:44:16_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

acknowledge these differences and to focus on the common interests and goals, like for example
a good safety performance.

10.6 ! Project controls team


The Project Controls (PC) team is part of the overall project team and can typically include the
following disciplines:
• Cost estimation
• Scheduling
• Cost control
• Risk management
• Document control

The PC team is normally led by a Project Controls lead or manager and the size of the team will
vary depending on the size and complexity of the project. The PC manager is normally a mem-
ber of the project management team.

The PC team plays a vital role in providing management information to the project team and
various stakeholders. To fulfil this role the PC team needs to:
• Establish a clear project baseline, including a proper understanding of the business drivers.
• Compile a fit-for-purpose project controls plan.
• Proactively collect and challenge project information and data.
• Integrate and analyse the information from all sub-projects, disciplines and third parties.
• Provide reliable management information to the project team to help them take the right
decisions.
• Consolidate all relevant progress information and data in a formal progress report.
• Support management of change and assess the impact of changes on cost and schedule.
• Facilitate risk management.

The PC team can only succeed if they are involved from the start of the project, if they are being
recognised for their critical role and provided they communicate and engage with the right peo-
ple at the right time. This requires full support from project management and the right mix of
analytical and people skills in the PC team.

10.7 ! Fit-for-purpose project controls


Fit-for-purpose project controls means applying the right level of cost and schedule control for a
project in each lifecycle phase. For large projects this can even be different for each major WBS
element. The level of control depends on the scope of work, associated risk, complexity and also
the contracting strategy. Building a multi-billion euro chemical plant under a joint venture with a
consortium of contractors requires a different level of control than building a small-size pedestri-
an bridge by one contractor under a lump sum contract.

204

925836-02_222_17-Feb-15_08:44:19_walter
the scene and money at work

Below some examples are given to illustrate the need for fit-for-purpose project controls.

Cost estimate
Depending on the project phase and the level of project definition, the completeness and accu-
racy of the estimates varies. Sometimes stakeholders are asking for a very accurate estimate in
the early development phases of a project, while the required level of project definition is not
available yet. This can result in an extensive exercise and expenditure, to obtain the necessary
detail required to establish the desired level of accuracy. The issue with producing very accurate
estimates too early, lies in making too many assumptions and trying to collect reliable cost data
while there are still a lot of unknowns and uncertainties. A famous one-liner applies here: ‘It is
better to be roughly right, than precisely wrong.’ So unless there is a clear need for an accurate
(deterministic) estimate early in the development, likely related to risk, stakeholders should really
focus on the objective of an estimate and on which decisions it should support.

Schedule
Same as for the cost estimate it is important to make sure that the level of scheduling detail is
aligned with the purpose of the schedule. It is no use to develop a detailed, fully resource loaded
schedule, if you only need rough milestones and lead times to compare different design con-
cepts in the early project phases.

Similarly it is highly unlikely that the small-size pedestrian bridge requires a fully integrated cost
and schedule Monte Carlo risk analysis. On the flip side, the multi-billion chemical plant does
require this integrated analysis since the complexity and associated risks are entirely different.
In summary, applying fit-for-purpose project controls requires full understanding of the project
value drivers, risks and the specific purpose of estimates and schedules in each project lifecycle
phase.

205

925836-02_223_17-Feb-15_08:44:19_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

Chapter 11 ! overview
This chapter deals with the economics of a project. It reveals how the financial justification of
a project can be calculated and demonstrated. A number of economic project parameters are
introduced and defined. Time value of money is introduced. Categories of projects and their
desired profitability are presented. The calculation of the economic parameters is based on the
capital outlay and the project proceeds over the years. Cash Flow and Operating Income are
elements of these proceeds.
The chapter details what input is needed for calculating the parameters and where to find or how
to define these inputs. Three projects, different in nature as to level and timing of the proceeds
are compared. It is demonstrated how the differences impact the defined economic parameters.
Finally the rationale behind applying a multiple of parameters is underpinned.

Chapter 11 ! outline
11.1 Introduction
11.2 Definition of the economic parameters
11.3 Time value of money
11.4 Projects and their desired profitability
11.5 Input for the evaluation model
11.6 Calculating the economic parameters
11.7 Economic and sensitivity analysis
11.8 Significance of the economic parameters
11.9 The Wind Farm

206

925836-02_224_17-Feb-15_08:44:20_walter
the scene and money at work

Chapter 11
Economic project
evaluation
by Jan Wagenmakers

11.1 ! Introduction
This chapter deals with the economics of a project. The outcome of the economic project eval-
uation depicts the financial viability of a project.

In its project selection process the owner will consider a number of aspects such as company
strategy, production technology, marketing, personnel and importantly also the financial aspects.
The results of the economic evaluation are important to the management (representing the
owner), which takes the go-no-go decision on the execution of a project. As the decision is quite
often a choice between a number of project opportunities, a profitable prospect provided by the
economic project evaluation is a major decision criterion.
In contrast to some other aspects of managing a project the economic project evaluation is
based on an arithmetic model. This model itself is not subject to strategy, tactics or approaches.
The input for the model – the financial data – however is influenced by the business man-
agement view and as a result strategy, tactics and approaches do affect the outcome of the
economic project evaluation.
Nonetheless models do not take decisions, people do. So the evaluation outcome is only a part
of the decision process; an important one however.
Economic evaluations take place at the various stages of a project. The data are provided by the
business case; both capital investment estimates and financial yield of the project under con-
sideration. As the business case is reviewed at various stages of the project the data used in the
project evaluation firm up and the outcome increases in reliability.

During the period that I served at the Delft University of Technology, I supervised student
teams working on conceptual design projects in their pre- and postmaster programmes.
The subjects concerned Chemical and Biochemical Engineering. At the end of the project
the results were presented to the staff and supervisors.
By using the following comments I tried to box the mindset of these teams for the task.

207

925836-02_225_17-Feb-15_08:44:25_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 a number of years from now many of you will be members of a project team in the
process industry. You will have to present your results to an approval or appropriation
committee. When that day comes – having done your utmost – you will leave the
board room and see that another project team is waiting to sell their project to the
same committee. This committee only has a certain budget to invest and not all the
appropriation proposals can be granted. Make sure your project is selected. So now, as a
student, prepare your presentation in a way as if it were to be given to the committee of
the company that assigned the project to you.’

The economic evaluation can be performed in a number of ways using various indicators. The
level of these indicators for the project at hand define the financial attractiveness of the project.
Each indicator has its own meaning about the company, the decision makers and the project
perspective.
Those stated below are the common ones:

• Payback period (PBP)


• Internal (or Investor’s) rate of return (IRR)
• (Net) Present Value ((N)PV)
• Return on investment (ROI)

These indicators are defined in detail in the next paragraphs.

11.2 ! Definition of the economic parameters

Payback period (PBP):


Payback Period (Seider et al., 2009) is the time required for the annual earnings (Cash Flow, Net
Income + Depreciation, see 11.5) of the plant operation – the plant being the result of the project
– to equal the original investment. As a rule here the Total Depreciable Capital (TDC) is used. For
definitions of TDC and TIC: see Paragraph 11.5. The following equation represents this:

10

TDC = (CF)n
n=1

In this equation n is the PBP in years. As the annual earnings may not be constant over the years,
particularly in the early years of the operation, it is not fully accurate to state: PBP (years) = TDC/
(annual) CF.

Return on investment (ROI):


The Return on Investment is the ratio between the Operating Income (OI, defined in Paragraph
11.5) and the Total Invested Capital (TIC) (www.dsm.com, www.akzonobel.com).

Operating Income OI
ROI = Total Invested Capital
= TIC

208

925836-02_226_17-Feb-15_08:44:28_walter
the scene and money at work

The ROI is expressed as an annual percentage number when in the formula the annual OI is filled
in. This ROI number may fluctuate from year to year in the plant operation as OI may fluctuate.
Another way to express the ROI is by calculating it over the estimated life of the plant operation.
For definition of estimated life of the plant operation, see Paragraph 11.5. In that case the average
OI (total OI divided by the estimated life of the plant operation n in years) is incorporated in the
formula:
10

ROI =( (OI)n * 100 ) / TIC


n=1 n

Usually the value in the denominator (TIC) is kept constant over the years. The alternative is that
the average asset value – asset value averaged over the estimated life of the plant operation – is
applied in the denominator.
In contrast to PBP and ROI, indicators such as PV, NPV and IRR include time value of money.

Present value (PV):


The Present Value is the value of the future (or projected) Cash Flow from the plant operation in
value of money of today (current buying power).

10

PV = (CF)n / (1 + r)n where r = discount rate.


n=1

The summation starts with n=1 being the first year of the plant operation and ends with n=10,
being the end of the estimated life of the plant operation. The discount rate r is applied at the end
of the year.

Net Present Value (NPV):


The Net Present Value has much similarity with PV. However, NPV covers a longer period: the
investing period as well as the operational period right throughout to the end of the estimated
life of the plant operation. So it is the value of the (negative) Cash Flows (CFs) in the investing
period plus the projected CFs from the operation in value of money today.

10

NPV = (CF)n / (1 + r)n where r = discount rate.


n=0

n=0 in the final year of the investing period and negative in the years before that. In the formula
above, for simplicity reasons, the TIC is incorporated in year n=0.

Internal rate of return (IRR):


The Internal Rate of Return is the discount rate r in the formula of the NPV under the condition
that the NPV is zero. The formula for calculating the IRR for an estimated life of the plant opera-
tion of 10 years is:
10

IRR = r @ NPV = (CF)n / (1 + r)n = 0


n=0

Here the investment is taken in year n=0 and r is calculated by iteration.

209

925836-02_227_17-Feb-15_08:44:28_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

11.3 ! Time value of money

11.3.1 Introduction

The value of money is time-related. It is assumed that money in the bank has a higher absolute
value in the future than the nominal amount of today; the reason being the interest paid by the
bank.

Therefore, in the case of an interest rate > 0 the future nominal value of money will be higher
than the nominal value per today. When at the end of year 0 € 100 is put in the bank, the nominal
value of this € 100 at the end of year n will develop as the numbers in Table 11.1 depict.

Table 11.1: Future nominal money value

Interest rate

Year 2% 4% 8% 10 %

0 100 100 100 100

1 102 104 108 110

2 104 108 117 121

3 106 112 126 133

4 108 117 136 146

5 110 122 147 161

The nominal value at the end of year n equals:

Amount (€ 100) * (1+ i)n

where i = interest rate.

The opposite is also true: money kept in a safety deposit box will lose value over time as a result
of inflation. The nominal value remains the same but the buying power diminishes. Table 11.2
demonstrates how the buying power of € 100 (nominal at the end of year 0) develops over the
subsequent 5 years at different inflation rates. The numbers express the buying power at the end
of each year.

210

925836-02_228_17-Feb-15_08:44:28_walter
the scene and money at work

Table 11.2: Loss of money buying power over the years

Inflation rate

Year 2% 4% 6% 10 %

0 100 100 100 100

1 98 96 94 91

2 96 92 89 83

3 94 89 84 75

4 92 85 79 68

5 91 82 75 62

The buying power of the money at the end of year n equals:

Amount (€ 100) /(1 + t)n

where t = inflation rate

The outcome of the formula 1/(1+ t)n is referred to as Inflation factor in year n.

11.3.2 Time value of money in economic project evaluation


As depicted in Table 11.2, in current buying power, € 100 to be earned 5 years from now is worth
less than € 100 to be earned next year.

In the economic project evaluation this aspect is taken into consideration. The projected earn-
ings (the annual Cash Flows) of the operation are discounted against a defined discount rate. This
method is called Discounted Cash Flow (DCF) Calculation.
Time value of money is reflected in (Net) Present Value and IRR calculations.

For the discount rate different inputs can be considered


• Inflation %: For a project evaluation this is too mild as it only considers the loss in buying
power.
• Interest %: This is more realistic as the number now represents the percentage of the money to
be made by depositing money in the bank (own capital) or to be paid to the bank in case of a
loan.
• Instead of interest rate the more comprehensive term WACC (Weighted Average Cost of
Capital) can be considered. This represents the average on all of a company’s securities such
as stocks, bonds and other debts. The resulting rate is what the firm would use as a minimum
for evaluating a capital project or investment (WACC, 2014).

211

925836-02_229_17-Feb-15_08:44:28_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

Table 11.3: Present Value calculations Project I

Cash Flow DCF against

Year k€ 4% 9% 14 %

1 100 96 92 88

2 120 111 101 92

3 150 133 116 101

4 200 171 142 118

5 250 205 162 130

6 300 237 179 137

7 300 228 164 120

8 300 219 151 105

9 200 141 92 62

10 250 169 106 67

2170 CCF

1711 1304 1020 CDCF

DCF = Discounted Cash Flow


CCF = Cumulative Cash Flow
CDCF = Cumulative Discounted Cash Flow = Present Value (PV)

• For the process industry a historic WACC rate of 10 % may apply but more recently 8 % is real-
istic (Cost of Capital Study, 2012).
• WACC and risk provision %: In the above the aspect ‘risk’ is still not fully incorporated.
Companies like to see reflected in the discount rate the risk they take in executing the project.
So on top of the WACC a percentage is added reflecting the risk taken. This brings the required
IRR hurdle to 14 - 18 %.
• In many cases an even more rigorous condition is applied: e.g. the percentage that can be
made with an alternative, attractive project.

In Table 11.3 an example is given of the result of applying different discount rates to the predicted
Cash Flows of a project, called Project I.

212

925836-02_230_17-Feb-15_08:44:31_walter
the scene and money at work

In this example the Cumulative Discounted Cash Flow (CDCF or PV) @ 14 % in the 10 years of the
estimated life of the plant operation yields less than 50 % of the Cumulative Cash Flow (CCF):
€ 1.02 million versus 2.17 million or 47 %. With a milder discount rate of 4 % the CDCF ends up
higher and the ratio CDCF/CCF becomes 79 %: 1.71 / 2.17.

Below the effect and benefit of high Cash Flow in the early years of the project is demonstrated.

Over the estimated life of the plant operation a project II yields the same cumulative Cash Flow
(€ 2.17 million) as Project I. However, the cash is generated earlier which is favorable for the
Discounted Cash Flow. The higher Cash Flows in these early years are discounted against a lower
discount factor as they come in after a smaller number of years and contribute with more DCF.
As a result the cumulative Discounted Cash Flow is higher than in the case of Project I.

Table 11.4 shows the data for Project II; the cumulative Cash Flow is the same as for Project I but
the cumulative Discounted Cash Flow in Project II is higher for reason as stated above.
For easy reference: compare the numbers of year 6 in Table 11.3 with those in the years 2 and 4
in Table 11.4.

Table 11.4: Present Value calculation for Project II: high Cash Flows in the early years

Cash Flow DCF against

Year k€ 4% 9% 14 %

1 100 96 92 88

2 300 277 253 231

3 500 444 386 337

4 300 256 213 178

5 250 205 162 130

6 200 158 119 91

7 150 114 82 60

8 130 95 65 46

9 110 77 51 34

10 130 88 55 35

2170 CCF

1812 1477 1229 CDCF

Therefore, for comparable projects, those with high Cash Flow in the early years are financially
more attractive than those with moderate early Cash Flow.

213

925836-02_231_17-Feb-15_08:44:31_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

11.4 ! Project types and their desired profitability

11.4.1 Process Industry


Management teams in the industry, tasked with the appraisal of project proposals, will be offered
a range of projects. Viewed from a business perspective a number of categories can be defined:

• Strategic projects:
These projects are to be executed in order to support and bolster the company’s (new) strate-
gy. For example: they are conditional to
– Increase market share or
– Enter new markets or
– Enlarge the product portfolio

Although these projects may carry a higher risk than a debottlenecking project, they may be
approved with a less attractive financial picture – PBP over 4 years and IRR below 14 % because
they serve the (mid- to long term) strategy.

• Safety projects:
Safety projects serve to enhance the safety of production conditions. Execution is based on
other considerations than profitability. In order to come up with economic attractiveness the
potential savings of prohibiting accident cost can be taken into account in the profitability
calculation.

• Right to operate projects


Right to operate projects have to be executed to stay within the limits of permits granted. They
are also referred to as ‘must’ projects. Although executing these projects may be regarded
as ‘spending money with no revenues as a result’ there is a bottom line profitability because
discontinuing the operation concerned often has a much higher financial impact.

• Other projects:
Enterprises have their own minimum levels for appraising projects. An IRR level of 14 to 18 % is
common in the chemical industry at a PBP not over 3.5 years. But again exceptions exist.
Notable ones are:
– High risk projects:
Projects introducing new technology (new for the company) or aiming at new markets will
have a high risk for success. These projects require a short PBP in order not to be exposed to
the high risk for a longer time. Exceptions are those projects marked as ‘Strategic’.

– Expansion and debottlenecking projects:


These projects have comparatively low risk. Moreover they often benefit from low fixed cost
as many provisions are already in place and shared with the existing operation. That is the
reason why they show (and should show) at least a very short PBP and a high IRR.

214

925836-02_232_17-Feb-15_08:44:35_walter
the scene and money at work

One may argue that safety projects do not yield money, but preventing accidents and
prohibiting their consequences (including avoiding losses due to repair and claims
following accidents and permit infringements respectively) do ensure money.

Where Derek Bok stated:


If you think education is expensive, try ignorance for a while

We can paraphrase him by


If you think safety measures are expensive, try neglect for a while.

11.4.2 Non-Profit Organisations


Management Teams of non-profit organisations like housing corporations may have a different
view on project economics. The goal of housing corporations is to provide housing facilities for a
reasonable price, whilst minimising financial risks. The money to be invested will be provided by
the bank. The financial focus for their house building projects will be on the Income Statement.
After having paid the annuity (interest plus repayment) and operating cost the Income Statement
should show a slightly positive result to cover the financial consequences of uncertainties.
It is worthwhile mentioning that these projects often have a very long projected lifetime of the
project result – a house in this case – (and a much lower risk profile). For example, the PBP and
the running time of the mortgage may be 30 years or longer.

Capital investments made by the government (central and local government) in most cases
will not primarily be based on economic attractiveness within a more limited period (of several
years). Many of them also have a very long projected life of the result of the project. Here the
focus will be on public purpose, necessity and availability of the required funds. Savings (like cost
of pollution), entrance fees (museums, theaters), tax income and touristic promotion of the city
involved can be marked as Revenues. But in many cases these projects themselves will never
break even. They will be judged on their importance for society as a whole. On a local level they
compete with each other to obtain the required funds from the (remainder of) the municipality’s
annual budget.

In most cases, major infrastructural projects are executed by the government. The oper-
ation activity (e.g. operating a railroad connection) may be given in concession to private or
semi-private parties. The latter consider the economic attractiveness as important. Often
they will be limited in collecting sufficient revenues as a consequence of the public opinion
regarding the price of tickets. This in return determines the price of the concession. In the worst
case scenario a subsidy may be required. In a broader picture: subsidies are important drivers for
capital investments in developing countries, environmental projects, governmental stimulation
and the like.

11.5 ! Input for the evaluation model


The economic project evaluation model requires a set of data. Some come in by definition –
like the estimated life of the plant operation – but most are delivered by estimating the capital
investment level and the profit that can be made with the result of the project.

215

925836-02_233_17-Feb-15_08:44: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

Estimated life of the plant operation


In calculating the financial attractiveness of an engineering project for manufacturing, the
production is given a theoretical number of years.

The physical life of an asset is the period over which the asset is expected to be usable, with nor-
mal repairs and maintenance, for the purpose it is acquired. But this is only one component of
the estimated life of the plant operation. Also economics – in which are reflected raw materials,
end product prices and product substitution – play a role in assessing the estimated life.

For projects concerning manufacturing of hardware applied in mass communication a projected


life of the plant operation not over 5 years may be realistic as after that the product may become
obsolete. In the chemical industry for many cases 10 years is chosen as an estimated life. For
some, more traditional projects 15 years are taken as an input.

Although the real production period (physical life) may be longer – oil and gas assets are normal-
ly designed to operate for 25 to 30 years – a very high number of years as an estimated life of the
plant operation hardly makes sense in the economic evaluation. The reason is that the additional
DCF the asset is assumed to yield becomes marginal after 10 years when a realistic discount
percentage (like for instance 16 %) is applied.

Capital Investment
As stated above, the Present Value of a project represents the amount of money in value of today
that the project is expected to yield with the plant operation. The picture becomes more realistic
when this number includes the capital cost required to realise the project. The number is then
called the Net Present Value, NPV. Calculating the Internal Rate of Return (IRR) is based on the
NPV so the capital investment level is incorporated.

In calculating the IRR the Total Invested Capital (TIC) is used. This is the one-time expense for the
design, construction and start-up of a new plant.

The Pay Back Period (PBP) is calculated on the basis of the Total Depreciable Capital (TDC) which
is defined as the TIC minus Value of Land minus Start-up Cost minus Working Capital.

Cash Flow, Net Profit


To arrive at these data an Income Statement (or Profit & Loss Statement) is to be made, for every
year of the operation. The Income Statement is the financial statement showing the profit (or
loss) earned by a business over an accounting period (as a rule one year). The Income Statement
depicts the Cash Flow, Operating Income and Net Income.

Income Statement
A somewhat simplified Income Statement for a project is given in Table 11.5, indicating which
data are used in calculating IRR, PV, NPV, PBP and ROI. The Business Representative responsible
for Marketing and Strategy is to provide data for Revenues. Fixed and Variable Cost is inputted by
Project Engineering and Purchasing.

216

925836-02_234_17-Feb-15_08:44:39_walter
the scene and money at work

Table 11.5: Example of a Project Income Statement

Project A, year 2 Some remarks regarding Table 11.5 are


worth mentioning:
M€ • Cash Flow: Cash Flow is the difference
between revenues and cost actually
Revenues 20 paid. As depreciation is incorporated in
calculating the Net Income and depre-
Variable Manufacturing Cost 8 ciation is not an item actually paid, the
• Raw Materials
• Auxiliary Materials (incl. catalysts,
depreciation is added to the Net Income
solvents) to arrive at the Cash Flow.
• Quality Control • Interest: this is a cost item in stating
the Income Statement of the project. In
Contribution Margin 12 larger companies, projects are regarded
as internally funded. In the economic
Fixed Manufacturing Cost 8.5
evaluation the company likes to know
• Labor
• Utilities/waste treatment what money can be made with the
• Maintenance funds provided for the project. So here
• Site Overhead Interest is not viewed as a project
• Insurance premium / tax
expense and is left out in calculating
• Royalties
• Depreciation Net Income. Smaller enterprises must
borrow money from the bank and do
Gross Profit 3.5 not always have competing projects.
As the interest for this loan is a real
MAR Cost 1.2 cost item (to be paid to the bank) these
• Marketing
leveraged or externally funded projects
• Administration
• R&D incorporate Interest in the Net Income
and economic evaluation calculation.
Operating Income (OI) 1 2.3 • Tax: to some extent this could be
treated like Interest. Some companies
Interest n/a disregard Tax in the economic evalua-
tion as the profit is reconciled with the
Tax n/a profit of other operations. For them Tax
plays a role in the site selection process.
Net Profit/Net Income (NI) 2.3
In particular smaller companies incor-
porate Tax here.
Depreciation 1.7

In the Income Statements for the exam-


Cash Flow 2 4
ples below (Projects A, B and C) Interest
1 Used in calculating ROI and Tax are not taken into account.
2 Used in calculating IRR, PV, NPV and PBP

217

925836-02_235_17-Feb-15_08:44:39_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

11.6 ! Calculating the economic parameters


In this paragraph an example is given of how to calculate the economic parameters discussed
above.

A project A with a capital outlay (or TIC) of € 20 million is considered. For simplicity, it is assumed
that the total capital investment is spent in one year. Value of Land, Start-up expenses and
Working Capital are estimated at a level of € 3 million, which brings the TDC to € 17 million.

Estimated life of the plant operation is set at 10 years. In the final year the Salvage, Land value
and the returned Working Capital are estimated to be (nominally) € 1.5 million. This explains the
relatively high CF in year 10. Depreciation, linear in 10 years, is at a rate of € 1.7 million per year.

Table 11.6 depicts the projected CFs, Depreciation, Net Income (NI), Operating Income (OI), PV,
NPV and IRR for this project. OI and NI are equal (Interest, Tax disregarded) so only NI is stated.
For NI and CF the numbers for year 2 are taken from Table 11.5. For the other years the numbers
for these 2 items are projections, used as an example.

Depreciation equals TDC divided by estimated life (10 yrs): € 17/10 = € 1.7 million per year.
Interest and Tax expenses are PM.

Now return to Table 11.6


The estimated Net Income (NI) is taken from the Income Statement.
Cash Flow equals: Net Income + Depreciation.

ROI is arrived at by dividing OI by TIC. In this case NI divided by TIC as OI equals NI.

The PV is calculated at a 10 % discount rate based on the WACC rate and some coverage for risk.
The 10 DCF terms are: CF/(1+r)n where n is the year of operation from the first column and r is
10 %.

The NPV is calculated similarly to PV but now the terms include year zero, the investing year –
that is the year that the project is under construction. NPV equals PV minus TIC when PV and
NPV are discounted against the same discount rate.

Note that in Tables 6,7 and 8 for the PV calculation a 10 % discount rate is applied whereas in the
NPV calculation the IRR is applied, bringing the NPV to 0.

The IRR (17 %) is obtained by iteration: iterate the r in the formula of NPV
("(CF)n/(1+r)n) to a level that the sum of the 11 terms (n runs from 0 to 10) equals zero. (Goal seek
in Excel)

The PBP is calculated by deducting the CF in the early years from the TDC (€ 17 million) until the
remainder is zero. In this example the PBP is 4 years.

218

925836-02_236_17-Feb-15_08:44:41_walter
the scene and money at work

Table 11.6: Calculating Economic Parameters

Project A

TIC 20 M€

TDC 17 M€

Estimated life 10 years

Depreciation 1.7 M€

Year Net Income Depreciation Cash Flow DCF @ DCF @ ROI

M€ M€ M€ 10 % 17.0 % %

0 -20 -20

1 1.3 1.7 3 2.7 2.6 6.5

2 2.3 1.7 4 3.3 2.9 11.5

3 3.3 1.7 5 3.8 3.1 16.5

4 3.3 1.7 5 3.4 2.7 16.5

5 3.3 1.7 5 3.1 2.3 16.5

6 2.8 1.7 4.5 2.5 1.8 14

7 2.8 1.7 4.5 2.3 1.5 14

8 2.3 1.7 4 1.9 1.1 11.5

9 2.3 1.7 4 1.7 1.0 11.5

10 3.3 1.7 5 1.9 1.0 16.5

27 17 24 26.6 0.0 13.5

CCF PV NPV avg. ROI

PBP = 4 yrs IRR = 17 %

Note: Operating Income = Net Income as Interest and Tax are disregarded

219

925836-02_237_17-Feb-15_08:44: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

Cumulative CF and NPV


Project A

30

20

Cash PBP
10
Flow
(M€)
0 Years
-1 0 1 2 3 4 5 6 7 8 9 10

-10

CCF
-20
NPV
-30

Figure 11.1: Development of Cash Flow and Net Present Value, discounted against the IRR

In Figure 11.1 the CCF, starting at the TDC level of – € 17 million is given. The curve of the CCF
intercepts the x-axis at year 4, being the PBP. Also the NPV, discounted against the IRR (17. %) and
starting at – € 20 million (the TIC) is given. At the end of the estimated plant production period,
the NPV is 0 when as a discount the IRR is applied.

11.7 ! Economic and sensitivity analysis


Estimated life of the operation and discount rate are well defined for a given project. All data
are provided by the business case, depicting the various estimates. Numbers for TIC and TDC
estimates are provided by the project cost estimating process. With the feasibility study being
complete, the accuracy level can be as good as ± 10 %.

The other sets of numbers – those for Cash Flow and Operating/Net Income – used in calcu-
lating the economic parameters are provided by the projected annual Income Statements. As
a result, CF and OI/NI are projections over a longer time. Their accuracy is impacted by many
aspects including:
• raw material and energy price development
• final product price development being a result of:
– actions of competitors
– potential product substitution
– social acceptance of the product over time
• sustainability of patent protection.

220

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

With this in mind it is understood that the economic attractiveness of a given project depends
heavily on the CF and OI/NI to be generated, keeping in mind that these input items have a low
level of accuracy.

In order to address this risk element a sensitivity analysis is performed.

For the Base Case Scenario, PBP, ROI, (N)PV and IRR are calculated using the best estimated num-
bers for TIC, TDC, CF and OI/NI. In the best and worst case scenario signifying lower numbers
(pessimistic) and higher numbers (optimistic) respectively are inputted for those aspects having
a high impact.

Below is an example how this can be applied:


best estimate pessimistic optimistic
TIC, TDC: ‘100’ 130 % 90 %
Raw materials price: ‘100’ 150 % 70 %
Final product price: ‘100’ 75 % 115 %

So for the worst case (pessimistic) a 30 % overrun on cost is anticipated.

A carefully chosen combination of the numbers above – used as an input – will represent the best
and worst case respectively. It is not likely that all choices will result in either poor or excellent
outcomes because, for example, raw materials and final product prices may change dependently
in the same direction.

As stated above, CF is a very important element with a strong impact on the economic parame-
ters. Both the sum of the CFs over the years (CCF) and the spread over the years are important.

Below a pair-wise comparison is made between 3 projects.

For the process industry 3 projects (A, B and C) are envisaged. All 3 have a Total Depreciable
Capital of € 17 million. Also the Total Invested Capital is the same for all three: € 20 million
Project A will deliver a product which needs a market initiation period. As a result, the CFs in year
1 through 3 are modest.
Project B will lead to the production of a product that will gain market share and will show
reasonably good sales early on. Therefore the CFs in the years 1 through 3 are high. But after that
some product substitution may set in.
The production processes of Project A and B are not protected by a patent. During the estimated
lifetime Project A and B will yield the same CCF: € 24 million.
The product, being the result of Project C, is completely new which leads to a market introduc-
tion with limited early success and consequently moderate sales volumes in the early years. CFs
are identical to those of Project A. But the process and the product are protected by patents. As a
result the CFs are good until year 8. The CCF is high: € 31 million.
Below it is stipulated how these different conditions impact the economic parameters.

The development of the Operating Cash Flows (CFs excluding the TIC) of the 3 projects are given
in Figure 11.2

221

925836-02_239_17-Feb-15_08:44: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

Cash Flow of three projects

Cash
Flow
(M€)

Project A

Project B

Project C
Years

Figure 11.2: Comparing the Operating Cash Flows for three projects

Effect of high CFs in the early years: compare Project B with Project A
The data resulting from Project A have been given in Table 11.6.
The product of Project B has a good start. It is successful in the market leading to high CFs in year
1 through 3. Project B is a frontloaded CF project. After year 3 the CFs are tapering off. Compared
with Project A, high CFs (year 1 - 3) are discounted against a lower factor as they come in early
(for easy reference: see also Paragraph 11.3.2).

In Table 11.7 the data for Project B are given. The effect of the more attractive CF distribution
(more CF in early years) has its effect on PBP, which drops by 1.1 year (from 4 to 2.9 years), a sig-
nificant period of time.
The IRR increases from 17 % to 20.9 %, which is quite a step as well.
The PV goes up from € 26.6 million to € 28.7 million.
The ROI (13.5 %) is not affected as the cumulative NI stays unchanged at € 24 million. The annual
ROI for Project B (Table 11.7) is more attractive in the early years though.

Effect of higher CFs in the later years: comparing Project C with Project A
One should understand that when the cumulative CF goes up, most of the parameters benefit
and look more attractive.
This is demonstrated in Table 11.8, representing the data from Project C. The cumulative CF is
€ 31 million: € 7 million more than that of Project A. In both projects the CF in the operating years
1 to 3 is the same however. During the years 4 to 7 Project C yields higher CFs.

222

925836-02_240_17-Feb-15_08:44:48_walter
the scene and money at work

The effect is as follows (comparing data of Project C with those of Project A; Table 11.8 with
Table 11.6):

Table 11.7: Effects of a front-loaded Cash Flow project on Economic Parameters

Project B

Year Net Income Depreciation Cash Flow DCF @ DCF @ ROI

M€ M€ M€ 10 % 20.9 % %

0 -20 -20

1 3.3 1.7 5 4.5 4.1 16.5

2 4.3 1.7 6 5.0 4.1 21.5

3 5.3 1.7 7 5.3 4.0 26.5

4 3.3 1.7 5 3.4 2.3 16.5

5 2.3 1.7 4 2.5 1.6 11.5

6 2.3 1.7 4 2.3 1.3 11.5

7 1.3 1.7 3 1.5 0.8 6.5

8 1.3 1.7 3 1.4 0.7 6.5

9 1.3 1.7 3 1.3 0.5 6.5

10 2.3 1.7 4 1.5 0.6 11.5

27 17 24 28.7 0.0 13.5

CCF PV NPV avg. ROI

PBP = 2.9 yrs IRR = 20.9 %

• PV: increases by € 4.5 million


• IRR: goes up from 17 % to 21.1 %
• ROI moves up from 13.5 % to 17 %

The PBP, however, remains almost unchanged: 3.8 and 4 years respectively. This is because the
CFs in year 1 through 3 are the same.
This example demonstrates the limitation when taking into account only one parameter. On the
basis of PBP the Project B (Table 11.7) looks most attractive, but PBP disregards the higher CFs in
subsequent years.

223

925836-02_241_17-Feb-15_08:44: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

Table 11.8: Effects of high Cash Flows in later years on Economic Parameters

Project C

Year Net Income Depreciation Cash Flow DCF @ DCF @ ROI

M€ M€ M€ 10 % 21.1 % %

0 -20 -20

1 1.3 1.7 3 2.7 2.5 6.5

2 2.3 1.7 4 3.3 2.7 11.5

3 3.3 1.7 5 3.8 2.8 16.5

4 4.3 1.7 6 4.1 2.8 21.5

5 6.3 1.7 8 5.0 3.1 31.5

6 6.3 1.7 8 4.5 2.5 31.5

7 4.3 1.7 6 3.1 1.6 21.5

8 2.3 1.7 4 1.9 0.9 11.5

9 1.3 1.7 3 1.3 0.5 6.5

10 2.3 1.7 4 1.5 0.6 11.5

34 17 31 31.1 0.0 17

CCF PV NPV avg. ROI

PBP = 3.8 yrs IRR = 21.1 %

11.8 ! Significance of the economic parameters


Those who decide on the selection and approval of a project have a long list of considerations
playing a role in the approval process. Economic evaluation data is just one of them.

In the above examples, four economic parameters (PBP, (N)PV, IRR, ROI) are discussed. Generally
the appropriation committee has a set of company, division or business unit standards against
which they check the level of the parameters for the project under discussion.

As discussed above each parameter has a different meaning and stipulates a unique aspect
(Burke, 2003; Kapur, 2004; Bhatia, 2014; De Neufville & Stafford, 1969).

224

925836-02_242_17-Feb-15_08:44:51_walter
the scene and money at work

PBP is a parameter easy to relate to and often plays a very important role. How long does it take
before the invested money is recuperated? How long will the money be exposed to risks?

The annual Cash Flows are the basis for calculating the PBP. These CFs however are projections
or expectations. During the estimated life of the plant operation many assumptions may change.
These potential changes (regarding increasing raw material and energy prices, overestimated
product uniqueness, competitors’ actions, inadequate patent protection) may not happen or
may not have consequences in the early years of the projects. Hence a short PBP reduces many
of these risks as competition makes investments over a longer time period and fixed project
contracts cover raw materials, energy and, to some extent, final product prices. As a result a short
PBP makes a project economically attractive. Often a PBP of no longer than 3 years is required in
the chemical industry. High-risk projects may require short PBPs.

Drawbacks for focusing on PBP are:


• does not consider time value of money; however for short-time periods this is not quite
relevant;.
• does not consider potential (and potentially high) CFs in the period after PBP. The data com-
parison of Projects A (Table 11.6) and Project C (Table 11.8) substantiate this.

ROI depicts the annual return on the invested capital. It is a good measure for what percentage
can be made with the money invested compared to other alternatives. In contrast to PBP, ROI
is based on the Operating Income, annually provided by the (plant) operation. Depreciation is
regarded as a cost.

ROI as a measure is popular because it can easily be used for comparisons with running projects.

For many companies a level of 12 % is minimally desired. It does not take into account the time
value of money.

(N)PV and IRR are considered as very important as they indicate the money that can be made by
operating the project asset, in money of today: in euros and percentage respectively.

In contrast to PBP, (N)PV and IRR view the full period of the project and the projected life of the
asset, which is important. When the revenues have a slow start this will affect both PBP and (N)
PV-IRR. However the impact on PBP is much more severe. In Paragraph 11.7 examples of these
effects are dealt with.

A standard for (N)PV is more difficult to set. It is an amount of money related to the level of capi-
tal investment and the discount rate applied. In particular this discount rate will have a relation to
prevailing interest rates and risk associated with the project.

IRR is a more encompassing parameter as it incorporates almost everything discussed above:


• time value of money
• capital outlay
• level of CFs and when obtained
• outcome not affected by inflation and interest rate

225

925836-02_243_17-Feb-15_08:44:51_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 level desired for approval reveals the anticipated risk rate. High-risk projects require a high
IRR. For projects with a risk level anticipated to be moderate, the desired IRR in the industry is
14 % to 18 %, depending on the company standards.

The three projects from Tables 11.6, 11.7 and 11.8 yield the following values for these parameters:

Table 11.9: Comparing the three projects

Parameter Unit Project

A B C

PBP yrs 4 2.9 3.8

PV @ 10 %, M€ M€ 26.6 28.7 31.1

NPV@ 10 %, M€ M€ 6.6 8.7 11.1

IRR, % % 17 20.9 21.1

ROI, % % 13.5 13.5 17

For a graphical representation, the PBP, NPV @ 10 %, IRR and ROI of the 3 projects are indicated
in Figure 11.3

Despite the higher (N)PV, IRR and ROI of project C, the short PBP of project B makes this project
tempting for decision makers, especially those with a focus on the near future.

In conclusion

The economic project evaluation provides valuable information in the selection process of pro-
jects. The outcome is based on an arithmetic model. The input data for the calculation model is
provided by the capital investment estimates and the projected data in the Income Statements
for the various years of the projected lifetime of the operation.
The 4 major parameters (PBP, ROI, (N)PV and IRR ) represent different aspects of the evaluation.
PBP and ROI do not include time value of money. (N)PV and IRR provide information over the
project period and the projected life of the asset. In contrast to PBP they safeguard that profits in
later years are duly reflected. However, as the uncertainty of these later years profits in general is
high, the accuracy of these two parameters – (N)PV and IRR – has its limitation.

In the project selection and approval process it is recommended to involve multiple parameters.

226

925836-02_244_17-Feb-15_08:44:53_walter
the scene and money at work

Year M€

4,5 12,0

4,0
10,0
3,5

3,0 8,0

2,5
6,0
2,0

1,5 4,0

1,0
2,0
0,5

0,0 0,0
PBP NPV

% %

25 25

20 20

15 15

10 10

5 5

0 0
IRR ROI

A B C

Figure 11.3: Comparing PBP, NPV, IRR and ROI of three projects

It is also recommended that the economic parameters be evaluated not only during the project
phase but also after the plant has been producing and the cash has been flowing in for a number
of years following the PBP. The responsibility for this rests with the company and is beyond that
of the Project Manager.

227

925836-02_245_17-Feb-15_08:44:54_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

11.9 ! The Wind Farm


The Allwind project case differs from what is considered standard in the process industry.
A more moderate IRR is acceptable together with longer PBPs. Nonetheless, projects like
WEP oftentimes require subsidies to become economically viable. For the Allwind project
the following key economic data are given:

Base Case (M€ ) Best Case (M€ )


TIC 385 269
TDC 356 246
Revenues from operation 38.5 38.5
Revenues from subsidies 19.2 19.2
Operational cost 7.4 5.5
(maintenance, labour, insurance, etc.)
Interest and Tax n/a n/a
Depreciation 25.6 17.9
Estimated life of the operation 15 yrs 15 yrs

A simplified Income Statement is given below (numbers in M€ )

Case Base Best


Subsidies no yes no yes
Revenues from Operation 38.5 38.5
Revenues from Subsidies 19.2 19.2
Total Revenues 38.5 57.7 38.5 57.7
Operational Cost -7.4 -5.5
Depreciation -25.6 -17.9
Operating Income (Net Income) 5.4 24.6 15.0 34.2
Cash Flow 31.0 50.3 33.0 52.2

For the above, the economic parameters have been calculated with the following result:

Case Base Best


Subsidies no yes no yes
PBP (yrs) 11 7 7.5 5
IRR ( %) 2 9 8 14
ROI ( %) 2 14 6 21

The conclusion is that without subsidies granted to increase the revenues, the project
will hardly meet the requirements or not at all. The subsidised best case yields more than
acceptable results.

228

925836-02_246_17-Feb-15_08:44:54_walter

Common questions

Powered by AI

Constraints on a project manager's authority in established organizations include bureaucratic assessment systems that can limit flexibility and adaptability . Project managers are also bound by the implementation of processes and procedures designed to control project risks, budgets, and schedules, which may inhibit creative problem-solving . Furthermore, organizational structures often require project managers to coordinate multiple stakeholders and comply with industry standards and regulatory requirements, which limits their decision-making autonomy . To work around these constraints, project managers need to build strong leadership skills to effectively lead and motivate their teams, leveraging the skills of team members to navigate within set guidelines . Additionally, project managers can take a holistic approach to competence development, emphasizing broad exposure to various project environments and functions to enhance decision-making within the constraints . Effective communication and stakeholder management are also crucial in aligning team efforts and managing expectations within these limits ."}

Collaborative contract types such as partnering/alliance contracts enhance project performance through improved relational attitudes and teamworking quality. Compared to lump-sum or reimbursable contracts, partnering/alliance contracts foster a more collaborative environment between owners and contractors, resulting in better project outcomes . This collaboration is reflected in the development of shared norms, commitment from senior management, trust, and a no-blame culture, which are essential relational attitudes for successful project execution . The quality of inter-team interactions, specifically communication, coordination, mutual support, and trust, are critical to teamworking quality and significantly contribute to enhanced project performance . Although reimbursable contracts require more owner involvement to manage project objectives, no significant difference in relational attitudes and teamworking quality between lump-sum and reimbursable projects has been observed . Therefore, while contract types and incentives by themselves do not directly change project performance, they are effective in creating a collaborative framework that indirectly improves project performance . Performance benefits are realized through the positive effects of relational attitudes and teamworking, rather than the contract types or incentives alone ."}

Leadership styles significantly impact team development and project success in the context of project management. Effective project managers are those who not only handle the technical complexity but also integrate leadership skills that focus on human and organizational aspects . Different leadership styles, including holistic and cooperative approaches, ensure attention to the entire project scope rather than just technical details, fostering higher team motivation and commitment . Constraints such as timelines, budget, and regulatory approvals often determine the choice of leadership style to ensure flexibility and adaptability throughout the project lifecycle . Additionally, the integration of best practices and standards, such as those from PMBoK and ISO 21500, emphasizes structured processes and strategic oversight, essential for addressing these constraints and achieving project goals . The ability to lead across various phases allows for a seamless transition from development to implementation, leveraging diverse skill sets for project success ."}

Incentive-based contracts positively influence relational attitudes and teamworking quality by aligning stakeholders' objectives and encouraging collaborative behavior. When parties involved in a project see clear benefits tied to their performance, they tend to foster a cooperative relationship, focusing on joint success rather than individual gains. This enhanced collaborative environment leads to better communication, mutual trust, and seamless integration of efforts across teams, thereby improving overall project performance. Nonetheless, while effective in fostering collaboration, these contracts require careful structuring to avoid potential conflicts and ensure fair reward distribution .

Time schedules and formal communication methods significantly influence project coordination, particularly in complex projects, by structuring and standardizing procedures, thus facilitating better alignment among team members. A formalized schedule ensures that deadlines are met, and tasks are executed in a timely manner, thereby supporting project progression and reducing delays . Moreover, formal communication methods provide clear guidelines and frameworks that help manage expectations and ensure that all stakeholders have a common understanding of project goals . Having a structured approach and clear communication aids in integrating different organizational cultures, promoting teamwork, and minimizing conflicts, which are essential for successful project delivery . Furthermore, lessons learned from previous projects can be systematically incorporated into new projects, thereby enhancing progress and performance through improved continuity and consistency in communication practices .

Factors contributing to inaccuracies in calculating economic parameters like NPV, IRR, and PBP include uncertainty in cash flow and operating income projections, fluctuations in raw material and energy prices, competitor actions, product substitution, and varying interest and inflation rates. The impact of these inaccuracies can be significant over long project durations as the assumptions made can change over time, affecting future projections and profitability . NPV and IRR, while accounting for the time value of money, still face limitations due to the inherent unpredictability of long-term cash flows and revenue, which is an issue since they rely heavily on future projections . Sensitivity analysis helps mitigate these inaccuracies by evaluating how changes in key assumptions such as investment costs, market prices, and revenue projections affect economic outcomes like NPV and IRR. By modeling best-case and worst-case scenarios, sensitivity analysis provides insights into potential risks and variability in outcomes, enabling decision-makers to make more informed choices and prepare for different business conditions .

Different types of project teams can significantly impact the effectiveness of project execution, particularly regarding communication and coordination. Integrated project teams, which involve close collaboration among multidisciplinary members, can enhance communication and coordination by building trust and facilitating joint problem-solving . The organizational complexity of a project, such as the number of nationalities and time zones involved, can challenge communication and coordination, making these aspects crucial for project success . Teams that employ collaborative contracting methods, such as partnering and alliancing, often achieve better communication and coordination as they emphasize relational attitudes and teamworking, which are crucial regardless of contract types . Furthermore, task-specific teams like project controls teams, which manage project information flow and integrate data from various sources, are essential for maintaining clear communication and facilitating coordination . Ultimately, fostering a collaborative environment with clear communication and coordination strategies tailored to the team's structure and project requirements can lead to more effective project execution.

The phases of the project lifecycle significantly influence project management practices and the delivery of project outputs. During the proposal and initiation phase, the focus is on identifying opportunities and aligning them with business strategy, ensuring that chosen projects are viable and strategic . The front-end development phase is crucial; it involves extensive design and appraisal to define the project's scope and plan, minimizing costly changes later . Execution and control phase emphasizes effective project management methodologies to deliver the project outputs as planned, using standards and frameworks like PRINCE2 and ISO 21500 that promote a structured approach . The finalization and closeout phase involves assessing whether project objectives have been met and integrating lessons learned into future projects, which improves ongoing project management practices . Each phase typically culminates in a stage-gate review to ensure readiness to proceed to the next phase, supporting systematic and controlled project management practices .

Risk and uncertainty in project management are closely related to approaches in other industries such as finance, healthcare, and process management. In finance, risk management involves balancing high risks with potential high value, using quantitative methods like risk profiling and scenario analysis to optimise investments . In healthcare, risk assessments aim to balance healthcare costs and outcomes, using risk screening to manage uncertainties about patient health effectively . Similarly, the process industry conducts extensive risk assessments to ensure safety, acknowledging that while plants can't be entirely risk-free, measures can minimize potential harm . Project managers can learn from these industries by adopting practices such as balancing risks with potential value outcomes, employing both qualitative and quantitative risk management, and ensuring robust risk assessment and mitigation strategies. Additionally, involving multiple stakeholders and using well-structured frameworks like those in finance can enhance risk management in projects . Emphasizing the understanding and communication of risks through probabilities and scenarios rather than fixed predictions further aligns project management with these industries . This cross-industry learning can significantly improve projects by anticipating and managing uncertainties, leading to more successful outcomes .

PRINCE2 and ISO 21500 serve different project management needs through their unique structures and purposes. PRINCE2 is widely recognized and extensively used by the UK government and the private sector, known for its structured methodology applicable primarily within controlled environments . It provides established best practices and is more prescriptive, meaning it outlines specific processes and responsibilities . This makes it suitable for organizations seeking a comprehensive framework in a controlled context, focusing on defined stages and processes. In contrast, ISO 21500 offers a more generalized approach with a broad description of project management concepts and processes, aimed at providing guidance rather than prescribed methods . It is designed to be applicable across various types of organizations and projects, regardless of project complexity or size, which suits those looking for flexibility and broad applicability . ISO 21500 emphasizes high-level guidance suitable for any sector, allowing new and experienced project managers to adapt practices to improve project outcomes . This flexibility caters to organizations in the public, private, or community sectors, making it more versatile compared to PRINCE2 .

You might also like