Professional Documents
Culture Documents
Managing Project Complexity
Managing Project Complexity
Marian Bosch-Rekveldt
Proefschrift
ter verkrijging van de graad van doctor
aan de Technische Universiteit Delft;
op gezag van de Rector Magnificus prof. ir. K.C.A.M. Luyben;
voorzitter van het College voor Promoties
in het openbaar te verdedigen op dinsdag 15 november 2011 om 12.30 uur
door
Maria Gerridina Catharina BOSCH-REKVELDT
werktuigkundig ingenieur
geboren te Kampen
Samenstelling promotiecommissie:
Rector Magnificus, voorzitter
Prof. dr. ir. A. Verbraeck, Technische Universiteit Delft, promotor
Prof. dr. H.L.M. Bakker, Technische Universiteit Delft, promotor
Dr. ir. H.G. Mooi, Technische Universiteit Delft, copromotor
Prof. L. Crawford DBA, Bond University
Prof. dr. ir. J.I.M. Halman, Universiteit Twente
Prof. mr. dr. J.A. de Bruijn, Technische Universiteit Delft
Prof. dr. P. Storm, Open Universiteit Nederland
Prof. dr. C.P. van Beers, Technische Universiteit Delft, reservelid
Acknowledgement
Achteraf moet ik concluderen dat ik eigenlijk niet wist waar ik aan begon: wat een project!
In november 2006 begon ik mijn promotieonderzoek in het Delft Centrum voor
Projectmanagement (DCP) aan de faculteit TBM van de TU Delft. Er ging een wereld voor
me open: de boeiende wereld van sociaal wetenschappelijk onderzoek. Projectmanagement
had ik al enige jaren in praktijk gebracht, nu mocht ik op zoek naar de achtergrond ervan.
Deze zoektocht ging, zoals het een zoektocht betaamt, met vallen en opstaan, maar ik heb
mijn weg gevonden, resulterend in dit proefschrift.
Veel mensen hebben mij ondersteund bij het tot stand komen van dit proefschrift en deze
mensen wil ik dan ook heel hartelijk bedanken. Ten eerste mijn begeleidingscommissie:
promotor Alexander Verbraeck (altijd een scherpe en kritische blik), promotor Hans Bakker
(zeer praktische inslag en de bepalende link naar het NAP netwerk) en copromotor Herman
Mooi (zonder jou was ik hier niet aan begonnen (sic!) en had ik het al helemaal niet
afgerond). Heren, veel dank voor alle constructieve, chaotische en verwarrende discussies!
Ten tweede wil ik iedereen bedanken die heeft bijgedragen door het leveren van input en
data: de bedrijven van het NAP netwerk, alle enquterespondenten (Fase II en IV) en alle
mensen die hebben meegewerkt aan de interviews (Fase I en III). Daarnaast wil ik ook de
studenten noemen die ik heb begeleid in hun afstudeeronderzoek, dat al dan niet een directe
relatie had met mijn promotieonderzoek (Tim, Yuri, Gerbert, Roald, Sergio, Stephan,
Jeroen, Jordy, Iris, Amin, Arsalan, Anne, Sjoerd, Freek en Jorden). Jullie directe betrokkenheid blijkt uit de gezamenlijke artikelen waarop een aantal hoofdstukken is gebaseerd. Door
het sparren met een ieder van jullie heb ik enorme stappen voorwaarts kunnen zetten.
Mijn collegas bij TSE en de collega-minordocenten wil ik bedanken voor alle collegiale
support. In het bijzonder wil ik noemen: Helen en El van het secretariaat (altijd aanwezig
en behulpzaam), Claire en Elisa (vele zinvolle, gezellige en motiverende (eet)afspraken),
Roland (boeiende ganggesprekken, van zeilen tot schaatsen tot werk gerelateerd), en ook de
anderen op de gang: Patrick, Geerten, Victor, Cees, Sergey, Jafar, Fardad, Casper en Prap.
Het belang van de gezamenlijke uitstapjes naar de koffieautomaat moet niet worden
onderschat!
Ook wil ik mijn en onze vrienden en vriendinnen heel hartelijk bedanken: jullie waren vol
belangstelling en begrip, ondanks de beperkte tijd die ik had in de afgelopen periode. De
optimist in mij zegt dat het alleen maar weer beter kan worden! Leden van het TBMkelderkoor en alle Connections: veel dank voor de broodnodige muzikale afleiding!
Mijn ouders, schoonouders, broers, zwagers en schoonzussen wil ik bedanken voor alle
ondersteuning, op welke manier dan ook. Ik noem bijvoorbeeld het extra oppassen op Lieke
en Nathanenorm bedankt! Lieve Lieke, Lieve Nathan: ja, ik heb nu weer meer tijd voor
poppen, DUPLO en autos: mamas boek is echt af!
Tenslotte, en hierbij geldt hoe clich ook, last but not least: Hans! Je hebt me enorm
ondersteund, begrip gehad en meer dan eens ingesprongen als ik weer eens belde of ik nog
even door kon werken. Lieve Hans: veel dank voor je geduld, je flexibiliteit, voor alles. Ik
hoop dat ik alle brownie points die je hebt verdiend terwijl ik mijn proefschrift schreef
ooit kan compenseren.
i
Table of content
ACKNOWLEDGEMENT....................................................................................................I
LIST OF FIGURES ........................................................................................................VIII
LIST OF TABLES .............................................................................................................IX
LIST OF ABBREVIATIONS ...........................................................................................XI
CHAPTER 1 ......................................................................................................................... 1
INTRODUCTION ............................................................................................................... 1
1.1
1.2
1.3
WHY DO CAPITAL PROJECTS STILL FAIL, WHAT CAN WE DO ABOUT IT? ....................... 2
RESEARCH OBJECTIVE, RESEARCH QUESTIONS AND SCOPE ......................................... 3
RESEARCH APPROACH ................................................................................................ 5
1.3.1
Research in social science ............................................................................. 5
1.3.2
Methods applied in this research ................................................................... 7
1.4
SCIENTIFIC AND SOCIAL RELEVANCE ........................................................................ 11
1.5
DISSERTATION OUTLINE ........................................................................................... 11
CHAPTER 2 ....................................................................................................................... 13
LITERATURE REVIEW ................................................................................................. 13
2.1
2.2
2.3
2.4
ii
CHAPTER 3 ....................................................................................................................... 47
EXPLORATORY CASE STUDIES ................................................................................. 47
3.1
METHODS ................................................................................................................. 47
3.1.1
Case study design......................................................................................... 48
3.1.2
Case study protocol ..................................................................................... 48
3.1.3
Case selection .............................................................................................. 50
3.1.4
Data analysis ............................................................................................... 50
3.2
CASE 1: DESIGN, CONSTRUCT AND START-UP OF A CHEMICAL PLANT (GOOD PROJECT
PERFORMANCE) .................................................................................................................... 52
3.2.1
Brief case description .................................................................................. 52
3.2.2
Interview results on project complexity ....................................................... 52
3.2.3
Interview results on front-end activities ....................................................... 54
3.2.4
Overall case conclusion ............................................................................... 55
3.3
CASE 2: DEVELOPMENT AND CONSTRUCTION OF A NEW FACILITY (GOOD PROJECT
PERFORMANCE) .................................................................................................................... 55
3.3.1
Brief case description .................................................................................. 55
3.3.2
Interview results on project complexity ....................................................... 55
3.3.3
Interview results on front-end activities ....................................................... 56
3.3.4
Overall case conclusion ............................................................................... 58
3.4
CASE 3: DESIGN AND CONSTRUCT OF CHEMICAL PLANT (MARGINAL PROJECT
PERFORMANCE) .................................................................................................................... 58
3.4.1
Brief case description .................................................................................. 58
3.4.2
Interview results on project complexity ....................................................... 59
3.4.3
Interview results on front-end activities ....................................................... 60
3.4.4
Overall case conclusion ............................................................................... 61
3.5
CASE 4: MODIFICATION OF CURRENT FACILITY (POOR PROJECT PERFORMANCE) ...... 62
3.5.1
Brief case description .................................................................................. 62
3.5.2
Interview results on project complexity ....................................................... 62
3.5.3
Interview results on front-end activities ....................................................... 63
3.5.4
Overall case conclusion ............................................................................... 65
3.6
CASE 5: DEVELOPMENT OF NEW OFFSHORE ENERGY FACILITY (GOOD PROJECT
PERFORMANCE) .................................................................................................................... 65
3.6.1
Brief case description .................................................................................. 65
3.6.2
Interview results on project complexity ....................................................... 65
3.6.3
Interview results on front-end activities ....................................................... 67
3.6.4
Overall case conclusion ............................................................................... 68
3.7
CASE 6: CONSTRUCTION OF NEW FACILITY (MARGINAL PROJECT PERFORMANCE).... 69
3.7.1
Brief case description .................................................................................. 69
3.7.2
Interview results on project complexity ....................................................... 69
3.7.3
Interview results on front-end activities ....................................................... 70
3.7.4
Overall case conclusion ............................................................................... 71
3.8
CROSS CASE ANALYSIS ............................................................................................. 72
3.8.1
In which way do project professionals consider their project as complex?. 72
3.8.2
Adapting the front-end development phase to the particular complexity?... 74
3.8.3
Classification of projects according to their complexity level? ................... 75
3.8.4
Dealing with project complexity in the front-end phase .............................. 75
3.9
DISCUSSION .............................................................................................................. 76
3.9.1
The engineer as a project manager.............................................................. 77
3.9.2
Dynamics of project complexity ................................................................... 77
3.9.3
The need for an extensive complexity framework ........................................ 78
iii
CHAPTER 4 ....................................................................................................................... 79
GRASPING PROJECT COMPLEXITY: THE TOE FRAMEWORK........................ 79
4.1
4.2
4.3
4.4
4.5
4.6
4.7
CHAPTER 5 ....................................................................................................................... 95
NAP SURVEY STUDY ..................................................................................................... 95
5.1
METHODS ................................................................................................................. 95
5.1.1
Survey .......................................................................................................... 95
5.1.2
Sample.......................................................................................................... 96
5.1.3
Validity ......................................................................................................... 96
5.2
SURVEY DESIGN........................................................................................................ 97
5.2.1
Identifying the projects complexity ............................................................. 97
5.2.2
What was done in the front-end phase of the project? ................................. 98
5.2.3
How did the project perform? .................................................................... 101
5.3
DATA TREATMENT .................................................................................................. 102
5.3.1
Data collection ........................................................................................... 102
5.3.2
Data analysis ............................................................................................. 103
5.4
GENERAL SURVEY RESULTS .................................................................................... 104
5.4.1
The respondents ......................................................................................... 104
5.4.2
Project characterization ............................................................................ 105
5.4.3
Project driver(s) ......................................................................................... 105
5.4.4
Project performance .................................................................................. 106
6.6
6.7
7.1.1
Results total complexity, VIP effort and project performance ................... 139
7.1.2
Results for dimensions of complexity, VIP effort and project performance140
7.2
ACTIVITIES TYPICALLY PERFORMED IN THE FRONT-END PHASE .............................. 142
7.2.1
Activities in front-end: Value Improving Practices (VIPs) ........................ 142
7.2.2
Other activities in front-end development .................................................. 144
7.3
DIRECT RELATIONS WITH PROJECT PERFORMANCE ................................................. 146
7.4
MODERATED RELATIONSHIPS ................................................................................. 148
7.4.1
Contingency theory .................................................................................... 148
7.4.2
Analysis framework .................................................................................... 149
7.4.3
Relations between front-end development and project complexity ............ 150
7.4.4
Subgroup analysis to test for moderated relationships .............................. 153
7.5
SUMMARY OF RELATIONS FOUND BETWEEN FRONT-END ACTIVITIES, COMPLEXITY
AND PROJECT PERFORMANCE .............................................................................................. 157
7.6
WHAT IS THE INFLUENCE OF THE RESPONDENTS ROLE? ......................................... 160
7.6.1
Respondents role in the project ................................................................ 161
7.6.2
Role of the respondents company ............................................................. 163
7.7
DISCUSSION ............................................................................................................ 166
7.7.1
Methodological limitations ........................................................................ 167
7.7.2
Comparison with literature ........................................................................ 167
7.7.3
Managerial implications ............................................................................ 168
8.3
vi
vii
List of figures
FIGURE 1.1: THE WHEEL OF SCIENCE (WALLACE, 1971) ................................................................... 6
FIGURE 1.2: MODEL PROJECT COMPLEXITY / FRONT-END ACTIVITIES / PROJECT PERFORMANCE .................. 7
FIGURE 1.3: OVERVIEW OF THE EMPIRICAL PART OF THE RESEARCH .................................................... 10
FIGURE 1.4: DATA COLLECTION WITHIN THE NAP NETWORK COMPANY INVOLVEMENT........................ 10
FIGURE 1.5: OVERVIEW OF THE DISSERTATION ............................................................................... 12
FIGURE 2.1: THE INFLUENCE OF FRONT-END DEVELOPMENT (PHASE 1, 2, 3) ON THE VALUE OF A PROJECT
(HUTCHINSON & WABEKE, 2006) ....................................................................................... 25
FIGURE 2.2: OVERVIEW OF DIMENSIONS OF PROJECT COMPLEXITY (WILLIAMS, 2002) ........................... 36
FIGURE 2.3: STAKEHOLDER TYPOLOGY ACCORDING TO (MITCHELL ET AL., 1997) .................................. 41
FIGURE 3.1: SUMMARY OF SELECTED CASES, CASE 1 TO 6 ................................................................. 50
FIGURE 4.1: NEW AND TOTAL NUMBER OF ELEMENTS MENTIONED BY THE INTERVIEWEES. ................... 85
FIGURE 5.1: TIME SPENT TO COMPLETE THE SURVEY ...................................................................... 103
FIGURE 5.2: YEARS OF WORK EXPERIENCE (LEFT) AND EXPERIENCE AS PROJECT MANAGER (RIGHT).......... 104
FIGURE 5.3: PROJECT DRIVERS: QUALITY, SCHEDULE, COST ............................................................. 106
FIGURE 5.4: CUMULATIVE SCORE FOR PROJECT PERFORMANCE (N=54) ............................................ 107
FIGURE 5.5: NUMBER OF CASES AGAINST PERFORMANCE SCORES (N=54) ......................................... 107
FIGURE 6.1: SURVEY RESULTS: PERCEIVED COMPLEXITY (N=67 FOR T AND O, N=66 FOR E) ................. 113
FIGURE 6.2: ANSWERS RELATED TO APPLICATION OF A COMPLEXITY FRAMEWORK ............................... 132
FIGURE 6.3: ANSWERS RELATED TO THE BENEFIT OF APPLYING A COMPLEXITY FRAMEWORK AND ITS FORESEEN
USE TO CREATE AWARENESS ABOUT PROJECT COMPLEXITY AMONGST ITS STAKEHOLDERS ............... 132
FIGURE 6.4: USE OF THE COMPLEXITY FRAMEWORK IN DIFFERENT PROJECT PHASES ............................. 133
FIGURE 7.1: C (COMPLEXITY) AS A MODERATOR OF THE RELATIONSHIP BETWEEN A (FRONT-END ACTIVITIES)
AND B (PERFORMANCE) ................................................................................................... 149
FIGURE 7.2: OVERVIEW OF POTENTIAL RELATIONSHIPS .................................................................. 150
FIGURE 7.3: RELATIONSHIPS INFLUENCING PROJECT PERFORMANCE: RESULTS CURRENT DATASET ........... 158
FIGURE 7.4: RELATIONSHIPS COMPLEXITY, FRONT-END ACTIVITIES AND PERFORMANCE IN MORE DETAIL
(DASHED BLOCK FROM FIGURE 7.3).................................................................................... 159
FIGURE 8.1: OVERVIEW OF SELECTED CASES: SCORES ON PROJECT PERFORMANCE ............................... 174
FIGURE 9.1: TIME SPENT TO COMPLETE THIS SURVEY ..................................................................... 193
FIGURE 9.2: YEARS OF EXPERIENCE AS PROJECT MANAGER (LEFT) AND AT THE COMPANY (RIGHT) ........... 194
FIGURE 9.3: CUMULATIVE ELEMENT SCORES, N=64 ...................................................................... 195
FIGURE 9.4: CUMULATIVE ELEMENT SCORES PER GROUP, DISPLAYED IN AVERAGE NORMALIZED SCORES ... 199
FIGURE 9.5: HOW TO DEAL WITH PROJECT COMPLEXITY (%): MOST CONTRIBUTING T-ELEMENTS ........... 201
FIGURE 9.6. HOW TO DEAL WITH PROJECT COMPLEXITY (%): MOST CONTRIBUTING O-ELEMENTS........... 203
FIGURE 9.7: HOW TO DEAL WITH PROJECT COMPLEXITY (%): MOST CONTRIBUTING E-ELEMENTS ........... 204
FIGURE 9.8: VISUAL REPRESENTATION OF THE FINAL TOE FRAMEWORK ............................................ 213
FIGURE 10.1: DATA COLLECTION WITHIN THE NAP NETWORK OVERVIEW OF RESPONSES ................... 218
viii
List of tables
TABLE 2.1: DIRECTIONS FOR SOLVING PROJECT MANAGEMENT PROBLEMS FROM DIFFERENT PERSPECTIVES
(SHENHAR & DVIR, 2007A) ............................................................................................... 18
TABLE 2.2: SUCCESS MEASURES (SHENHAR ET AL., 2001) ................................................................ 22
TABLE 2.3: CRITICAL SUCCESS FACTORS, DIFFERENT LITERATURE SOURCES ............................................ 24
TABLE 2.4: NAMES FOR TYPICAL FED PHASES ................................................................................ 26
TABLE 2.5: STANDARD RECOMMENDED FRONT-END ACTIVITIES IN THE PROCESS INDUSTRY:..................... 27
TABLE 2.6: VALUE IMPROVING PRACTICES AS IDENTIFIED BY IPA AND CII ............................................ 28
TABLE 2.7: OVERVIEW OF CONTINGENCY FACTORS FOUND IN LITERATURE, DIVIDED INTO 5 MAIN CATEGORIES
AND A SIXTH CATEGORY OTHERS ....................................................................................... 32
TABLE 3.1: INTERVIEWEES AND THEIR INVOLVEMENT IN THE PROJECT ................................................. 52
TABLE 3.2: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 1 .................................. 53
TABLE 3.3: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 1 ........................................................ 54
TABLE 3.4: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 2 .................................. 56
TABLE 3.5: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 2 ........................................................ 57
TABLE 3.6: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 3 .................................. 59
TABLE 3.7: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 3 ........................................................ 60
TABLE 3.8: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 4 .................................. 62
TABLE 3.9: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 4 ........................................................ 64
TABLE 3.10: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 5 ................................ 66
TABLE 3.11: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 5 ...................................................... 67
TABLE 3.12: SUMMARY INTERVIEW RESULTS ON PROJECT COMPLEXITY, PROJECT 6 ................................ 69
TABLE 3.13: SUMMARY INTERVIEW RESULTS ON FED, PROJECT 6 ...................................................... 71
TABLE 3.14: RELEVANT FRONT-END ASPECTS ................................................................................. 76
TABLE 4.1: ELEMENTS CONTRIBUTING TO PROJECT COMPLEXITY FROM LITERATURE SOURCES ................... 82
TABLE 4.2: ELEMENTS (49) CONTRIBUTING TO PROJECT COMPLEXITY BASED ON 6 CASES, 18 INTERVIEWS . 86
TABLE 4.3: SUBCATEGORIES OF TOE ............................................................................................ 87
TABLE 4.4: TOE FRAMEWORK (50 ELEMENTS IN TOTAL) .................................................................. 88
TABLE 5.1: OVERVIEW OF VIPS / BEST PRACTICES AND SELECTION FOR INCLUSION IN THIS STUDY............. 99
TABLE 5.2: EXPLANATION OF VIPS CONSIDERED IN THE SURVEY ....................................................... 100
TABLE 5.3: OTHER FRONT-END ACTIVITIES CONSIDERED IN THE SURVEY (BASED ON CHAPTER 3) ............. 101
TABLE 6.1: SIGNIFICANT CORRELATIONS BETWEEN PROJECT PERFORMANCE AND PROJECT COMPLEXITY.... 111
TABLE 6.2: SIGNIFICANT CORRELATIONS BETWEEN PROJECT PERFORMANCE AND PROJECT COMPLEXITY
ELEMENTS ..................................................................................................................... 112
TABLE 6.3: INTER-CORRELATIONS FOR THE PERCEIVED COMPLEXITY SCORES FOR T, O AND E COMPLEXITY 113
TABLE 6.4: SPEARMAN CORRELATIONS BETWEEN .......................................................................... 115
TABLE 6.5: CORRELATION RESULTS T-ELEMENTS ........................................................................... 118
TABLE 6.6: CORRELATION RESULTS O-ELEMENTS .......................................................................... 120
TABLE 6.7: CORRELATION RESULTS E-ELEMENTS ........................................................................... 123
TABLE 6.8: TOE WITH PROPOSED ADAPTATIONS........................................................................... 126
TABLE 6.9: THE MOST COMPLEX ELEMENTS AND THEIR LINK TO THE TOE FRAMEWORK ........................ 128
TABLE 6.10: ASPECTS OF PROJECT COMPLEXITY NOT IN TOE FRAMEWORK IN VIEW OF RESPONDENTS ..... 130
TABLE 6.11: RELIABILITY STATISTICS ........................................................................................... 134
TABLE 6.12: CORRELATIONS BETWEEN AGGREGATED COMPLEXITY SCORES AND PERCEIVED COMPLEXITY .. 134
TABLE 7.1: DESCRIPTIVE STATISTICS (VIP EFFORT, TOTAL COMPLEXITY, ON PROJECT PERFORMANCE) ...... 139
TABLE 7.2: DESCRIPTIVE STATISTICS (VIP EFFORT, T-COMPLEXITY, ON PROJECT PERFORMANCE) ............ 140
TABLE 7.3: DESCRIPTIVE STATISTICS (VIP EFFORT, O-COMPLEXITY, ON PROJECT PERFORMANCE)............ 141
ix
TABLE 7.4: DESCRIPTIVE STATISTICS (VIP EFFORT, E-COMPLEXITY, ON PROJECT PERFORMANCE) ............ 141
TABLE 7.5: SURVEY RESULTS OF VIP QUESTIONS........................................................................... 143
TABLE 7.6: SURVEY RESULTS OF QUESTIONS ABOUT THE OTHER FRONT-END ACTIVITIES ..................... 145
TABLE 7.7: OVERVIEW OF SIGNIFICANT CORRELATIONS .................................................................. 146
TABLE 7.8: SIGNIFICANT CORRELATIONS BETWEEN PROJECT PERFORMANCE AND FRONT-END ACTIVITIES .. 147
TABLE 7.9: SIGNIFICANT CORRELATIONS BETWEEN COMPLEXITY AND FRONT-END ACTIVITIES ................. 152
TABLE 7.10: SIGNIFICANT CORRELATIONS WITHIN SUBGROUPS ........................................................ 155
TABLE 7.11: KRUSKAL-WALLIS TEST RESULTS: SIGNIFICANT DIFFERENCES BETWEEN PROJECT MANAGERS,
BUSINESS REPRESENTATIVES AND TEAM MEMBERS (N=67) ..................................................... 161
TABLE 7.12: KRUSKAL-WALLIS TEST RESULTS: SIGNIFICANT DIFFERENCES BETWEEN OWNERS, (MANAGING)
CONTRACTORS, SUBCONTRACTORS (N=60).......................................................................... 164
TABLE 8.1: CASE SELECTION PROCEDURE ..................................................................................... 172
TABLE 8.2: SUMMARY OF SELECTED CASES .................................................................................. 173
TABLE 8.3: SUMMARY OF CASE RESULTS ..................................................................................... 182
TABLE 9.1: FINAL TOE FRAMEWORK, 47 ELEMENTS IN TOTAL ......................................................... 191
TABLE 9.2: SURVEY QUESTION ON ADDITIONAL EFFORT FOR ELEMENT(S) MOST CONTRIBUTING TO PROJECT
COMPLEXITY................................................................................................................... 192
TABLE 9.3: OVERVIEW OF RESPONSES ........................................................................................ 193
TABLE 9.4: MOST CONTRIBUTING ELEMENTS (MAX 3 SELECTIONS PER PARTICIPANT)............................ 196
TABLE 9.5: LEAST CONTRIBUTING ELEMENTS (MAX 3 SELECTIONS PER PARTICIPANT) ............................ 197
TABLE 9.6: SIGNIFICANT RESULTS FOR MANN-WHITNEY TEST (DISTINGUISHING OWNERS AND CONTRACTORS)
................................................................................................................................... 198
TABLE 9.7: SUMMARY OF SURVEY FINDINGS ON APPLICATION OF THE TOE FRAMEWORK ...................... 206
TABLE 9.8: SUMMARY OF SURVEY FINDINGS ON ADDED VALUE OF THE TOE COMPLEXITY FRAMEWORK ... 208
TABLE D.1: CORRELATIONS T-ELEMENTS AND PERCEIVED COMPLEXITY .............................................. 268
TABLE D.2: CORRELATIONS O-ELEMENTS AND PERCEIVED COMPLEXITY ............................................. 276
TABLE D.3: CORRELATIONS E-ELEMENTS AND PERCEIVED COMPLEXITY .............................................. 285
TABLE D.4: SUMMARY OF ELEMENT EVALUATIONS ........................................................................ 292
List of abbreviations
ACAT
ADM
APM
ANOVA
BDP
CAPEX
CIFTER
CII
CO
CoPS
CPM
CRC
CRI
DCP
DMO
ENAA
EPC
EPCC
EPCM
FED
FEL
FID
FPO
GAPPS
HS(S)E
JV
IBC
ICB
IPA
IPMA
NAP
NCTP
OIP
PERT
PM
PMI
UCP
USAF
SHE
TOE
VIP
WP
xi
xii
Chapter 1
Introduction
Capital projects delivered us the large facilities and assets needed to live our modern lives.
Energy supply, infrastructure, transportation, telecommunication, buildings, and consumer
electronics: all were established as a tangible result of projects, in one way or another.
Benchmarking data across all industry sectors, however, is indicating that there is still a
problem with the successful delivery of capital projects (IPA, 2011). Amongst 300 global
megaprojects (budget for each project larger than 1 billion 2010 US$), 65% failed to meet
their business objectives (Merrow, 2011). Investigating about 600 projects in business,
government and nonprofit sectors, with budgets between $40.000 and $2.5 billion, Shenhar
and Dvir reported a failure of even 85% when looking at meeting time and budget goals
(Shenhar & Dvir, 2007b). Hence across the board, from small projects to mega projects,
serious problems are reported.
Specific examples of projects that dont progress according to their plans (money wise or
time wise) are numerous; think for some examples from the Netherlands of the construction
of the underground Noord-Zuidlijn in Amsterdam, the renovation of the Rijksmuseum
in Amsterdam, the construction of the cargo railway Betuweroute between Rotterdam
and Germany, and the implementation of new ICT services for the Dutch Police Forces. All
these projects are late and over budget and in case of the new ICT-services project even
without properly meeting the project scope (Stuiveling & van Schoten, 2011).
Despite a rather poor track record of project performance, the projectification of the
world is continuing (Maylor, Brady, Cooke-Davies, & Hodgson, 2006). With the capital
market looking for predictability and strong returns, poor project performance in terms of
delivering late and above budget is not acceptable (Mc Kenna, Wilczynski, & van der
Schee, 2006). Therefore, improving project performance is of vital importance.
Capital projects, as introduced above, can be considered as projects that aim to deliver socalled complex products and systems (Hobday, 1998). Such complex products and systems
(CoPS) are defined as high cost, engineering-intensive products, systems, networks and
constructs () (where) the term complex is used to reflect the number of customized
components, the breadth of knowledge and skills required and the degree of new knowledge
involved in production, as well as other critical product dimensions (p.690). Research into
CoPS also shows the necessity to improve project performance (Barlow, 2000; Hobday,
Rush, & Tidd, 2000).
This chapter sets the scene for the research undertaken. First, the research background is
provided. Next, the research objective and research questions are formulated and the
research scope is defined. How to answer these research questions within the scope is
described subsequently in the research approach. Next, the relevance of the research is
explained. To conclude this chapter, the structure of the dissertation is presented.
1
1.1 Why do capital projects still fail, what can we do about it?
Project failure in terms of cost overrun and time delay is being investigated for years now
(Flyvbjerg, Bruzelius, & Rothengatter, 2003; Hall, 1981; Morris & Hough, 1987; Sauser,
Reilly, & Shenhar, 2009; Thamhain & Wilemon, 1986). Numerous reasons for such project
failures can be found in project management literature. More than a decade ago, the
Handbook of Project-Based Management already listed several pitfalls of project
management (Turner, 1999):
- Pitfalls in establishing the project (project plans are not aligned with business
plans, procedures for managing projects are not defined, priorities are not
communicated to parties involved, there is no shared vision) (p. 74)
- Pitfalls in project planning (plans developed on a single level, using cumbersome
tools, creativity discouraged, unrealistic estimates) (p. 75)
- Pitfalls in organizing and planning (lack of co-operation, resource providers not
committed, resources not available when required, management responsibility not
defined, poor communication, technical vs project management) (p. 77)
- Pitfalls in control (purpose of control is not understood, progress not monitored
against the plan, ineffective review meetings, responsibility without authority) (p.
79)
These pitfalls are all in the management area and, in the words of Turner, can be considered
as management mistakes. More often, managerial reasons are suggested to be a cause for
project failure (Lindahl & Rehn, 2007; Sauser et al., 2009).
According to literature, another reason for project failure would be the increasing
complexity of projects and underestimation of this complexity (Neleman, 2006; Williams,
2002, 2005). The complexity of projects is assumed to increase as a result of rapid changes
in environment, increased product complexity and increased time pressure (Williams,
1999). Therefore research has been undertaken to better understand project complexity
(Bosch-Rekveldt & Mooi, 2008; Dombkins & Dombkins, 2008; Geraldi & Adlbrecht,
2007; Hass, 2007; Maylor, Vidgen, & Carver, 2008; Vidal & Marle, 2008; Williams, 2002).
At this stage, however, common understanding of the concept of project complexity is
lacking. Research even expressed the need for the development of new models and
theories which recognize and illuminate the complexity of projects and project
management, at all levels (Winter, Smith, Morris, & Cicmil, 2006b), p. 642.
Given the high number of project management handbooks, such as (Cleland & King, 1983;
Kerzner, 2003; Meredith & Mantel, 2006; Pinto, 1988, 2004; Turner, 2008; Turner &
Simister, 2000), one could conclude that there is an enormous amount of knowledge on
project management available to deliver projects on time and within budget. Other recent
literature, however, still provides examples of failed projects: the RandstadRail project
(Koppenjan, Veeneman, Van der Voort, Ten Heuvelhof, & Leijten, 2011), the Mars
Climate Orbiter (Sauser et al., 2009) or the Channel Tunnel project (Chang & Ive, 2007).
These studies have in common that they advocate for a broader approach in the
management of projects, focused beyond the old project management control perspective.
To improve the current situation, traditional project management approaches could be
complemented by process approaches (de Bruijn, ten Heuvelhof, & in 't Veld, 2003) and
program management approaches (Pellegrinelli, 2011).
Why would the traditional project management not be suitable for todays projects?
Nowadays, projects are performed in highly dynamic environments, involving multiple
stakeholders with different perspectives and encountering technological challenges. Hence
2
Chapter 1: Introduction
Chapter 1: Introduction
This proven interest in front-end activities makes the NAP network very well-suited for
participation in our research.
Deduction
Theory
Empirical
generalizations
Induction
Hypotheses
Observations
Chapter 1: Introduction
Often interviews are part of a case study or a survey study. Interviews can have a structured
or an unstructured character (and all steps in-between). In unstructured interviews there is
no standard questionnaire but questions arise during the interview, giving the possibility to
elaborate on the answers of the respondent. In structured interviews, there is a strict
protocol or questionnaire to be followed. Where case studies more often use the
unstructured or semi-structured interviews, surveys more often use structured interviews.
The use of different research instruments and sources of information within one research is
called triangulation (Tashakkori & Teddlie, 1998).
1.3.2 Methods applied in this research
The basic underlying conceptual model of this research consists of three building blocks,
see Figure 1.2. Project performance is considered the dependent variable and project
complexity as well as front-end development activities are the independent variables.
however, is a high level one and these main variables first need further operationalization
and hence exploration of the field, which is at the inductive side of the spectrum. Therefore
this research starts with an exploratory character and progresses towards more evaluative
phases, as the detailed phase description shows.
In the first phase of the research, the concept of project complexity is explored and a model
representation of project complexity is developed. Also relevant front-end activities are
explored and it is investigated to what extent the front-end phase currently is adapted to the
particular project complexity. Although from literature there are some starting points on
modeling project complexity (Dombkins, 2008; Geraldi, 2008b; Hass, 2007; Williams,
2002) in-depth investigations towards real projects are not yet reported. To gather in-depth
information on activities in the front-end development phase and the factors determining
and influencing project complexity an exploratory case study approach is chosen. In a
limited number of exploratory case studies, semi-structured interviews are held with project
team members and written materials (official reports, project archives) are investigated. To
prepare for the case study, all building blocks from Figure 1.2 are explored by means of a
literature review. The exploratory case study is performed in one company, an active
member of the NAP network, with a very structured project management approach. By
choosing different projects from one company -all projects were executed based on the
same project management process- variations in the standard front-end activities applied in
a project were limited.
For the case study, a multiple-cases embedded design (Yin, 2002) is used, in which each
case represents a completed project. The embedded design refers to the different
dimensions to be analyzed within one case: project complexity, the activities in the frontend development phase and the project performance. The multiplicity refers to the inclusion
of a number of projects opposed to inclusion of a single project. The inclusion of multiple
cases in an embedded design is assumed to give a broader view on the dimensions under
consideration (Yin, 2002). Per case, semi-structured interviews are held with multiple
people involved in the project. The information obtained from the case studies is used for
development of the project complexity framework and for defining the relevant front-end
development activities to deal with project complexity. In the development of these
frameworks, the empirical findings are confronted with literature findings.
The second phase of the research is focused on finding the potential relationships between
the building blocks in Figure 1.2. Relations between project complexity, the activities in the
front-end development phase and the project performance are investigated. To obtain
sufficient data to draw statistically relevant conclusions from, a survey study is done
amongst a large number of completed projects in the Dutch process industry. The survey is
distributed via the NAP network. Despite NAPs interest in improving the front-end
development phase, not all the companies are at the same level of application of front-end
development activities. However, they do speak the same language and are well aware of
developments in improving project management in their sector.
The survey study is used to investigate and quantify potential relationships between project
complexity, project management (e.g. front-end activities) and project performance, hence
to further develop and operationalize the conceptual model of Figure 1.2. Also the newly
developed complexity framework is evaluated in detail. The research in this phase is
quantitatively oriented and, together with Phase I, follows an exploratory mixed methods
Chapter 1: Introduction
approach (Blaikie, 2009; Tashakkori & Teddlie, 1998): the qualitative part (Phase I), is
followed by a quantitative part (Phase II).
The third phase of the research consists of in-depth case studies. Multiple cases are
studied, exploring contractor and owner perspectives and following again a multiple cases
embedded design (Yin, 2002). Based on the quantitative outcomes of the second phase, this
case study investigates more deeply in what way specific front-end activities contributed to
the project performance. Actually this phase focuses on the assumed direct relation between
front-end activities and project performance in Figure 1.2. Phase III has a more explanatory
character and is qualitatively oriented.
The second and the third phase together are again an example of mixed methods approach,
but now it is explanatory rather than exploratory (Blaikie, 2009; Tashakkori & Teddlie,
1998). Some of the quantitative findings of Phase II are further explained by means of the
qualitative in-depth case studies in Phase III.
The fourth and final phase of the research is a validation survey, in which it is investigated
to what extent the different aspects of complexity indeed contribute to project complexity
and how the newly developed framework to grasp project complexity (Phase I en II) could
help in improving project performance in future projects. The questions in this survey are
not project specific but sector specific to enable generalization of the results outside the
specific companies involved. The survey is sent to two owner companies and two
contractor companies, all of which are participating in the NAP network. The research in
this concluding phase is partly quantitative and partly qualitative. Quantitative, as to what
extent each of the elements of the complexity framework indeed would contribute to project
complexity and qualitative in how the framework could help in improving project
performance.
A summary of these four phases, the methods used, the main content and main results is
provided in Figure 1.3.
Across the different phases, the Wheel of Science (Figure 1.1) is followed several times.
The case study in the first phase starts with observations, which are generalized and
confronted with theory, resulting in a framework to characterize project complexity. The
second phase evaluates the complexity framework and explores relations between
complexity, front-end activities and project performance. Again results are confronted with
literature findings. Based on the results of the second phase, the Wheel of Science was
followed again in the third and the fourth phase. In the third phase to deepen the Phase II
results by means of qualitative in-depth interviews and in the fourth phase to validate the
developed complexity framework. To strengthen the results, links with literature are
established where possible.
The constructivist character of the research consists of the appreciation of different
perceptions and dimensions of project complexity. The constructivist character of this
research is also reflected in including broader discussions on the use of the models
developed and the mere fact that projects are investigated with particular attention for their
context.
Figure 1.4: Data collection within the NAP network company involvement
10
Chapter 1: Introduction
Based on the findings of Chapter 7, another case study is performed to study in-depth how
the relevant front-end activities actually are applied and contribute to project performance,
which is presented in Chapter 8. This chapter comprises the third phase of the research.
Subsequently, results of a second survey are presented in Chapter 9. With this survey study,
the developed complexity framework is further evaluated and validated. This chapter
comprises the fourth phase of the research.
Finally, Chapter 10 provides the discussion as well as the conclusions and
recommendations for further research.
12
Chapter 2
Literature review
This chapter presents the literature review which was performed to build knowledge and
find current gaps in the literature. First, a project is defined and the development of project
management over the years is sketched, followed by observed trends in project
management research. Based on these trends and identified gaps, the focus areas for the
current research are further elaborated: project performance, front-end activities,
contingency theory, project complexity and stakeholders perspectives. This chapter
concludes with summarizing the starting points for the empirical work, described in the
subsequent chapters.
Throughout this dissertation, we focus on engineering projects: projects that create a
technical artifact. Therefore also general project management literature was read in view of
such engineering projects.
13
During a typical project life-cycle, the following project phases or stages are distinguished
(Turner, 2008):
- Proposal & initiation (concept and feasibility)
- Design & appraisal
- Execution & control
- Finalization & close out (p.14)
A similar distinction of these general project phases is presented by others (Cleland &
King, 1983; Leybourne, 2007; Murray, 2009), albeit with some different names. In spite of
the unique character of projects, elements of these phases are present in all projects. The
proposal & initiation and design & appraisal phases of the typical project life cycle are
often called the front-end development phase of a project. The ultimate goal of a project is
the creation of value for the project stakeholders, with the content of the term value being
different for the various stakeholders (Achterkamp & Vos, 2008).
The importance of the front-end development phase (FED) for the value creation or project
performance is expressed in literature (Flyvbjerg et al., 2003; Morris, 1994; Morris et al.,
2006a). However, this claim is rarely accompanied by hard scientific evidence or
underlying data. Some institutes do claim such evidence (IPA, CII), but do not make it
publicly available. Effort spent in the front-end development phase is called front-end
loading (FEL). The challenge would be to balance FEL and effort spent during project
execution, such that sufficient front-end development is done for an optimal project result
after project execution. Here sufficient refers to enough, but not too much.
Between the typical project phases, stage gates are defined where the outcome of a certain
phase is independently evaluated against pre-set conditions (Murray, 2009; Winch, 2002),
resulting in go / no go decisions. Based on the evaluation, the project can continue in the
next phase, can be adjusted or is stopped. Reviewing the project after every project phase
enables the possibility of early failure detection which is crucial in controlling project costs.
A rule of thumb from most industries says that costs of correcting a mistake non-linearly
increase when the project progresses (Turner, 2008). Therefore, serious attention should be
paid to the early project phases. When progressing through the different stages of the
project life cycle, generally uncertainties are reduced. Generally, uncertainties and risks
play a major role in todays project management (Hillson & Simon, 2007).
3.
17
Theoretical perspective
Project leadership
Transformational leadership
Project strategy
Strategic management
Kloppenborg and Opfer grouped the research trends into the nine PMBoK knowledge areas,
thereby introducing a possible limitation because they do not explicitly include aspects like
18
strategy, external factors and human behavior. According to Morris, the challenge for
further developments of the Bodies of Knowledge would be not to develop a one size fits
all approach irrespective of context and contingency, but an approach where intelligent
and reflective practitioners could make their own informed decisions on principles,
concepts, models and techniques to use (Morris et al., 2006a). Suggestions supporting this
view were done in research updating the APM body of knowledge 4th edition (Morris,
Jamieson, & Stepherd, 2006b). The recommendations include the emphasis on the link to
the business purpose, the nature of the context of a project and enhanced positioning of
people factors.
In the PMI project management handbook of 1988, Pinto briefly described his vision on the
future of project management (Pinto, 1988). He envisioned a need for the development of
project managers who have the skills and tools to make a project successful. Project
managers should be formally trained to obtain commonly accepted project management
skills. The importance of the focus on the project manager is shared by Kolltveit et al. who
discussed six different perspectives on project management: task, leadership, systems,
stakeholder, transaction cost and business perspectives (Kolltveit et al., 2006). In the books
on modern project management they investigated, the task and leadership perspectives were
dominant. Further, the leadership perspective was more present in modern literature than in
the traditional literature. They argue that the stakeholder perspective, not so much present
in modern project literature, but strongly related to project success, requires more attention
in future. Since project management and hence project managers have to deal with both
social and technological aspects, the role of the project managers is a role of integrating and
leading the work of specialists, a role of facilitating. Therefore the integration of social and
technological aspects requires more attention in future project management literature.
Also Williams emphasized the need for research to develop new paradigms for complex
projects (Williams, 1999). Projects are becoming more and more complex because of the
increasing complexity of the products being developed and the increasing time pressure on
current projects. It is argued that classical project management techniques such as
decomposition models cannot be used for the complex projects. New models and
techniques are needed to analyze complex projects, as well as new methods to manage
them. The following recommendations for further developments in project management are
given:
- Improvement of classical methods (bottom-up decomposition, network models,
time and cost risk models) using simulation models.
- Top-down holistic models, such as System Dynamics.
- Combination of hard quantitative data with soft data.
In his view, integration, systemic management, simultaneous management, use of
multidisciplinary teams and managing the functional plan simultaneously and
interdependently should be elements of the project management style, including attention
for a multi-project environment: program management.
Smyth and Morris investigated methodological issues in project management research
published in the International Journal of Project Management (Smyth & Morris, 2007). In
the majority of project management research, positivism and/or empiricism were used as
the methodological base. However, both positivism and empiricism are based on linear
thinking and best suited for closed cause-effect models, not addressing context or
distinguishing between generic and particular explanations. Therefore, they suggested
future application of critical realism, placing research in context both in theory and practice.
19
Recently, research into project management was categorized in seven schools of thought
(Sderlund, 2011). Based on 305 articles in 30 high ranking journals (like Academy of
Management Journal, Journal of Operations Management, Management Science and R&D
Management) outside the specific project management journals, the following
categorization was developed:
1. Optimization School (logic-based, prescriptive research drawing on management
science, optimization techniques and systems analysis),
2. Factor School (empirical research relying on descriptive statistics on the criteria
and factors of project success and failure),
3. Contingency School (empirical research, case-study-based and survey-based
research on the differences between projects, characteristics of projects and
contextual dimensions),
4. Behaviour School (interpretative and descriptive research on organizational
behaviour, processes and learning in projects),
5. Governance School (prescriptive research on governance and contract problems
in projects),
6. Relationship School (descriptive case-study research on relations between actors
in projects),
7. Decision School (descriptive and interpretative research on politics and decisionmaking in projects). (p.158).
These seven schools of thought all have their own main focus of analysis, research
approach and methodology and key-questions to be answered. In fact they represent seven
separate theories of project management. In contrast to striving for one unified theory of
project management, Sderlund stresses the importance of these different perspectives: by
embracing pluralism, project management research might be better equipped to explore
and explain the difficulties of generating, forming, managing and even killing projects
such analysis would benefit from a comprehensive view on project processes and the use of
multiple theories (p.169). This dissertation therefore embraces the lines of thought of
several of the schools as distinguished above including the factor school, the contingency
school, the behavior school and the decisions school.
Focusing on this contingency school: several researchers suggested a contingency approach
in project management (Engwall, 2003; Sauser et al., 2009; Shenhar & Dvir, 1996; Smyth
& Morris, 2007; Williams, 2005). They suggest adapting project management to the context
in which the project takes place, in order to improve project performance. Summarizing the
research trends in the field of project management: it is about context. But still, the ultimate
goal of project management research is to improve project performance. What does
literature say about assessing project performance?
20
21
Commercial success
Creating a large market share
Regarding the budget goals, amongst others the following financial measures can be used to
decide whether or not the project is financially viable: the net present value, the internal
rate of return and the payback period of capital investment projects (Mc Kenna et al.,
2006). These measures are defined as follows (Kerzner, 2003):
- The net present value equates the discounted cash flows against the initial
investment. (p.584),
- The internal rate of return is the discount rate where the present value of the cash
inflows exactly equals the initial investment. (p. 585),
- The payback period is the exact length of time needed for a firm to recover its
initial investment as calculated from cash inflows. (p.582).
The actual financial result of a project is compared to the initial estimates to assess the
projects success in terms of finances.
However, how realistic are the initial cost and schedule estimates? Both owners and
contractors are struggling to make cost and schedule estimates that are on the one hand as
realistic as possible (difficult amongst others because of uncertainties and risks) and on the
other hand as competitive as needed. Also, strategic behavior might influence such
estimates. For example, too low cost estimates accompanied by too high expected benefits
are made in order to get the project started (Flyvbjerg et al., 2003). Once started, it is more
difficult to stop, particularly if the technical artifact to deliver is indivisible: half a bridge is
not a bridge. Or, opposed to cost underestimation, also cost might be overestimated on
beforehand to be sure the whole budget is reserved, for example in a situation where change
orders are not acceptable. The overestimation of costs and hence having an ample budget
(once agreed upon), can lead to gold-plating: unnecessary spending of the budget to
embellish the result although it is not needed to fulfill the project requirements. Concerning
the cost and schedule estimates, estimates should be range estimates rather than point
estimates, because of the uncertainties in the project (Turner, 2008).
When a budget is assigned based on a range estimate, the management however should also
realize this budget was based on a range estimate. For example with a p50 budget, there is
50% chance of delivering within budget (including chance on gold-plating) and 50%
chance of delivering above budget.
22
The above aspects of cost and schedule estimates illustrate potential strategic behavior of
the actors involved, resulting in either an under- or overestimation of project cost and
schedule, which makes it difficult to assess the real value of the estimation. Carefully
looking at the incentives of an actor and the rewarding mechanisms in an organization (also
on the project selection system) might help to better assess the value of the estimates. To
monitor whether a project is successful during its execution, besides cost and schedule
progress often Earned Value Analysis (EVA) is performed (Kerzner, 2003): this is the
value of the actual work done, which however is more difficult to quantify than just cost or
schedule progress.
Based on subjective definitions of successful performance, Menches and Hanna developed
a performance measurement index with the following six variables: actual percent profit,
percent schedule overrun, amount of time given, communication between team members,
budget achievement, and change in work hours (Menches & Hanna, 2006). Other measures
than the traditional cost and schedule performance measures are more often used. For
example, the number of change orders is used as a performance indicator in Project
Definition Rating Index (PDRI) studies (Gibson, Wang, Cho, & Pappas, 2006; Nicholas,
2004): the lower the costs associated with change orders, the more successful was the
project. Lewis et al. measured project performance by distinguishing four areas: technical
knowledge, commercial objectives, on time and within budget (Lewis, Welsh, & Dehler,
2002). Tatikonda and Rosenthal operationalize project execution success by the extent to
which the project objectives are met in terms of technical performance, unit cost, time to
market and a combination of all objectives (Tatikonda & Rosenthal, 2000). An extension to
the so-called classical iron triangle of project success (cost, schedule and quality) would be
the customers perspective and their satisfaction with the outcome of the project (Winter &
Szczepanek, 2008)(Bakker, Arkesteijn, Bosch-Rekveldt, & Mooi, 2010). This, however, is
more difficult to objectively measure.
Therefore, it is still commonly accepted to limit the measures of project success towards the
traditional three that can be objectively measured: meeting time, budget and (technical)
specifications. When assessing project performance using these traditional measures,
potential strategic intentions of the actors involved should not be forgotten. The measures
of project success are also called success criteria. What are the factors that, according to
literature, help in achieving project success?
2.4.3 Critical success factors
Critical success factors are those factors that enable project success. Different literature
sources list different factors contributing to project success; see Table 2.3.
Common factors in the three oldest lists are related to project mission, project planning and
control, top management support, and customer involvement. Although Morris and Hough
rightly indicate that perception of success and factors affecting success (and failure) will
develop, the three oldest lists represent rather universal factors for project success. With
universal is meant that they would apply to a project regardless of the specific projects
context. In addition to the universal project success factors, Engwall and colleagues
promote a more contextual approach: successful management of a project has to be
contingent upon the project content (Engwall, 2003). Based on two case studies they
suggest adding the historical and organizational context of the project when determining
success factors.
23
Major differences are observed between the results of the most recent research by Bakker et
al. and the other three (Cleland & King, 1983; Morris & Hough, 1987; Pinto, 1988).
Differences can be explained by sector influence and time influence. The research of
Bakker et al. was performed within the process industry in which safety plays a dominant
role, thus explaining why Safety, Health, Environment (SHE) compliance scores that high.
The influence of time seems reflected in the importance of risk management in achieving
project success. Risk management only recently is considered to play a prominent role in
project management (Charette, 1996; Kwak & Ingall, 2007). The perceived importance of
trust also surprised Bakker and his colleagues and further research into operationalization
of trust was recommended (Bakker et al., 2010).
Table 2.3: Critical success factors, different literature sources
(Bakker et al., 2010)
1. Risk management
2. SHE compliance
3. Trust
4. Cost management
(Pinto, 1988)
1. Project mission
2. Top management
support
3. Project schedule
and plans
4. Client
consultation
5. Value focused
5. Personnel
5. Schedule
6. Team composition
6. Technical tasks
6. Implementation
8. Monitoring and
feedback
7. Organization and
contract strategy
8. Communication and
controls
9. Communication
9. Human qualities
10. Troubleshooting
10.Resource management
7. Client acceptance
In Table 2.3, explicit attention for the influence of leadership on project success is not
present, although recent publications emphasize the importance of leadership (style) for
project success (Turner & Mller, 2005). Also missing in Table 2.3 are aspects of
stakeholder involvement, that are considered to heavily influence the project success
(Olander & Landin, 2005). Several of the critical success factors in Table 2.3 relate to the
front-end development phase of a project. Hence the importance of the front-end
development phase for project performance, as already mentioned previously, is confirmed.
decide whether or not the project is worth investing resources in; so enabling them to take
the final investment decision (FID). This image consists of the business needs that lead to
the initiation of this project and the path chosen to meet these needs (objectives, scope,
design basis, project planning, required resources (financial / organizational) and risks
involved).
25
FED1
FED2
FED3
(Turner, 2008)
(Morris & Hough, 1987)
(de Groen et al., 2003;
Oosterhuis et al., 2008)
(IPA, 2009b)
(Hutchinson & Wabeke,
2006)
Concept
Pre-feasibility
Define
business case
Appraise
Identify and
assess
Feasibility
Feasibility
Do conceptual
design
Select
Design
Design
Do basis
engineering
Define
Select
Define
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), although new, important inputs from the business perspective
should not be discarded by definition. The different steps (high level) in which the scope
and other deliverables are developed during FED1, FED2 and FED3 are:
-
FED1 - During FED1, the project objectives (strategic and commercial) are set. A
business case for the project needs to be delivered together with the constraints on the
project performance (budget, time, quality) and a functional description of the asset
(input, throughput, output). Furthermore, project risks need to be assessed, available
technologies need to be explored and the execution of FED2 and FED3 needs to be
planned (Oosterhuis et al., 2008). FED1 is about defining what the team is trying to
do (Merrow, 2002). Obviously, this phase is not aiming for fully detailed designs and
estimates, a typical accuracy of +/- 40% is aimed for (Oosterhuis et al., 2008).
- FED2 - In FED2, the aim is to identify the best way to meet the project objectives and
to select an option. Technological, process related and commercialization alternatives
are identified and for the alternatives, a preliminary scope and execution plan is
developed. For each alternative the value is assessed. FED3 is prepared. The accuracy
of estimates typically is +/- 20%. After FED2, one of the alternatives is selected for
FED3.
- FED3 - FED3 is devoted to defining the preferred alternative to a level that is
sufficiently detailed for the final investment decision (e.g. refined scope, contracting
plan). The scope is frozen (as much as possible) and final estimates are prepared (+/10%). Final execution and implementation plans are developed. FED3 is seen as the
true transition point between identification and delivery of value (Walkup & Ligon,
2006). Detailed design is often part of the project execution phase, after a positive final
investment decision is taken.
For each of the FED phases, suggested key deliverables and key activities are determined;
see Table 2.5 for an example from the process industry. These key deliverables and key
activities together comprise the standard front-end activities in the process industry.
In case a company has a project management system in place, key deliverables and key
activities will be similar to those presented in Table 2.5. 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 deliverables (IPA, 2009a).
Because of the special nature of VIPs, IPA recommends to facilitate the execution of these
practices by a person external to the project team, who possesses the skills to maximize the
26
outputs that can be gained (IPA, 2009a). Despite IPAs own interest in external facilitation,
external facilitation 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 maximize the
value that is created (de Groen et al., 2003).
Table 2.5: Standard recommended front-end activities in the process industry:
Key deliverables and key activities in the different FED phases,
based upon (Oosterhuis et al., 2008)
Key activities
Key deliverables
FED1
Business goals
Project objectives
Requirements on project premises
FEL strategy
Cost estimate (+/- 40%)
WBS level 1 schedule
Initial Hazard and Operability study (HAZOP)
Risk register
Contracting strategy
Technology review
Project execution plan (incl human factors,
alliances, benchmarking, innovation)
FED2
Basic engineering
Cost and revenue assessment
Prepare level 3 schedule
Analyse safety issues
Risk identification and management
Define project funding strategy
Prepare the contracting plan
Define project strategic interfaces
Team building
Different organizations developed lists of value improving practices, also called best
practices, see Table 2.6. The organizations only list those practices for which they 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. Searching
scientific literature, however, did not provide sound evidence for the actual value of
applying value improving practices.
27
The question is how the general application of best practices or value improving
practices should be considered, taking into account the earlier shown ideas on one size
does not fit all (Shenhar, 2001). Applying a contingency approach could be a way to
differentiate in the application of these practices.
organization (Lawrence & Lorsch, 1967). They concluded that by stimulating integration
within the organizations, the different impact of environmental change on different
departments might be counterbalanced. They also saw rate of change as a contingency
factor.
Besides rate of change and technological complexity, also task uncertainty can be
considered an environmental contingency. Galbraith argued that the more uncertain the task
is, the more information has to be processed, thus shaping the communication and control
structure of an organization (Galbraith, 1973). Thompson also argued that (uncertainties of)
the environment directly shape the organizational structure, with three different
technologies and three different levels of interdependence between activities in the
workflow, to be handled at different hierarchical levels, thus shaping the organization
(Thompson, 1967).
Pugh at al concluded that the main contingency factor for structuring was size (Pugh,
Hickson, Hinings, & Turner, 1969): larger organizations were more structured. Based on a
study towards the administrative history of about 100 of Americas largest enterprises,
Chandler stated that structure follows strategy: companies need to maintain a fit between
strategy and their structure in order to perform well, with their strategy being influenced by
the changing economic environment (Chandler, 1962), so in fact strategy being a
contingency factor.
Hence, from this historical overview, the most important contingency factors for
organization structure in order to achieve optimal company performance can be listed as:
strategy, rate of change, size, task uncertainty and technology (Donaldson, 1996). Whether
and how these contingency factors could be used in a contingency approach in project
management is further elaborated in Section 2.6.4.
2.6.2 Structural contingency research paradigm
The research paradigm on structural contingency theory was well established by around the
1970s. Adaptive functionalism, the contingency fit model and the comparative method form
the core of the structural contingency theory paradigm (Donaldson, 1996). The
organizational sociological branch of functionalism assumes that organizational structures
are shaped so as to provide for effective functioning of the organization (Pennings, 1992).
Contingency research often followed the method of a comparative study across different
organizations, measuring the contingency factors and the structural factors at one point in
time (Donaldson, 1996). Correlation or cross-tabulation studies were done on the pairs of
contingency and structural factors, testing the underlying fit between contingency and
structure. Also multivariate models have been investigated (Drazin & van de Ven, 1985).
The contingency view of an organization is based on a systems perspective, and can also be
described as follows (Kast & Rosenzweig, 1985): The contingency view of organizations
and their management suggests that an organization is a system composed of subsystems
and delineated by identifiable boundaries from its environmental suprasystem. The
contingency view seeks to understand the interrelationships within and among subsystems
as well as between the organization and its environment and to define patterns of
relationships or configurations of variables. It emphasizes the multivariate nature of
organizations and attempts to understand how organizations operate under varying
conditions and in specific circumstances. Contingency views are ultimately directed toward
29
suggesting organizational designs and managerial actions most appropriate for specific
situations (p. 17-18).
Any contingency theory contains two implicit assumptions (Fry & Smith, 1987; Kast &
Rosenzweig, 1985; Nightingale & Toulouse, 1977):
- The existence of a congruence between the organization and its environment and
among the various subsystems (test of congruence),
- The theoretical system has the potential for multiple states that are signaled by
changes in the values of the units composing the theoretical system (test of
contingency).
These two implicit assumptions are fulfilled in several studies on contingency theory
(Drazin & van de Ven, 1985; Fry & Slocum, 1984; Fry & Smith, 1987; Schoonhoven,
1981). All segregate the testing of congruence and contingency in their hypotheses.
2.6.3 Developments and criticisms to structural contingency
theory
Some researchers expressed a critical view on the structural contingency theory and
suggested further developments. An important criticism is the lack of clarity in contingency
theory (Schoonhoven, 1981). She described several interrelated problems with contingency
theory, with the main problem the lack of clarity in definitions. Also the tendency to rely on
simple, linear relationships within the contingency theory is criticized. The main criticism,
however, is on the concept of determinism.
This determinism, the structure being dependent on the contingency factor in contingency
theory, is criticized by many, such as (Child, 1972, 1975; Pennings, 1992; Perrow, 1986;
Pfeffer & Salancik, 1978). Pennings, for example, points out the presence of strategic
choice, supporting Child, who favors a proactive image of organizations instead of a
reactive and passive picture of organizations, depicted by the contingency theory (Child,
1972, 1975). Child admits the influence of contingencies, but emphasizes the concept of
strategic choice for managers, arising from several sources. According to certain actionlevel factors (perceptions, implicit theories, values, interest and power), managers vary in
their response to the contingency. And rather than responding to the environment,
organizations may also (attempt to) alter the environment thus avoiding the need to change
their structure (Perrow, 1986; Pfeffer & Salancik, 1978). Supporting Childs ideas,
contingency factors could be seen as influential but not decisive by taking a more
constructivism perspective rather than a positivism perspective. Moreover, Pennings
suggests an equifinality view, in which multiple combinations between organization
structure and environment can lead to organizational effectiveness (Pennings, 1987).
Applying this broader view on structural contingency theory (hence with a more influential
character, rather than decisive), we will apply a contingency approach to project
management.
2.6.4 Towards a contingency approach to project management
In the structural contingency approach, the organizational structure is made dependent on
the contingency factors, with a fit between organizational structure and contingency factor
leading to organization performance. Applying the contingency approach to project
management would mean that project management should be made dependent on the
contingency factors, with a fit or congruence between those factors leading to best project
performance. Following the equifinality view, multiple combinations of contingency factors
and structural variables would be possible, all leading to best project performance. Further,
30
31
Table 2.7: Overview of contingency factors found in literature, divided into 5 main categories and a sixth category others
32
33
Despite the prominent attention for uncertainty as a contingency factor in Table 2.7, this
dissertation focuses on project complexity as a contingency factor. In our view uncertainty
is an intrinsic part of project complexity. Increased uncertainties would contribute to the
project complexity and hence increase the chance of budget and schedule overruns (Birol,
2006; Neleman, 2006; Williams, 1999; Williams, 2002, 2005). To be able to consider
project complexity as a contingency factor, first we need to know what project complexity
actually comprises, according to modern literature.
1.
36
De Bruijn et al. also paid explicit attention to softer aspects related to project complexity
(de Bruijn et al., 1996). They assumed that project complexity would break down into
technical, social and organizational complexity. Here technical complexity was assumed to
be related to amongst others technological uncertainty, dynamics and the uniqueness of the
project. Organizational complexity was assumed to be related to amongst others the
organization structure, the project team, and the actors involved, and social complexity
referred to (again) actors involved, their interests and the risks and consequences of the
project in relation to its environment. Also other studies indicated the environment as an
important contributor to project complexity (Jaafari, 2003; Mason, 2007; Xia & Lee, 2005).
Also Antoniadis et al. favor an approach in which complexity is considered broader than
just technical complexity (Antoniadis, Edum-Fotwe, & Thorpe, 2011): they showed the
importance of recognizing socio-organizational complexity.
The Williams model, introduced above (Williams, 2002), primarily covers the technical
aspects and to a lesser extent the organizational aspects and aspects related to the
environment, although the number of stakeholders involved, their diversity and
interdependency could be considered as being part of structural complexity. Integrating
Williams model in a broader model taking into account these softer aspects is therefore
suggested. While social complexity seems to have overlaps with organizational complexity
and complexity of the environment, in the current research, project complexity is broken
down into at least technical complexity, organizational complexity and complexity of the
environment. With environment we refer to the direct environment of the project, physical
as well as relational (such as location and stakeholders).
2.7.3 Uncertainty, project risk and project complexity
As shown above, project complexity is often considered as being caused by uncertainties.
Perminova introduced a new perspective on uncertainties in projects and how to manage
uncertainties in projects (Perminova, Gustafsson, & Wikstrm, 2008). She explained the
link between uncertainties and risk management. Whereas traditional risk management
scholars assumed risk is uncertainty, Perminova rather understands risk as one of the
implications of uncertainty. She defined uncertainty as a context for risks as events having
a negative impact on the projects outcomes, or opportunities as events that have beneficial
impact on project performance (p. 76). Risk as an important contributor to project
complexity (Turner & Cochrane, 1993; Williams, 2002), seems more focused on the first
part of Perminovas uncertainty definition.
Hillson and Simon also addressed the positive and negative side of project risk in their
definition of risk (Hillson & Simon, 2007): any uncertainty that, if it occurs, would have a
positive or a negative effect on achievement of one or more objectives (p. 5). In most
definitions of project risk, quantification of risk has two components: a probability of
occurrence of the event and the impact of the event (Kerzner, 2003). Often risks are ranked
using a product of the probability and impact (Turner, 2008; Williams, 2002). However,
ranking of risks should also consider the separate values of impact and probability
(Williams, 2002) in order to make well founded decisions on which risks to take and which
risks to treat.
Particularly during the early stages of a project, high uncertainties have to be dealt with and
important decisions are to be made, supported by thorough risk management. During the
subsequent phases of the project in its life-cycle, the total project risk will normally
decrease because of the information that becomes available during the project (Kerzner,
37
2003). The nature of the risks however can change during the project life cycle. As a result
of actions to treat the risk in the project, new risks might arise (secondary risks) and some
risks might remain (residual risk), (Hillson & Simon, 2007).
A particular category of risks is formed by so-called Black Swan events (Taleb, 2007).
These events are characterized by low probability, extremely high impact and predictability
in hindsight. In view of Taleb, rather than to predict Black Swam Events, robustness should
be built against the negative ones and the positive ones should be exploited.
With increasingly complex projects, risk management becomes more important and risk
management should be done throughout the whole life-cycle of a project (Jaafari, 2001).
Complexity modeling as an aid for project and risk management is discussed by Vidal and
Marle, who consider complexity as a source of risks, either directly or indirectly induced by
the complexity in the project (Vidal & Marle, 2008). However, we argue that the number of
risks and/or their probability and impact can also be assumed to contribute to project
complexity. For example, in a project with a high number of risks, more dynamics and
more interactions might be expected, contributing to project complexity.
Carefully identifying the project risks should not be considered as a project goal as such,
but as a means to manage the project and its inherent uncertainties. After risk identification,
risk management could consist of risk assessment, risk response planning, risk reporting,
risk implementation and risk review activities (Hillson & Simon, 2007). Risk management
is important, since it was shown to be an important project success factor (Hillson &
Simon, 2007). When not treated carefully, project risk can be a factor that potentially
jeopardizes project success. This explains the relevance of risk management in current
project management.
In literature, complexity is also explicitly placed next to uncertainty (Halman, 1994; Pich et
al., 2002; Sommer & Loch, 2004). Sommer and Loch define these terms as follows:
Complexity has two dimensions: system size (the number of influence variables) and the
number of interactions among influence variables. Unforeseeable uncertainty refers to the
inability to recognize influence variables or interactions at the outset (the system state
space is not fully known) (p.1343). Following the Williams approach (Figure 2.2),
however, even these uncertainties could contribute to project complexity.
To conclude this section, we express and summarize our views on the concepts of
uncertainty, risk and complexity in the context of projects:
- Uncertainty is a fact of life in modern project management. Throughout the
project-life cycle, uncertainties are reduced, but some uncertainty will always be
present (and is not necessarily negative).
- Risk is the uncertainty that matters for the project delivery. A risk description
includes a cause for the risk, the event itself and the consequences, with certain
probability and impact.
- Complexity is caused by, amongst others but not limited to, uncertainties and
risks. In our view, complexity is a project characteristic: a project could be
characterized by its complexity footprint.
38
39
POWER
1
Dormant
Stakeholder
4
Dominant
Stakeholder
7
5
Dangerous Definitive
Stakeholder Stakeholder
LEGITIMACY
2
Discretionary
Stakeholder
6
Dependent
Stakeholder
3
Demanding
Stakeholder
8
Nonstakeholder
URGENCY
Figure 2.3: Stakeholder typology according to (Mitchell et al., 1997)
Although this typology might be helpful in identifying and classifying project stakeholders,
its orientation is mainly outside the project (external stakeholders). The role-based
stakeholder definition of Achterkamp and Vos provides a model that seem a useful startingpoint to distinguish stakeholders within a project (Achterkamp & Vos, 2008). Their
classification model is based on Ulrichs earlier work (Ulrich, 1987) and specifies four
roles that stakeholders could play: client, decision maker, designer (all actively involved)
and those stakeholders passively involved. Here the basic definition of stakeholders by
Freeman can be recognized (Freeman, 1984)a stakeholder in an organization is any
group or individual who can affect or is affected by the achievement of the organizations
objectives (p. 46). Stakeholders who can affect are represented in the active roles of
Achterkamp and Vos, and stakeholders who are affected are represented in their fourth,
passive role.
Specific roles within projects are more often distinguished in project management literature
(Callan, Sieimieniuch, & Sinclair, 2006; Turner, 2006; Turner & Keegan, 2001; Turner &
41
Mueller, 2003). Turner, for example, distinguished seven roles in projects: owner, users,
sponsor, resources, broker, steward, manager (Turner, 2006). Compared to Turners roles,
Achterkamps main extension seems that she explicitly mentions the passive stakeholders,
hence favoring a broader view on the project, but at the same time the role of the project
manager is not explicitly addressed. Apart from that, her roles do cover the more specific
roles that were defined by Turner.
Next to identification of stakeholders (roles) in project management, stakeholder
engagement is important. Hillson and Simon recommend to assess three dimensions for
each stakeholder: their attitude (supportive or resistant), their power, and their level of
interest (Hillson & Simon, 2007). Dependent on the three scores, it should be decided how
to involve/engage/manage them in the project.
In the current research, project related stakeholders play a role in two respects. First, all
stakeholders (and types), internal as well as external, can influence the complexity of the
project and hence should and will be included in the research on project complexity. Think
of the groups/roles as distinguished by Achterkamp and Vos or Turner, but also of
(sub)contractors, governmental parties, pressure groups, etc. Second, different stakeholders
involved in the project (e.g. involved persons with a specific role in the project: internal
stakeholders) may have a different perspective on the project and what happened in the
project. For the second, three of the above mentioned roles are considered relevant: the
project manager, the project owner (client / sponsor), and the team members (resources /
designers / broker / steward). These are the three roles that actively contribute to the project
and hence are expected to have a relevant view on a projects complexity and how to adapt
the FED phase to the particular complexities.
subsequent research by Dvir et al., but this research was limited to defense development
projects, with data from the considerable amount of 110 projects (Dvir, Lipovetsky,
Shenhar, & Tishler, 1998). In 2003, Dvir et al. again used this data to investigate the
relationship between project planning efforts and project success (Dvir et al., 2003). They
concluded that there is a positive correlation between project success and efforts in the
planning phase, again based on the 110 defense projects. They suggested that conclusions
could be generalized to other industries, without giving firm arguments. In 2006, Dvir et al.
studied the relationship between project managers personality, project types and project
success (Dvir et al., 2006). To classify project types, they attempted to use the NCTP
framework (novelty, complexity, technology, pace), based on their previously developed
UCP framework (uncertainty, complexity, pace). However, due to small variability of
projects, they distinguished only 3 main categories of projects, rather than really using the
NCTP framework they were proposing. Dvir et al. concluded that for the three types of
projects, different patterns of correlations were found between certain aspects of the
managers personalities and certain dimensions of project success. Note that the NCTP
framework, similar to the UCP framework it is based on, is heavily focused on technical
complexity, limited to three levels of complexity: assembly, system and array.
Subsequently, Shenhar and Dvir published the Diamond Approach, which basically
describes how to adapt project management to projects with a specific NCTP character
(Shenhar & Dvir, 2007b).
In the field of product development, Tatikonda and Rosenthal investigated the relation
between project characteristics (like technology novelty and project complexity) and
project execution outcomes, however without linking towards project management
techniques (Tatikonda & Rosenthal, 2000). They concluded that projects with high levels of
technology novelty or project complexity are associated with specific project execution
outcomes, such as poor unit-cost outcomes. Technology novelty is also associated with
poor time-to-market costs. Lewis et al. explored contrasting styles of project management
in product development (planned and emergent styles, see also Section 2.6.4) using data
from 80 R&D product development projects from a US firm in the chemical industry
(Lewis et al., 2002). They found that successful projects were managed with concurrent use
of emergent and planned styles. The question stemming from this is whether adaptation of
different management styles would also be effective for the management of large, complex
engineering projects.
The recent study of Williams seems to confirm that emerging styles rather than planning
styles would be effective also outside the product development industry (Williams, 2005).
Based on IT and construction industry practice, he argues that the projects emerge rather
than can be entirely preplanned (because of a lack of information available), using a
cooperative management style including influences of the external environment such as the
stakeholders. Williams work aims at enabling project managers to choose effective ways to
manage projects based on understanding and model-based theory. Suggested future steps
include the definition of a categorization of projects based on three dimensions: structural
complexity, uncertainty and time-limitations. Further, it should be investigated how to mix
different management styles (for example preplanned vs. emergent) and how to define the
best mix, dependent on project classification metrics.
Project management effectiveness in different organizational conditions was studied by
Hyvri using both case studies and surveys (Hyvri, 2007). The case studies were
performed on two partnership investment projects from AGA, an important producer of
43
industry and medical gases in Finland. Based on only two cases, it was concluded that for
effective project management, more attention should be given to resource planning, the
earned value method, communication networks and the making of contracts. The
subsequent survey study aimed at investigating the effectiveness of project management (in
terms of organizational structures, technical competency, leadership ability and the
characteristics of an effective project manager) and evaluating critical success/failure
factors in project management. The survey study concerned 25 responses, out of the 78
company members and 368 personal members from the Project Management Association
Finland that were asked to participate in the study. Further details on the limited number of
responses are not provided and therefore the results have only limited value. Results did
confirm outcomes of previous research that planning/organizing, networking and informing
are the most significant managerial practices in the leadership behavior of the project
manager.
Relevant studies were also found originating from the construction industry. As already
mentioned in Section 2.7.4, Gidado attempted to measure the complexity of the production
process in construction (Gidado, 1996) and is even developing a tool (CAPCoPS) to
assess the complexity of construction projects and its influence on production time and cost
(Cho & Gibson Jr, 2001). His approach, however, solely focuses on the effects of
complexity on time and cost planning, and dominantly includes aspects of technical
complexity.
Menches et al. attempted to quantify the relationship between project characteristics, preconstruction planning and performance in the electrical construction industry (Menches,
Hanna, Nordheim, & Russell, 2008). The study quantified the impact of inherent project
characteristics and pre-construction planning on the probability of successful project
performance. Using two-stage random sampling, a sample of 40 members of the National
Electrical Contractors Association (NECA) was contacted of which 27 contractors provided
data on 55 projects. All participants completed a questionnaire and subsequently were
interviewed (4 hours for each project). A 7-variable model, using 2 project characteristics
and 5 planning components as variables, was developed to predict the probability of a
successful outcome. Initially, five classes of project characteristics were developed using
principle component analysis: project size, initial uncertainty of the project, bid accuracy,
existing relationships and type of construction and award. Initial uncertainty of the project
was based on the perceived level of complexity (low/med/high), the % design that was
completed at bid time and the estimated profitability. Bid accuracy was estimated based on
three questions: accuracy of cost estimate, accuracy of work hours estimate, perceived level
of complexity (low/med/high). From the five classes of project characteristics, only two
were included in the final model: uncertainty of the project and bid accuracy. Initially, the
project planning phase was characterized by 73 activities divided over three project stages
(bid preparation, pre-construction and jobsite management planning), in 21 categories of
activities. Only 5 planning components were included in the final model with 24 underlying
variables. To validate the predictive model developed, data from 12 additional projects
were used. The outcome of these projects (6 successful, 6 less successful) could be
correctly predicted for 11 of the 12 projects. It was concluded that the model could predict
the probability of project success based on two project characteristics (with 4 underlying
variables) and 5 planning characteristics (with 24 underlying variables). The absence of the
24 planning activities in a project would significantly decrease the chance of project
success. A follow up on the study was suggested in developing a tool to support contractors
in adjusting their planning activities to certain project characteristics.
44
It is noted that the approach of Menches et al. has a very systemic and positivist character,
assuming that variables can realistically be quantified, that the processes can be modeled in
subsequent steps and that several causal relationships exist. They predominantly focused on
the perspectives of the contractors involved in the electrical construction industry. A main
comment on their model is that the number of projects is fairly limited to develop a
predictive model as they claim, with 4 underlying project characteristic variables and 24
underlying planning variables, based on a sample of 55 projects and a validation sample of
12 projects. Limitations of their research are not clearly indicated in their paper and their
suggested subsequent work only focused on tool development, indicating the model is
sufficiently validated for use by contractors in the electrical construction sector.
Generalization outside the sector at this stage seems unlikely, because of the sector specific
activities amongst those relevant 24 activities. Still, it shows a rare example of quantitative
research in the field of project management.
As opposed to the positivist character of the previous study, a more constructivist approach
was reflected in recent work of Sauser et al., studying the concept of fit between project
characteristics and project management (Sauser et al., 2009). Taking the example of the
Mars Climate Orbiter loss, their paper shows how contingency theory provided new
insights in why the project had failed: the management style did not fit the particular
project. It also shows the importance of applying the right management styles in the
particular context.
This section presented research on adapting project management to certain project
characteristics (complexity) and the link with project performance. Next to the interesting
approach of Menches et al.(with its limitations as described), the impressive works of
Shenhar and Dvir seem to have the closest fit with our research objective. However, their
operationalization of project complexity is limited to three levels of complexity (assembly,
system, array), which in our view is too narrow and too dominantly technically oriented.
Also, in our research we focus on a different sector, the process industry.
The certain project characteristic to be used as contingency factor could be the projects
complexity, because of the increasing complexity in projects and its assumed contribution
to project failure (Neleman, 2006; Williams, 2002, 2005). Regarding project complexity,
current literature seems to particularly focus on aspects of technical complexity, although
the importance of the softer aspects of complexity is recognized. Current classification
methods for projects based on their complexity seem to lack inclusion of other dimensions
than the technical one. And even if other categories are distinguished (most often
organizational); the complexity of a project is summarized in one single complexity score,
which is overly simplifying the concept of project complexity in our view. Based on what
we saw in literature (de Bruijn et al., 1996; Jaafari, 2003), we propose to distinguish
technical complexity, organizational complexity and environmental complexity in our
research. Further, project complexity is assumed to have a dynamic character: the project
complexity will change over the life-cycle of the project. A model to characterize project
complexity should therefore acknowledge its dynamic character. In contrast to considering
complexity next to uncertainty as project characteristic (Halman, 1994; Pich et al., 2002;
Sommer & Loch, 2004), we consider uncertainty as one of the sources of project
complexity (Williams, 2002).
In the current research, we are looking at adapting the front-end phase to the particular type
of (expected) project complexity. In the front-end phase, however, there are several
standard activities that have to be always done (albeit only to some extent), regardless of
the typical character of the particular project. On top of these standard front-end activities,
value improving practices (VIPs) are thought to add value to the project. However, these
VIPs have practical evidence (IPA database), rather than scientific evidence at this stage.
Subsequent case studies (Chapter 3) explore which of the front-end activities and VIPs are
indeed perceived to add value to the project and how project complexity is currently
managed in the front-end phase.
Regarding project success, we rather talk about project performance. In literature,
agreement was found that within a project, the parties involved should agree on the success
criteria or measures for the specific project (Bakker et al., 2010). Some mainstream project
performance measures were discussed (delivering scope with sufficient quality and meeting
cost and schedule estimates), but it can be questioned what these measures really tell, as
long as they are based on cost and schedule estimates that might be influenced by strategic
behavior of the actors involved. Also less mainstream performance measures were
discussed, but their subjective character troubles effective usage. Since the old iron
triangle performance measures are relatively easy and objectively measurable and still
commonly accepted, they were selected for usage in this study: cost performance, schedule
performance and scope/quality performance.
Stakeholder theory was used to define which stakeholder perspectives to include in the
research. (Achterkamp & Vos, 2008; Turner, 2006). Since perspectives are known to be of
influence when performing social research, three relevant roles were selected, all from an
owner perspective: the project manager, the owner representative and the project team
member.
Now the starting points of the research are more closely defined, the empirical part can
start, taking into account a constructivist approach to study project management.
46
Chapter 3
Exploratory case studies
Part of this chapter was presented at the IXth IRNOP conference in Berlin (Bosch-Rekveldt,
Mooi, Verbraeck, & Bakker, 2009a).
From the literature study in Chapter 2, amongst others it was concluded that there is no
commonly agreed definition of project complexity (Geraldi, 2008c). What exactly makes a
project complex and how professionals perceive the complexity of their project is unknown
at this stage, let alone how they deal with it in the early project phase (which is the crucial
project phase, as shown in Section 2.5).
Empirical research was therefore undertaken to investigate the concept of project
complexity. In this explorative research, the perspectives of several project professionals on
their projects complexity and how complexity was dealt with in the early project phases
was studied. Exploratory case studies were performed to answer the following research
questions (sub-questions 1 and 4 as defined in Chapter 1):
1. What is project complexity as experienced by project professionals?
4. What are the relevant front-end activities to deal with project complexity?
To answer this research question several sub-questions were defined:
a) Do project professionals consider their project as complex, and in which way?
b) How do perspectives about project complexity differ within a project?
c) How to classify projects based on their technical, organizational and
environmental complexity?
d) How is project complexity currently dealt with, in the front-end project phase?
This chapter presents the findings of this explorative, empirical research. Section 3.1 details
the methods used: the case study protocol, the case selection, the persons interviewed and
the data analysis. Next the six cases are presented in Section 3.2 to Section 3.7, detailing
per case the perspectives on project complexity and the perspectives on the front-end
activities. A cross case analysis is presented in Section 3.8, entailing an analysis of the
perspectives on project complexity and the results of the front-end development phase
across the cases. Finally, the discussion, including a confrontation of the results with
literature findings, is presented in Section 3.9.
3.1 Methods
To gather empirical data for this explorative research, a case study approach was followed.
A case study approach was chosen because we are studying a contemporary real-life
situation on which the researcher does not have a strong influence (Yin, 2003). Moreover, a
47
case study approach is very suitable to answer a descriptive research question, like the
what question we aim to answer in this chapter (Blaikie, 2009).
3.1.1 Case study design
The chosen unit of analysis was a completed project in the process engineering industry. To
be more specific: projects with the aim to develop and/or construct and/or modify a certain
asset or facility. The project was taken in its wide definition: it covers all activities from
initiation to close-out (including the feasibility (or scouting) phase, front-end development,
implementation and close-out / handover, but excluding operations and maintenance of the
facility built).
A multiple-cases embedded design was followed (Yin, 2002). The embedded design refers
to the different sub-units of analysis to be analyzed within one case: project complexity,
front-end activities and project performance. The multiplicity refers to the inclusion of a
number of cases (six) opposed to inclusion of one single case. In our research, one case
consisted of three interviews with three different persons about one project, combined with
the study of written project documentation (such as official reports and project archives).
The inclusion of multiple cases in an embedded design was applied to get a broad view on
project complexity and how project complexity was dealt with in the front-end phase.
The six projects were selected from within one major company in the Dutch process
industry, active member of the NAP network. This company was selected because of its
size, which enabled inclusion of very different types of projects from within one company
(see also Section 3.1.3), the well-developed project management procedures and the
positive attitude towards further professionalization of project management. The choice to
perform the case study within one company, with a well-developed project management
process, limits variation across the cases in the standard front-end activities to be applied.
Thereby the main phenomenon under study (project complexity and how it was dealt with)
can be better explored.
Semi-structured interviews were held with the project managers of these six projects, a
project team member (lead process engineer, lead project engineer, control manager, or
engineering manager) and an owner representative (future site/plant owner, asset
development manager (ADM), managing director) to investigate what elements in a project
contributed to the projects complexity and how project complexity was dealt with. For one
of the cases (case 6), no owner representative was involved in the interviews. Instead, for
case 6 two project managers were included since the first was replaced during the project.
In total, eighteen interviews were held. The interviews lasted between 60 and 90 minutes.
3.1.2 Case study protocol
To increase validity of the study, a case study protocol was followed. This protocol
described which steps to take. In order to avoid biased participants, all had the same brief
information about the objectives of the interview. The foreseen participants were asked to
participate in the interview with a short letter of information. All project professionals
approached were willing to participate in the research. Before performing the interviews,
project documentation such as progress reports and close out reports were studied. This
way, the interviewer became already a little bit familiar with the project and terminology
prior to the interview. The written information was also used to verify and complement the
interview results.
48
All interviews were taped with permission of the interviewees. The interviews were
following the same list of base questions, but there was room to further deepen the answers
of the participants. The interviews included questions related to project performance,
activities during front-end development and project complexity. The transcripts from the
interviews, made by the interviewer, were approved by the interviewee before starting
further analysis.
The first six interviews were performed together with an interviewer assistant. The assistant
carefully checked that the questions to the interviewees would not become suggestive
questions, by any means. The assistant also kept an eye on the time schedule and in the
subsequent analysis of the interviews, he checked the analysis done by the interviewer and
partly performed analyses in parallel. The outcomes of these parallel analyses were
thoroughly discussed and integrated in the case analysis. After six interviews, this double
presence during the interviews was stopped but still the analyses were thoroughly discussed
with at least one other researcher involved, which was possible because of the stored
interviews.
In total 64 interview questions were predefined, divided over 5 categories (general, project
result, project complexity, front-end activities and closure). In the category general,
information on the background of the interviewees and the project was gathered. In the
category project result, questions were asked on the project performance. In the category
project complexity, interviewees could express their ideas on project complexity and
whether or not they considered their project as complex (and in what way). Only after
obtaining their initial ideas on project complexity, in subsequent questions several potential
areas of project complexity were introduced (commercial, economical, organizational,
political, technical, and health, safety and environment) and it was asked whether any
elements in the project had contributed to project complexity in that area. These potential
areas of project complexity (only serving as wide categories) were following the incompany risk identification model because this framework allowed a broad approach to the
concept of complexity and, even more important, the interviewees were already familiar
with the framework (this was tested during the interviews). The risk identification model
distinguished the following dimensions: technical, economical, commercial, organizational,
political, safety & security & health & environment.
Also, the interviewees were asked to assess the projects complexity on a 1 to 5 scale (1 =
least complex, 5 = most complex) in the three main areas (technical, organizational,
environmental), hence in the proposed framework structure. Finally, in this category it was
asked whether (and how) the complexity of the project changed over its lifecycle. In the
category front-end development, questions were asked on how the interviewees dealt
with project complexity in the front-end phase, what they perceived as the value of frontend development and how fit for purpose scaling was practiced in their projects. In the
final category closure, the participation of the interviewee in the review process was
asked for and also any other business could be discussed, if the interviewees or the
interviewer felt this was appropriate. From the 64 pre-defined questions, 25 questions were
considered more important than the others (the so-called need to haves versus the nice to
haves, including background information questions about the respondents) and these 25
questions got preferred attention during the interviews and the analysis as described in
Section 3.2 to Section 3.8. All interview questions are listed in Appendix A.
49
the interviews with information regarding the background of the participants and
information regarding the project.
Per case, a general picture of the project was sketched based on the written information and
an overview of the interview results. After the writing of these narratives (about four A4s
per interview), the actual analysis took place by comparing mentioned complexity
elements, whether they changed over time and how the front-end phase was perceived. The
answers on the interview questions were analyzed by a qualitative comparison, and
differences and similarities were explained. Interviewees were not aware of the answers of
their colleagues. After the in-depth single case analysis, a cross case analysis was
performed focusing on an overall comparison of the results and exploring trends across the
single case results.
The analysis of the cases in this chapter is presented as follows. In the subsequent 6
sections, each of the cases is described. First the selected cases are briefly introduced. All
case descriptions include the projects objective, the location, whether (un-)proven
technology was included, its ownership and business, the project team, contractor(s), the
capital expenditure, its main driver (cost versus schedule driven) and its performance. This
project description was made as objective as possible, primarily based on archived project
documentation. Also the assessment of the projects performance was based on the archived
project documentation, taking the simple success definition (Section 2.10) where project
performance is measured based on timely delivering with acceptable quality within the
agreed budget. Subsequently, per case it was analyzed whether or not the interviewed
project members did consider the project complex, as well as their different perspectives (if
any) on the projects complexity. Also the dynamics of project complexity and the elements
contributing most to project complexity were discussed. Next, it was discussed how the
front-end phase was adapted to the particular complexities and how fit for purpose
scaling was practiced, if at all. Also the interviewees perception on the value of the frontend phase in their projects was discussed.
After the single case analysis, the cross case analysis is presented in Section 3.8. Cross case
analysis, a comparison of the case results across the different cases, was done to deepen the
understanding of the results (Miles & Huberman, 1994). Their variable-oriented strategy
was followed, looking for themes that cut across cases, p.175. The cross case analysis
aims to answer the research questions of this chapter.
An overview of who was interviewed (consisting of the role in the project and work
experience) and in which project phases they were involved in the project is given in Table
3.1. Two of the eighteen interviewees were female. The involved interviewees did have
considerable work experience (> 25 years on average).
51
Project
Work
experience
in 2008
(years)
Involved in
earliest phase
of project
Involved
in front
end phase
project
Involved in
project
execution
1
1
1
2
2
2
3
3
3
4
4
4
5
5
5
6
6
6
Project manager
Project controls manager
Future site owner
Project manager
Engineering manager
Project owner
Project manager
Process design / ADM
Future plant owner
Project manager
Lead process engineer
Asset development manager
Project manager
Lead engineer
Managing director
Project manager
Project manager front-end
Control manager
35
35
29
30
12
15
31
31
31
45
18
19
11
23
24
28
>30
17
No
Yes
No
No
No
No
No
Yes
Yes
No
No
No
No
No
Yes
No
Yes
Yes
Yes
Yes
Yes
No
Partial
Yes
Yes
Yes
Yes
No
Yes
Yes
Yes
No
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes*
No
Yes
Yes
Yes
Yes
Yes
No
Yes
* Project manager was only involved in the late project execution phase
52
Project
Perspective
Project
complex?
Technical
Organizational
Environment
Scores (1-5)*
1
1
1
Project manager
Project controls manager
Future site owner
Yes
Yes
Yes
1
2
3.5
2
2
4
2
2
2
Complexity changed
during lifetime?
Overall
direction of
complexity
change?
Yes
Yes
Yes
Decrease
Decrease
Decrease
In view of the project manager, project 1 was complex in terms of size: the number of
people involved in the project but also the physical size of the construction site. He
however indicated that it was still manageable and as such, he didnt experience the project
as being complex while executing. Further, he stressed the importance of the people in the
project. He considered the organizational aspects in the project most complex. Because it
was a joint venture project, there were two home offices and the project manager had to
communicate with the two company boards.
In view of the project controls manager, project 1 was complex in terms of being organized
in a joint venture which required approval of the other joint venture partner on allocation
models, agreed budgets, etc. The construction of the facility as such he did not consider
complex since it was just a copy of an existing facility. The aspect contributing most to the
project complexity was the fact that the project was done with a partner in a joint venture
structure.
In view of the future site owner, project 1 was complex in terms of having a joint venture
partner, resulting in extra interfaces. Also at the contractor side, a joint venture structure
was in place with split responsibilities, introducing additional interfaces. Further, complex
arrangements had to be made with feedstock suppliers, resulting in extra logistic interfaces
and dependencies. The aspect contributing most to the projects complexity was related to
the many parties involved at both owner and contractors side.
All three interviewees indicated that the organizational aspects contributed most to project
complexity, particularly the fact that the project was run by a joint venture. Based on their
scores, they did not really consider the project complex, with the majority of their scores
being 2 (see Table 3.2). Note that all three were very experienced employees and that they
were involved in both front-end development and project execution.
How about the dynamics of project complexity? Again agreement was found amongst the
three interviewees. According to the project manager, the organizational complexity
decreased as soon as the JV partner accepted the project managers way of organizing. The
project controls manager indicated that when the JV was established and all agreements
were set, complexity was decreased, despite the finances becoming more complex after
finishing the contract. The future site owner suggested that complexity in the project was
reduced after the final investment decision, once the major decisions were taken by the joint
venture. Further he did not see major changes in the complexity during the project, in his
53
view this was mainly because of the continuity in the project in terms of people involved
and organization structures in place.
3.2.3 Interview results on front-end activities
A summary of the interview findings on front-end activities is given in Table 3.3.
Project
1
1
1
Perspective
Value of FED?
Opinion on
Fit for purpose scaling?
Rules and procedures are a
must, but not too much,
PM needs flexibility
Follow all procedures,
no bypassing
PM should get real
responsibility
All interviewees stressed the importance of having an integrated project team (of owners
and contractors), already in the FED phase. At the time of the project, this was considered
rather unconventional by the two owner organisations, as they were afraid for conflicts of
interests. This early team integration was considered very helpful and even essential by the
(experienced) project manager. In his view, organizational complexity was treated by early
teambuilding, thereby gaining trust and respect by and between all parties involved in the
situation. In view of the project controls manager, FED was adapted to the expected
organizational complexity by involving the JV partner in an early phase, next to early
involvement of the contractor. Estimates were made together, hence building trust between
the parties.
In view of the project controls manager, the value of FED for the project is that after FED it
is clear what and when you will deliver, and what it is expected to cost. As long as frontend is thoroughly performed, no problems with project execution are likely to occur, in his
view. In view of the project manager no scope changes should be necessary after FID in
case FED is done thoroughly, although exceptions are always possible.
The project manager very much favoured flexibility and own responsibility of the project
manager in following the (necessary) rules and procedures. Rules are necessary as a base,
but not as a law to comply with. In view of the project controls manager, however, not
following or skipping certain procedures, like bypassing part of the FED phase, will
certainly cause problems in projects. He favoured just following all procedures, and
personally he additionally used a checklist, based on previous experiences. In view of the
future site manager, if people feel constrained by the procedures they have to follow, there
is a higher chance they hide behind the restrictions and rules and do not reach an optimum
result. In this case 1, there was the possibility to integrally look at the problems and proactively treat them, because the project manager took and got responsibility. There was
freedom for the project manager, which contributed to the good performance of the project,
in view of the future site manager. All interviewees stressed the good co-operation with
subcontractors and with the steering committee.
54
most contributing element to the complexity of the project would be some political aspects
together with the local stakeholders that he found were difficult to influence.
Table 3.4: Summary interview results on project complexity, project 2
Perspective
Project
complex?
Technical
Organizational
2
2
2
Project manager
Engineering manager
Project owner
Yes
No
No/yes
2.5
2
3
4
3
4
Environment
Project
Scores (1-5)*
Complexity
changed
during
lifetime?
Overall
direction of
complexity
change?
2.5
4
5
Little
Yes
Yes
Decrease
Increase
Decrease
In view of the project owner project 2 was not complex in comparison with other projects.
He would not consider project 2 complex because the players in the project were known
and there were no interlinked investment decisions to be made, which he would consider
really complex. The timing and joining of all project parts together just before the final
investment decision, he found the most difficult.
Comparing the answers of the three interviewees (see also Table 3.4), a major difference in
perspective was observed between the project manager, most experienced of the three
interviewees for this project who found the different stakeholders with non-aligned
objectives the most complex, and the project owner, who just not considered the project as
being complex, but nevertheless scores the project relatively high on its complexity. The
opinion of the engineering manager is somewhere in between; he agreed with the project
owner that the project as such was not complex, but the aspect that contributed most to the
(limited) complexity was similar to the project manager, in the area of stakeholder relations.
How about the dynamics of project complexity? Again the interviewees disagreed.
According to the project manager, the complexity of the project did not change over its
lifecycle; except for the complexity related to the deal making that was solved after the
final investment decision. In view of the engineering manager, project complexity increased
during the implementation phase because elements were added to the project that were not
foreseen beforehand. Hence project complexity increased because of poor definition in the
early project phases, in his view. In view of the project owner, project complexity gradually
decreased during the different phases of the project; starting high but with a slight increase
towards the end of all project phases.
3.3.3 Interview results on front-end activities
A summary of the interview findings on front-end activities is given in Table 3.5. In view
of the interviewees, the value of FED is to be found in reducing execution risks and
preventing further complexities during project execution. In project 2, FED could have
been improved by more thorough investigation of the soil data, in view of the project
manager. Instead, the main focus was on signing the contract, in order to be able to deliver
in time. According to the project manager, always a compromise has to be found between
the amount of money to spend before the final investment decision is taken and the amount
of money not to spend in the development of the project but to reserve to solve issues (if
56
any) during project execution: you never know it all beforehand. Without proper front-end
development, project execution cannot be successful in view of the project manager. In
view of the engineering manager, the team preparing the project on-site was more business
oriented than project management oriented; only when the project was approved, project
management really started. In his view the project team consisted of a good mix of people
in age, experience, background, discipline and company. He also stressed the importance of
continuity within the team across the different project phases.
Project
Project manager
Engineering
manager
Project owner
Value of FED?
Opinion on
Fit for purpose scaling?
At the time of FED for project 2, there were no formalised procedures on what processes to
apply in a project; no formal fit for purpose scaling was known in view of the project
manager. The project manager indicated that freedom on which procedures to follow would
work well for experienced project managers, but not for the inexperienced. A certain
structure, in his view, would be needed to make people do certain things at the right
moment, and guidelines could work really well.
This project passed FID on the basis of a basic design package (BDP), which resulted in a
considerable number of change orders (COs) according to the project manager. Because of
the FID decision based on BDP, some sort of fit for purpose scaling was applied in view
of the project owner: normally requirements should be clearer at the moment of FID. The
engineering manager also stressed that some of the unforeseen scope elements could have
been tackled in FED, if all requirements were clear at that time. Hence more effort could
(should?) have been spent in the FED phase.
In view of the project owner, the front-end of the project was adapted to the complexity by
making changes in the objectives of the project, to prevent later scope changes as much as
possible. According to the project owner, the general challenge in projects is to adapt the,
always necessary, assumptions in time to the reality which could have been done better in
project 2.
The project owner suggested two changes to improve the front-end process, based on his
experiences in project 2. First, before taking the FID decision, he would like to sit together
with the technical team responsible for FED and he would like to make sure the commercial
people also sit together with the technical team, to prevent that the commercial people
making agreements with the client of which the technical team is not timely aware. Second,
he sketched the difficulty of mobilising the owners organization project team at the
moment the FID was taken. The project had to be won in an international tender, and most
people in his company were convinced that the tender would not be won. So when the
57
tender was won, unexpectedly, there was not enough time and attention to form the project
team. A smooth transfer from the project development organisation to the project execution
organisation should have had more attention.
Finally, the project owner reflected on the existence of different perspectives on project 2,
amongst the different people involved. In his view, he was more externally oriented while
the project manager was more internally oriented. This difference in perspectives actually
indicates the importance of including multiple persons per case in the current research.
3.3.4 Overall case conclusion
Based on the project characteristics this project could have been perceived as considerably
complex: working in a joint venture, new business, neither experience in the country nor
with the contractor involved. The interviewees, however, showed considerable differences
in their opinion on the projects complexity, ranging from not complex at all to
considerably complex. Also their ideas on the direction of changes in project complexity
across the different project phases differed considerably. Their different perceptions might
be related to years of experience, role in the project or involvement in the different project
phases. Not all of the interviewees were involved throughout the entire project (project
initiation, FED and project execution), but still the importance of continuity within the team
across the different project phases was emphasised in the interviews. This might be related
to the extremely late mobilisation of the owners organization project team (apart from a
few project developers) and the absence of such continuity in project 2, resulting in a slow
start after FID. Maybe also the perceived complexity of the stakeholders relations can be
explained by the absence of continuity in the project team: discontinuity in the team
negatively affects longer term relationships. Although this project was performed as a JV,
this was not mentioned as an element contributing to the complexity of the project by any
of the three interviewees: potentially because the JV partners had a similar background in
oil and gas.
Despite some flaws in the FED phase and a considerable number of change orders, a good
overall project performance was achieved. Partly this can be related to the contract type.
Although the choice for a lump sum contract in this project seems remarkable (there was no
detailed project definition available when signing the contracts) this might have positively
contributed to the project performance: the contractors had to bear part of the problems
encountered. At the time of contracting (~2002), lump sum contracts were the normal way
of contracting. Analysing the interviews on project 2, it is concluded that more effort during
FED could have either improved project performance or reduced the effort required to
achieve the current performance. The late project team involvement, as was the case in this
project, is not the normal way of working for this type of projects and earlier team
involvement is strongly recommended.
the owner organization. The project team only consisted of the project manager (owner
organization), a project engineer (subsidiary company) and a process engineer (subsidiary
company). The contractor worked under a reimbursable EPCM contract with incentive
scheme. The planned capital expenditure was about 34M$ and the project was cost driven.
The project was considered as existing business for the company. Based on project
documentation, it was concluded that the project performance was just acceptable: very
good quality and HSE performance was achieved against poor budget and schedule
performance.
3.4.2 Interview results on project complexity
A summary of the interview findings is given in Table 3.6. In view of the project manager,
project 3 was complex in terms of bringing the different parties involved together, not in
terms of technology. He considered the organizational part complex: he had experienced
major differences in the ways of working, particularly within the owners organization. The
final objectives of the project were aligned, in his view, but the way to achieve those
objectives was not. Further a mismatch in personal characters contributed to project
complexity. The aspect that contributed most to the project complexity, according to the
PM, was related to these organizational aspects.
Table 3.6: Summary interview results on project complexity, project 3
Scores (1-5)*
Project
Perspective
Technical
Organizational
Environment
Complexity
changed
during
lifetime?
Project
complex?
Project manager
Yes
Yes
3
3
No
No
2
2
4
5
2
1
Yes
Yes
Overall
direction of
complexity
change?
Decrease /
increase
Increase
Decrease
For the process designer (and in later stages, the project asset development manager
(ADM)), project 3 would not be complex, assessed against his background and experience
in the field. Still, aspects contributing most to this projects complexity would be
organizational aspects such as poor co-operation and communication as well within the
company as with the engineering contractor.
In view of the future plant owner, project 3 was not complex because of the many years of
experience the subsidiary company had in the business. He however could imagine the
project could be considered complex by somebody without experience, particularly because
of its non-standard character. In view of the future plant owner: it is all in the eyes of the
beholder and compared to a billion dollar project, project 3 was peanuts. The aspect that
still contributed most to the project complexity, according to the future plant owner, was
related to organizational aspects; particularly the link between the owner organization, the
subsidiary company and the engineering contractor. In his view, the complexity of the
interfaces between these parties was underestimated. Further, he mentioned the complexity
of dealing with the non-standard technical process; new for the owner organization as well
as for the engineering contractor.
59
The three interviewed project members fully agreed about the organizational aspects that
contributed most to project complexity, although not all of them would consider project 3
complex (see Table 3.6). The aspects that all three indicated are related to management of
interfaces within the project (communication and co-operation). Note that all three
interviewees were very experienced and involved in both front-end development and
project execution.
How about the dynamics of project complexity? The opinions were not unanimous.
According to the project manager, technical complexity decreased because of certain
equipment choices and organizational complexity increased because of the contractor
choice. In view of the process designer project complexity increased during project
execution; problems were raised, the co-operation worsened and worsened, hence
increasing complexity. Note the induced character of the complexity as sketched by the
process designer. The future plant owner indicated the opposite: parties involved were
getting more used to each other in the course of the project, hence reducing complexity.
3.4.3 Interview results on front-end activities
A summary of the interview findings is given in Table 3.7. In project 3, a clear difference
was observed between the opinion of the project manager and the others interviewed. The
project manager was an employee of the owner organization; the others were from the
subsidiary company. In view of the project manager, the scope was insufficiently defined at
FID, because of a different way of working of the subsidiary company compared to the
owner organization. In the subsidiary company, plans were made but if during construction
problems arose, scope would immediately be changed, with the risk of never finishing the
project, according to the project manager. He however stressed the owners organization
viewpoint of limiting scope changes after FID, i.e. construction should be done from
drawings and finalised according to the drawings. After delivery, changes can be made if
required. Therefore the project manager stressed the importance of the FED phase as a
thorough preparation and also the importance of correctly assessing the capabilities of the
foreseen parties.
Project
Value of FED?
Project manager
Process design /
ADM
Opinion on
Fit for purpose scaling?
Applied in the project, from technical
perspective; does the technology
allow for skipping certain
procedures.
Owners Organization management
methodology was strictly applied,
overvaluing planning, not really fit
for purpose scaling.
Not really applied, but highly
required in view of FPO.
In view of the process designer, organizational complexity in project execution could not
have been prevented by front-end activities, simply because the complexity was not
foreseen and moreover because the complexity was created by the people involved during
project execution. He did not see value of FED for solving this. The value of front-end
development, in view of the future project owner, was in making a clear role distribution. In
60
project 3, this was not successful, but in a comparable subsequent project the lessons
learned were successfully applied.
The interviewees had a different opinion on the use of fit for purpose scaling in project 3.
In view of the project manager, it was applied but mainly in terms of a technical
perspective: does the technology allow for skipping or following a certain procedure?
However, in his view more attention should be paid to organizational aspects: does the
organization (e.g. stakeholders, parties involved) allow for skipping or following certain
procedures? In view of the process designer (from the subsidiary company), they did apply
the owners organization management methodology, without having the possibility to adapt
it to their particular project. One consequence of following the owners organization
management methodology was the requirement to obtain three offers for most equipment in
the different stages of FED. However, because of the uniqueness of the equipment, this was
already hard and the suppliers just gave some price indications and only started the real
design work when they received the final order, in view of the process designer. Also he
mentioned the primary focus on planning, which in his view was not suited for this
particular project. So the process designer rather would have had more freedom to operate.
Also in view of the future plant owner, there was no real fit for purpose scaling applied in
the FED process. He however really would like to have a fit for purpose scaled front-end,
with the contrasts between the very large and very small projects and standard as well as
non-standard.
3.4.4 Overall case conclusion
Looking generally at the project characteristics, this project would not be considered very
complex. There was only one company involved (the owners organization, albeit with a
subsidiary company), the plant was a copy of an existing plant (although non-standard for
the project owner) and the CAPEX was rather small. This opinion was shared by two of the
three interviewees. However, the complexity of managing the interfaces within the
company was underestimated, which became a major source of organizational complexity.
Partly, the character of the organizational complexity was different than shown in the
previous cases: in this project 3, complexity was also induced by the poor co-operation
between the people involved. From this case, the influence of the relations in the project
team on project complexity became clear: obviously there was some tension between the
owners organization and the subsidiary company, with the owners organization providing
the project manager. This tension might have influenced the perception of the interviewees
on how the projects complexity developed across the different project phases.
This project was considered to be non-standard for the owner organization. Therefore,
this project probably could have benefited from a real fit for purpose scaling approach: a
management approach that would be better fitted to this specific project. The way the FED
phase was currently performed did not really contribute to overcoming or avoiding the
complexities that were faced later during project execution. The interviewees perception
on the scope definition, a crucial part of FED, was very different. The project manager, who
was inexperienced in the field, indicated that the scope was insufficiently defined at FID,
which was not agreed by the other interviewees, who were very experienced in the field. In
conclusion, the project team was not well integrated as a team. Not internally in the owner
company, but also not with the contractor. Lots of the complexities faced in this project
were related to inexperience with and between parties and differences in working
procedures between the parties involved.
61
Project
Perspective
Project
complex?
Technical
Organizational
Environment
Scores (1-5)*
4
4
4
Project manager
Lead process engineer
Asset development manager
Yes
Yes
Yes/no
4
3
4.5
4
4
3.5
4
1
2.5
Complexity
changed
during
lifetime?
Overall
direction of
complexity
change?
No
Yes
Yes
n.a.
Increase
Increase
The lead process engineer would not consider project 4 as technologically complex, rather
he would call the project complex because of the large variety and diversity of items
involved and the need to monitor all work processes related to these items. The aspect that
contributed most to the project complexity, in view of the lead process engineer, was
related to the involvement of multiple internal customers, again in the organizational area.
In view of the asset development manager, the project was complex because of the
inclusion of lots and lots of different scope elements, all interrelated and spread over large
62
areas of the site. Particularly brownfield projects like project 4 she considered more
complex than green field projects, because of the linkages with existing systems in case of a
brownfield project. The aspect most contributing to project complexity in view of the asset
development manager was related to the scope definition; she indicated the scope was not
complete and not well enough understood in terms of interrelations. She also mentioned the
weakness of the operational implementation plan at the moment of the final investment
decision. Further she mentioned the, contradicting, good front-end loading score received in
IPA benchmarking (IPA, 2009a).
Comparing the answers of the three interviewees (see also Table 3.8) again organizational
complexity arose as the aspect contributing heavily to project complexity. Besides, the
importance of a thorough and well understood scope definition and corresponding
operational implementation plan became clear: technical complexity was also rated high
and should not be underestimated for this type of brownfield project. By his role, which is
mostly internally focused, the lead process engineer probably had less attention for the
environmental complexity. Underestimation of the complexity of the project scope seems a
shared opinion amongst the interviewees.
How about the dynamics of project complexity for project 4? The opinions of the three
interviewees pointed in the same direction with different emphasis: an increase in project
complexity in the project execution phase because of poor project definition. According to
the project manager, the complexity of project 4 did not change over its life-cycle;
however, the complexity during execution was not recognized during project development.
The lead process engineer also indicated the underestimation of the complexity during
project execution, but he argued that hence project complexity did change over its life-cycle
(increased during project execution because of the high number of systems involved and the
priority operations got above project execution). According to the asset development
manager, project complexity increased over its life-cycle by major scope changes that were
done during development and detailed design, requiring recycles for implementation.
3.5.3 Interview results on front-end activities
A summary of the interview findings on front-end activities is given in Table 3.9. In view
of the project manager, project 4 perfectly followed all procedures in FED, however, the
real content or depth was lacking. It was more tick the box than thorough project
preparation. In FED, several specialists indicated that problems would occur if certain
aspects of the project were skipped, but they were not taken seriously, according to this
project manager (note that he was replacing the original project manager who was sent off
because of the problems in the project). This project manager considered it an important
task of a project manager to take the technologists serious in FED, realising they most often
have a point; they are no pushers by nature, generally speaking. In FED, the complexity
of the project execution was underestimated and not well recognised, according to the
project manager. The asset development manager shared this opinion. In her view, no one
realized how complex the project was, while they were in the front-end development phase.
All involved were aware of the different elements in the project, but not of their
interrelations and the consequences in project execution.
The asset development manager stressed that one of the problems in project 4 was that
major scope changes occurred rather late in the FED phase, and they werent really worked
out in detail before FID was taken. In her view, if this happens in a project, either postpone
the FID decision moment to make sure you have the correct details or do not accept the
63
scope change: in case the scope change is the right thing to do, forget about the schedule
and give the team the time to finalise the work.
Project
Project manager
Lead process
engineer
Asset development
manager
Value of FED?
Complexity in execution was not recognized
in FED; project should have been put on hold
in FED. FED should be more about content,
less tick the box.
Consequences for project implementation
were underestimated, despite involvement of
operations people.
Only after FID people seem to start thinking.
Continuity in the project team matters.
No one realized the complexity of the
project, interrelations between different
elements.
In case of late scope changes, postpone FID.
Opinion on
Fit for purpose scaling?
All procedures were
followed but the content
and real depth was
lacking.
Part of FED was skipped
in this project and is
skipped too easily in
general.
The project did
everything it had to do
and more. But: the
quality of the activities
was lacking and this is
more important.
In view of the process engineer, the normal construction reliability reviews were done in
FED, but only during execution it became clear that the scope would require much more
segmentation for successful implementation. Even with people from operations involved in
FED, the consequences for implementation were underestimated in FED. In view of the
process engineer, one of the problems of the project was that the Basis of Design (BoD) at
the end of FED1 still contained two options, but it was not clear how these options should
be treated in the project and who would take the decision about which option to choose. In
his view, only after FID, people seemed to start thinking and realizing the real implications.
Therefore, for him the value of FED is in timely involving the right people and being clear
about the roles and responsibilities. He also stressed the importance of continuity in the
project team. In the early FED phase (FED1), the team mainly existed of hired people from
outside the owner organization, but they all left before implementation. At the contractor
side, there was some more continuity, but the owner organization was not in control of the
project. Note: the unclarity about the options could be considered a FED management
flaw; this easily could have been prevented by assigning a person with decision
responsibility.
In view of the project manager, no fit for purpose scaling was applied; all obliged
procedures were completely and correctly followed. For him, fit for purpose scaling
sounds like an easy way of skipping essential parts of the project of which he is not in
favour. In his view, parts of FED can be skipped too easy already, for example the so-called
FED2 phase. FED2 was not obliged for this project and hence not performed. After FED2,
normally the FED3 phase is performed after which the FID is taken. The process engineer
had the same opinion: FED2 both in this project and in general seemed to be skipped too
easy. In view of the asset development manager, the project did everything it had to do and
more. But in her view the quality of the activities, which is more important in the end, was
lacking. Concluding from these opinions, it seems that, despite the considerable effort spent
in FED, project execution was not well prepared.
64
65
indicate what aspect contributed most to the complexity of the project; in his view it was
the combination and the number of issues that made the project complex.
Table 3.10: Summary interview results on project complexity, project 5
Project
Perspective
Project
complex?
Technical
Organizational
Environment
Scores (1-5)*
Project manager
Yes
Lead engineer
Yes
2-51)
Managing director
No
2-4
Complexity
changed
during
lifetime?
Yes
Yes
2)
Yes
Overall
direction of
complexity
change?
Increase,
areas change
Increase
Decrease /
Increase
In view of the lead engineer, project 5 was complex, although merely for the contractor,
since all activities were outsourced and all risks were transferred to the contractor. The
project complexity in project 5 resulted from the number of parties involved, parallel
activities that took place with a variety of tasks, high safety demands, difficult logistics and
the lack of experience of most parties involved. The aspect that contributed most to the
project complexity was related to the differences in background and safety culture of the
parties involved, requiring extra effort of the project team to create more HSE awareness.
Also the technical complexity of the equipment was heavily contributing to the project
complexity, in view of the lead engineer.
In view of the managing director, project 5 was not complex. Some elements in the project
he found difficult because of dependencies and he indicated quite some elements had to
come together, but all together it did not result in a complex project, despite the innovative
character of the project, the low cost requirement and the hard contract negotiations. He
considered the relation with the governmental parties the most difficult because of their
different roles in the project.
The three interviewees were non-aligned about which aspect contributed most to project
complexity (see Table 3.10). Either they thought it was highly interrelated (project
manager) not complex at all (managing director, despite high scores in Table 3.10) or in
some aspects complex, particularly organizationally complex in perspective of the
engineering contractor (according to the lead engineer). Not all were involved in all project
phases, and also their years of work experience considerably differs, which might partially
explain this difference. The lead engineer indicated that the project was technically
complex, which was not the case in view of the managing director. This difference could be
explained by the managing director having a more external focus, compared to a lead
engineer.
How about the dynamics of project complexity? Here the three interviewees were rather
aligned. The project manager indicated that the complexity of project 5 changed
66
particularly because the area of complexity changed. At early project phases, the political
area was very complex, as well as the economic and commercial areas. After the final
investment decision, other areas became more complex like the technology part and in
some aspects the organizational part. Although in some areas you would lose complexity,
the project manager overall saw an increase in complexity, also because of time and money
pressure. The managing director had a similar opinion: complexity from the environment
started high and then decreased once there was clarity about permits and ecological review
programs etc. Such a decrease was similar for political complexity and commercial
complexity; after completing contract negotiations all was mostly clear. The technical
complexity, however, strongly increased after signing the contracts, because detailed design
was done after the final investment decision. The lead engineer indicated project
complexity increased during the project execution phase.
3.6.3 Interview results on front-end activities
A summary of the interview findings is given in Table 3.11.
Project
Perspective
Project manager
Value of FED?
Process of putting together good
project execution plan before FID.
This was a huge effort that brought
together the team.
Rigorous management processes are
important.
Opinion on
Fit for purpose scaling?
For the project manager, the value of FED was a good project execution plan in writing
before FID. He experienced it as a huge effort that brought the team together, integrating all
knowledge in one document. The process of putting it together he considered essential;
during project execution the delivered plan was not used that much, but the writing
strengthened the team. In view of the project manager, it beneficially contributed to the
project that some key players were involved both prior to and after FID, although this could
have been done even better by bringing in the complete project team earlier. In view of the
project manager, team work is essential in achieving good project performance: getting the
right people to work together in the right way. He also stressed the importance of rigorous
management processes describing what needs to happen when, which was well in place for
this project, in his view. Regarding risk management, the project manager indicated that the
number of risks to be monitored should be kept to a reasonable number that can be handled
67
by the project team, to stimulate active usage and avoid that the risk register is just checked
for the next stage gate review.
In view of the lead engineer, in hindsight FED could have been improved by giving more
attention to the HSSE culture of the foreseen partners in the project, particularly focusing
on potential differences in HSSE culture. Also the level of relevant experience of the main
contractors involved should have been given more attention, according to the lead engineer.
However, due to a very long pre-phase in which the main contractor was already involved,
that contractor sort of automatically came into the next project phase. In view of the
managing director, complexity was not specifically managed in the FED phase, but
thorough risk management was done by making an inventory of the risks, further address
these risks and appointing risk owners. The organizational complexity could have got more
attention in the front-end phase by putting effort in bringing the different cultures
(contractor, owner) together, according to the managing director.
A formalised concept of fit for purpose scaling was not used in this project, in view of the
project manager and the lead engineer. According to the project manager, at the time of the
project there was no formal assurance process. During the project, the project assurance
management process was drafted based on available owners organization procedures,
hence making a sort of fit for purpose scaling process in his view. The lead engineer was
not aware of any particular fit for purpose scaling applied in the project procedures. In
this JV project, procedures based on the owners organization standard were applied, but
not all were followed because of the non-common character and history of this project,
according to the lead engineer. In view of the managing director, fit for purpose scaling
was applied in the project by carefully selecting which standards for design and execution
could be used in this non-traditional project and which ones were not applicable. In his
view, the project team took the liberty to apply fit for purpose scaling for this project,
because it was the first time such a type of project was done within the owner organization.
Relevant experience to build upon was lacking within the owner organization, providing
interpretation space.
3.6.4 Overall case conclusion
Looking at the project characteristics, this project would be characterized as complex with
complexities in various areas: new technology, new business, working in a JV, government
involvement and the fact that the project was driven by both (!) cost and schedule.
However, because of the lump sum turnkey contract, most of the complexities were faced
by the contractor, not by the project owners employees who were interviewed. Still, the
interviewees indicated the areas from which they perceived considerable complexity:
political, technical, and the non-expected differences in safety culture between the parties
involved. The complexity as a result of the large number of dependencies was indicated by
all three interviewees.
Although the project as such was delivered successfully, even better performance could
have been achieved by treating organizational complexity in the early project phase,
particularly aligning parties and their (safety) cultures. One of the FED deliveries, the
project execution plan, was seen as beneficially contributing in building the project team.
68
Project
Perspective
Project complex?
Technical
Organizational
Environment
Scores (1-5)*
6
6
6
Project manager
Project manager front-end
Control manager
Yes
Yes
Yes
4
3
5
4
2
5
3-4
4
4
Complexity
changed
during
lifetime?
Overall
direction of
complexity
change?
Yes
Yes
No
Evolving
Decrease
Decrease
In view of the project manager, project 6 was complex because of the non-alignment
between the business objectives of the joint venture partners. One partner was focused on
having a profitable project, run as efficient as possible, whereas the other was more focused
on getting as many local people employed as possible. Further, she considered the project
technically complex, with a lot of moving parts involved, resulting in some (expected)
iterations in the start-up process. The aspect contributing most to the project complexity,
according to the PM, was related to HSE, particularly because of the major difference in
HSE standards between the owner and the local organizations. Because of the scarcity of
skilled resources onsite, this required additional HSE awareness building and training.
In view of the front-end project manager, project 6 was complex due to a lack of local
experience of the owner company and the complexity of the technology. The aspect that
contributed most to the project complexity in his view, was related to operating in this
specific environment, with much less influence for the owner organization than he was used
69
to have, requiring on-going compromising between the owners standards and what could
be achieved in that environment.
The control manager considered project 6 complex in terms of not having experience with
the joint venture partner, being the first execution project in this technical area at this
location, including novel technology and a novel technical process. He could not indicate
which aspect contributed most to the project complexity. In his view, the aspects were quite
interlinked and influencing each other, such as cultural differences, novel technology,
organization of the project team, unfamiliarity with the joint venture partner and experience
with the contractor.
For the front-end project manager the complexity of the environment was the most
contributing to project complexity. His opinion was slightly different than the similar
opinions from the two others (see also Table 3.12), but they both could speak the local
language, hence eliminating potential communication problems. Still they valued
organizational complexity as equally high adding to project complexity as technical
complexity. Note that the opinion of the front-end project manager was heavily based on
his experiences in front-end.
How about the dynamics of project complexity? The three opinions were not aligned. In
view of the project manager, the complexity of the project evolved when moving from one
project phase to another, where each phase had different complexities. For example, before
project execution stakeholder engagement was complex. Next, during construction, the
complexity was increased, particularly in logistics and HSE. During installation and startup, complexity was found in finding competent and skilled people and technical complexity
increased because of the non-straightforward technical process. In view of the front-end
project manager, the complexity already decreased within the front-end development phase.
Once experience was gained and skills were developed for working in that particular
environment and organization structures were built, it became less complex. Also for the
technical part; the project became less complex with increasing knowledge and experience.
In view of the control manager, the overall complexity of the project did not really change.
In organizational aspects, he considered the project a little more complex in front-end than
during project execution, because of better alignment amongst people in project execution.
Still, the overall project complexity he considered unchanged during front-end and
execution.
3.7.3 Interview results on front-end activities
A summary of the interview findings is given in Table 3.13. In view of the project manager
of the execution phase, as much as could be done was done in FED, but in front-end you
simply cannot foresee all problems that will occur when you start to construct. With the
benefit of hindsight, it is by definition easier to see what could have been done better.
In view of the project manager of the FED phase, during FED they tried to prepare for
project complexity. Organisational complexities were handled by adding the way in which
the organisation would be run to the JV contract, with detailed role descriptions and from
which JV-partner the person would come, how decisions would be taken, etc. The FED
project manager indicated he often relied on the contract and referred back to the contract
which in his view helped in limiting the organisational complexity. In terms of technical
complexity, already in FED it was realised it was a complex matter, in view of the FED
project manager. However, he would suggest not showing such technical complexity to the
70
JV partner. In his view, it would have been better to do some developments in-house and
only involve the partner after freezing the technology concept, to avoid that the JV partner
loses confidence.
Project
Project manager
Project manager
front-end
Control manager
Value of FED?
In hindsight it is easier to see what you should
have done, although considerable effort was
spent in FED. One never knows the problems
that will happen when construction starts.
FED tried to prepare for project complexity, for
example by specifying all in the JV contract on
which he often relied.
FED tried to address all complexities,
technological challenges became clear.
Opinion on
Fit for purpose
scaling?
Not applied in the
project
Not applied in the
project
Not applied in the
project
In view of the control manager, during front-end development the different complexities
(technology, organisation, how to look for partners) were tried to address in the project
execution plan and execution strategy. The control manager indicated tried: meaning that
they were pretty well aware of the technological challenges, they did develop fall-back
options but the complexity was still there: they addressed the risks, raised the issues, but a
lack of experience and resources could not be treated. Also in the organizational field they
identified challenges, for example related to the country where the project was performed.
He complimented the good mixture of people in the team: some key persons thoroughly
knew the local language and culture, which was important in his view because not all JV
people were able to speak English well enough.
So the value of FED, in view of the interviewees, was in preparing for complexities in
project execution. For this project, fit for purpose scaling was not applied; all procedures
available were just followed as was, probably this was related to the Asian country and
culture in which the project was performed.
3.7.4 Overall case conclusion
Based on the project characteristics, this project would be assessed as potentially complex
with complexities in various areas: the project took place in Asia in a rural area,
involvement of a JV, involvement of new technology, considerable number of workers,
required local content and new business for the company. This first view was confirmed by
all the interviewees. One of the major complexities to overcome was the lack of local
experience and the corresponding language problems. Once the FED PM was replaced by a
PM who did have local experience and could speak the local language, this aspect of
complexity was overcome. In the FED phase, the FED project manager clearly relied on the
contract with the local JV partner that was deliberately drawn up to deal with this. Although
contracts are there to act accordingly, this emphasis on the contractual aspects suggests that
the relation between the JV partners could have been better and more easy-going. This
suggestion is supported by the fact that the business drivers (or objectives) across the JV
partners were non-aligned, in view of the project manager. In this project, public and
private interests conflicted.
71
The role of FED was considered key in view of all interviewees, albeit for different reasons.
In the FED phase, all technological challenges became clear and it was tried to prepare for
later project complexities, but as the project performed marginally, some complexities
were not timely foreseen or acted upon. The project performance was marginal, still (and
not poor), but most probably this was because of the hesitance in admitting the actual
failure of this highly complex project.
two others, both having a controlling role, saw a (small) decrease in complexity after all
agreements were settled and the final investment decision was taken, similar to the opinion
of half of the project managers.
The owner representatives tended to consider their projects not complex: twice a frank no
was scored, twice they couldnt make a clear decision and once a yes was scored. Despite
this overall impression, they unexpectedly scored the different aspects of project
complexity relatively high, compared to the other two groups (project managers and team
members). This might be related to a sort of strategic behavior: the written outcome was
more conservative (higher complexity) than from the oral discussion was concluded. It
emphasizes the difficulty of an absolute interpretation of the complexity scores given. They
also had different opinions about which aspect contributed most to project complexity;
some mentioned organizational aspects but also technical complexity was mentioned. The
latter is surprising since the owner representatives were expected not to be concerned about
the technical aspects. On the other hand, because they were more on a distance, they
might have perceived it as more technically complex.
All owner representatives indicated that the project complexity, although hardly present in
their view, changed over its lifecycle; the majority of them saw a decrease after the final
investment decision and some indicated an increase of the technical complexity in project
execution. The overall decrease in complexity could correspond with their decreasing
involvement: they indicated to be more closely involved in the earlier project phases and
left it to the project manager in execution. One owner representative mentioned an
overall decrease of project complexity with a small increase at the end of all project phases
because of all parts coming together. Such a model, with per project phase decreasing
complexity followed by increasing complexity, could bridge the perspectives of the
different respondent groups under consideration.
All project managers did consider their project complex, which was not the case for all
team members, neither for the owner representatives. Some sort of defense mechanism
might play a role here; admitting that something is complex, protects in case of project
failure (see for example case 4). However, also the opposite might play a role; your image
as a project manager boosts in case you successfully deliver a highly complex project (see
for example case 5).
Regarding the dynamics of project complexity, there seems overall agreement that project
complexity changed over its life time. Project team members mostly stressed an increase of
project complexity during project execution. Some of the project managers also saw an
increase in project complexity during project execution, but this seemed related to the
involvement of unproven technology in the project. Some other project managers
concluded a decrease in project complexity after the final investment decision particularly
in the areas of stakeholder management, politics, economics, etc. The owners
representatives overall did conclude a decrease in project complexity after the final
investment decision, probably related to their smaller involvement in execution. Hence
perspectives of project professionals on dynamics of project complexity considerably
differed amongst and within the different groups. And these differences are not only found
in the amount of complexity, but also in the changing areas of complexity.
The scores given by the interviewees for the areas contributing most to project complexity
can only be interpreted per interviewee; absolute scores have no value since these are
73
amongst others colored by previous experience and role in the project. Thus analyzing, 13
interviewees did score the organizational aspects (equally) highest, 8 interviewees did score
the environmental aspects (equally) highest and 6 interviewees did score the technical
aspects (equally) highest. This emphasized the important contribution of organizational
aspects to project complexity, partly related to working in a joint venture, in view of the
project professionals. Note that 16 of the 18 interviewees scored technical, organizational
and environmental aspects differently, hence indicating the usefulness of distinguishing
these categories.
In view of the interviewees, project complexity often was induced by a lack of thorough
FED and the lack of making clear arrangements between the parties involved. Therefore let
us take a look now at an analysis of the front-end activities: how was project complexity
dealt with in the front-end project phases?
3.8.2 Adapting the front-end development phase to the particular
complexity?
First of all, it should be noted that the projects that were investigated in this study were all
prepared several years ago when there were strict company guidelines and procedures for
managing such projects. Hence it is not surprising that adaptations of the normal procedures
are hardly reported based on the current cases (fit for purpose scaling). At the time the
project took place, it was simply not allowed to deviate from the standard, except in some
non-standard situations. The need to deviate from the standard, however, or the advantages
of a fit for purpose scaled front-end development phase were mentioned in two of the
investigated cases (case 3 and case 5).
What was the value of the FED phase, in view of the interviewees? The FED phase
contributed to team integration (case 1, case 2, case 5) and enabled a clear role distribution
amongst the parties involved (case 3). Further, a thorough FED phase could prevent major
scope changes (case 1, case 2, case 4) and would enable straight implementation of the
project execution plan (case 1, case 2, case 5). However, often project complexity was
underestimated or not well recognised in the FED phase (case 3, case 4, case 5, case 6).
Whether project complexity was taken care of in the front-end development phase differed
across the cases. Only in two cases explicit action was undertaken to prepare for the
expected project complexity (case 5 and case 6). In case 5, they recognised that even more
attention could have been paid towards overcoming the HSSE culture differences between
the companies (treating organizational complexity) and that a more detailed design study
could have been performed (treating technical complexity). In case 6, they tried to prepare
for the expected complexity by drawing up a very detailed JV contract. This can be
considered as a strict engineering approach, which might have caused problems in the
relational field. On the other hand, in case 3, no action could be undertaken in view of the
interviewees because the complexity during the project execution was simply caused by the
people involved. Such induced project complexity obviously should be avoided. More
implicitly, team integration was considered crucial to overcome interface complexities (all
cases).
In view of several interviewees, project performance will improve by adapting the FED
phase to the particular project complexity. The current study, however, indicated that such
fit for purpose scaling approaches were not yet common in the company under
investigation.
74
approach was expressed by some of the interviewees. A fit for purpose scaled or tailored
approach is also advocated in literature (Shenhar & Dvir, 2007b; Turner, 2008).
Although we did not explicitly ask for it, the interviewees expressed relevant front-end
aspects in the six studied cases throughout the interviews. Table 3.14 summarizes these
relevant front-end aspects.
Amongst these relevant front-end aspects (in some cases better called: activities), several
main themes can be distinguished: project team related, goal/scope related, risk
management related, governance related, contract/contractor related. Several of these
aspects, concluded from the case studies, can also be recognized in literature, see Table 2.3,
but on a more general level. For example, team composition is one of the critical success
factors from literature (Bakker et al., 2010), under which a number of Table 3.14 aspects
could fit: integrated project team, continuity of the team, presence of necessary disciplines,
social team building activities, etc. Others (avoid late scope changes, timely involvement of
parties) are also recognized in literature (Love et al., 2002). The relevance of all these
themes and particularly the underlying front-end aspects or activities could be further
explored in the survey of Chapter 5, see Section 5.2.2.
Table 3.14: Relevant front-end aspects
Description
Prevent late scope changes
Influence of project manager on human resourcing
Continuity of the team
Contract type and consequences
Integrated project team
Interaction between project manager and steering committee
Social team building activities
Project meetings
Interaction between project manager and (sub)contractors
Avoid late entry of parties
Selection of project manager
Presence of necessary disciplines
Active monitoring of risks throughout the project (risk register)
Alignment of project goals
Active monitoring of project goals
Case nr
1, 2, 3, 4
1, 2, 3, 6
1, 2, 4
1, 2, 5
1, 2, 6
1, 3, 6
1, 5
1, 5
1, 5, 6
2
2, 3, 4, 6
2, 4
2, 5
3, 4, 6
4, 5
3.9 Discussion
In this chapter the results of an explorative, empirical research into the perspectives of
project professionals on project complexity in the process industry were presented. It was
investigated whether the interviewees did consider their project complex and in which
aspects. This chapter contributed to answering the following questions (sub-questions 1 and
4 of Chapter 1):
1. What is project complexity as experienced by project professionals?
It was concluded that various aspects contributed to the complexity of the projects under
investigation. In view of the interviewees, organizational complexity prevailed over
external complexity and technical complexity. It was concluded that the technically welleducated interviewees were well prepared to deal with technical complexities, did
recognize external complexities to a lesser extent and particularly faced organizational
76
complexities in their project. Project complexity was shown to be a subjective concept and
highly dynamic.
4. What are the relevant front-end activities to deal with project complexity?
It was concluded that often project complexity was not recognized in the front-end phase
and hence not treated (well). A lack of thorough front-end development was shown to
increase the complexity of the project, in view of the interviewees. The research showed the
relevance of several front-end activities related to project team building, goals/scope
setting, risk management, governance, contract strategy and contractor interaction. To
overcome interface complexities, team integration was considered crucial.
The remainder of this section discusses some open ends.
3.9.1 The engineer as a project manager
The majority of the interviewees did consider their project complex and the aspect most
contributing to project complexity was in the organizational field. The importance of
focusing on socio-organizational complexity also is clear from literature (Antoniadis et al.,
2011). Because of the highly technical character of the projects involved, more emphasis on
technical complexity was expected, but the project managers in our study, all with an
engineering background, did not think technical complexity was the main issue in their
projects. This supports literature that suggests to develop and train project managers much
broader than their technical skills (Crawford, Morris, Thomas, & Winter, 2006).
The fact that our interviewees all had an engineering background is not surprising and even
favorable, as also literature indicates the importance of a project manager who is aware of
the technology involved and capable of understanding the implications of the technology
and its environment for the project (Halman & Burger, 2002).
Recent research with, and about, project managers with an engineering background
(Hodgson, Paton, & Cicmil, 2011) suggests a tension between technical and managerial
functions (p. 374). In technical domains, project managers typically have a technical
background under the assumption that a level of technical expertise is essential for the
effective oversight of the technical aspects of the work process. p. 374. Our study confirms
their findings in a sense that our interviewees did have an engineering background and did
not recognize particular technical complexities (they are trained to deal with these),
but their technical capabilities not necessarily are managerial capabilities, as demonstrated
by the organizational complexities faced. This tension between technical and managerial
functions therefore needs further exploration and explanation.
3.9.2 Dynamics of project complexity
Whether and how the project complexity changed during the projects life cycle was shown
to be related to the role of the interviewee within the project. The project team members
predominantly saw an increase of project complexity in project execution. The owner
representatives, however, predominantly concluded a decrease of project complexity after
the final investment decision. This difference could be explained by the different
involvement of the respective groups. The overall conclusion of the project manager
somehow bridges the overall opinions of the other groups: half of them saw a decrease in
project complexity and half of them emphasized that the area of complexity changed. It
seems that often a complexity increase in later project phases is caused by underestimation
or poor recognition of the complexity in an earlier project phase. Changes in complexity
77
across the different project phases, however, were very differently perceived by the
interviewees, potentially related to involvement or role of the interviewee. Continuity in the
team between the different project phases (particularly front-end and execution) was
throughout mentioned as beneficial for the project.
These results can be matched to literature findings on dynamics of project complexity
(Girmscheid & Brockmann, 2007). They reported a general reduction of complexity over
the project life-cycle (although complexity not necessarily is reduced to zero), with a
sudden rise in complexity in case of, for example, a change order. In the cases investigated
in our study, often an overall reduction of project complexity was reported, with some
sudden complexity explosion through project execution. In case such an increase in
complexity is caused by the people involved, we touch upon self-induced complexity
(Geraldi, 2009); a form of complexity caused by mismanagement (see for example case
3), or by improper front-end phases, in which complexity was not timely recognized.
Also our finding on the importance of team continuity was confirming recent literature
findings (Maurer, 2010). In that research, it was shown that it is beneficial for a project to
have team members that () join the project throughout its duration and work full-time
on the project, (since they) have greater opportunities to interact. p.635. This was
particularly evident from our cases 1, 2 and 4.
3.9.3 The need for an extensive complexity framework
Because of the very different perspectives on project complexity, the dynamic character of
project complexity, and the various aspects contributing to the projects complexity, a
universal classification of these six cases towards their technical, organizational and
environmental complexity was not possible. A large project including lots of employees
(case 1), was not perceived as complex, whereas a small brownfield project (case 4) was
perceived as complex by experienced professionals. Hence the project context is important
in assessing a projects complexity, as well as other than technical aspects that at first sight
might be overlooked (Antoniadis et al., 2011; Sauser et al., 2009).
To enable a classification of projects towards their complexity, an extensive framework
covering different main fields of complexity (technical, organizational and environmental)
would be required. With such a framework also more in-depth research into the different
perspectives on project complexity could be performed. Chapter 4 of this dissertation
therefore presents the development of a framework to grasp project complexity.
Subsequently, ideas towards a fit for purpose scaled front-end development are explored
in Chapter 5.
78
Chapter 4
Grasping project complexity: the TOE framework
This chapter is part of a paper that was published in the International Journal of Project
Management (Bosch-Rekveldt, Jongkind, Bakker, Mooi, & Verbraeck, 2011a).
This chapter presents a framework for characterizing project complexity in large
engineering projects, which can be used to adapt the front-end development phase of
engineering projects to the particular complexity. Recently, a large number of project
complexity related papers were published, demonstrating the evident importance of
complexity in current project management research, see Section 2.7, and to sketch the
relationship between complexity theory and project management (Cooke-Davies, Cicmil,
Crawford, & Richardson, 2007). In addition, there are suggestions to look at project
managers competence development in the view of project complexity (Remington &
Pollack, 2007; Thomas & Mengel, 2008), e.g. specific complexities in a project might
require specific competence development (Bosch-Rekveldt et al., 2009b). The College of
Complex Project Managers (Australia) even developed a Competency Standard for
Complex Project Managers (DMO, 2006b).
The large number of recent, project complexity-related papers illustrates the evident
importance of complexity in current project management research. The mentioned
studies do provide valuable theoretical insights and, in some cases, do link theory and
practice. The management of large engineering projects, however, would require a
framework for project complexity. This framework could then be used to -further- adapt
the front-end development phase of these projects to the particular project complexity with
the aim to achieve better project performance. Currently, however, no solid framework,
based on both theory and practice, is available that supports the characterizing and
understanding of project complexity and fully appreciates the richness of project
complexity of, specifically, large engineering projects.
In order to develop a framework based on theory and practice, the research question to be
answered in this chapter is (sub-question 2 as defined in Chapter 1):
2. How can we characterize project complexity in large engineering projects?
To answer this research question, several sub-questions were defined:
a) What elements of the project do contribute to project complexity according to
literature?
b) What elements of the project do contribute to project complexity according to
project professionals?
c) Which of these elements from sub-questions a) and b) should be included in a
framework to characterize project complexity in large engineering projects?
79
Despite the intrinsic dynamic character of project complexity during the different phases of
a project (findings of Chapter 3), this chapter primarily focuses on elements contributing to
project complexity that can be assessed before the project execution phase is started
(before FID). This was done because the intended use of such a framework is in early
project phases.
After the research approach in Section 4.1, the literature results are summarized in Section
4.2, followed by the case study results in Section 4.3. The resulting framework to grasp
project complexity in large engineering projects is presented in Section 4.4 and further
discussed in Section 4.5. Section 4.6 discusses the foreseen use and developments of the
framework, as well as limitations of the research. Conclusions and recommendations are
presented in Section 4.7.
Amongst different researchers, there is some debate about the exact definition of a
complex project and the differences between complicated and complex projects
(Maylor et al., 2008; Whitty & Maylor, 2009). In their view, a project would only be
complex when uncertainties play a role, if not, the project at most would be complicated.
Rather than further elaborating this debate, we consider complicated projects to be
(potentially) complex - to a certain level. A framework to grasp project complexity could
be beneficial for complicated projects as well as complex projects.
In this research, a distinction is made between project complexity and project
management (or managerial) complexity: project management complexity is seen as a
subset of project complexity, e.g. the part of project complexity related to managerial
complexity. Such a broad approach was chosen with the aim to grasp all aspects of project
complexity and not to be limited to managerial complexity.
Some elements, although found in literature, were not explicitly included in this final
literature table:
- In case the elements were covered in another element, the original elements were not
included, like uncertainty in goals and methods (Williams, 1999), well covered in
unclarity of goals and uncertainty in methods respectively, or the degree of
interdependence between and among the product and the process (Tatikonda &
Rosenthal, 2000). The latter were covered in dependencies between tasks and
interrelations between technical processes.
- In case the elements were too generic, such as uncertainty (Williams, 1999) or
dependencies with the environment (Vidal & Marle, 2008). These elements were not
explicitly added to the final list but implicitly they are covered, in elements like
uncertainty in methods or risk from environment.
- In case the elements were focused on how to manage project complexity instead of
how they contributed to project complexity, like project manager leadership style
(Mller & Turner, 2007) or responsibilities of partners (Geraldi & Adlbrecht, 2007).
These elements were not included in the final list.
Explicitly or implicitly, the concepts as described in Section 2.7.2 can be recognized in the
list of elements in Table 4.1.
The elements were further developed, refined and defined (right column in Table 4.1,
ordered alphabetically), in order to enable a comparison with the elements found in the
case studies (Section 4.3).
4.2.2 Elaborating on the proposed structure for the framework
Looking at the literature review as well as the elements gathered from the literature (see
Table 4.1), it was concluded that not only the technical or technological aspects in a
project determine the projects complexity. As indicated earlier, next to technical aspects,
particularly organizational and environmental aspects play an important role.
81
82
Authors
(Crawford, 2005; Geraldi & Adlbrecht,
2007; Vidal & Marle, 2008)
(Geraldi & Adlbrecht, 2007)
Elements defined,
alphabetically ordered
Clarity of goals
Company internal support
Compatibility of project
management methods and
tools
Contract types
Co-operation JV partner
Dependencies on other
stakeholders
Experience with parties
involved
(Baccarini, 1996)
Goal alignment
Level of competition
Newness of technology
(world-wide)
Interrelations between
technical processes
Number of different
disciplines
Number of different
languages
Number of different
nationalities
Number of different norms
and standards
Number of financial
resources
Number of goals
Number of locations
Number of stakeholders
Number of tasks
Number of project
members
Frequency and impact of
changes in macroorganization (suppliers,
contract, raw material
pricing, exchange rates)
Client transparency,
empathy (the personal
and intangible matter that
improves co-operation)
Team transparency,
empathy (the personal
and intangible matter that
improves co-operation)
Frequency and impact of
changes in technological
aspects (quality, velocity
etc.), dynamism (i.e.
changing information,
specifications, change
order etc.)
Degree of definition of
methods
Variety of perspectives
Variety of tasks
Authors
(Dewar & Hage, 1978; Baccarini, 1996);
Elements defined,
alphabetically ordered
Overlapping office hours
Political influence
Project drive
Project duration
Required local content
Trust in contractor
Uncertainties in scope
Uncertainty in methods
Risk management
Scope largeness
Variety of stakeholders'
perspectives
Variety of tasks
83
84
Figure 4.1: new and total number of elements mentioned by the interviewees.
Interviews are ordered according to interview date. #.1: interview with project
manager. #.2: interview with team member. #.3: interview with owner representative.
Note that Case 6 involved 2 project managers and no owner representative.
Note that 5 of the 6 first interviews were with the project managers of the projects under
investigation and the number of elements contributing to project complexity they were
raising seems higher than the other interviewees did. This might be related to their specific
role in the project: the project manager can be expected to have the widest view on
elements contributing to project complexity. Next to the interviews, project documentation
(already studied prior to the interviews) was used to verify and complement the interview
results.
Based on these case results, the elements contributing to project complexity from a
practical perspective were gathered confirming or complementing the literature elements.
Table 4.2 shows the 49 elements contributing to project complexity based on the case
study results, ordered in number of occurrences from the interviews (maximum number is
18) and cases (maximum number is 6). Almost all elements found in the literature survey
were independently confirmed by the interviewees, without explicitly asking for it (see
column source in Table 4.4).
Note that 5 of the 6 first interviews were with the project managers of the projects under
investigation and the number of elements contributing to project complexity they were
raising seems higher than the other interviewees did. This might be related to their specific
role in the project: the project manager can be expected to have the widest view on
elements contributing to project complexity. Next to the interviews, project documentation
(already studied prior to the interviews) was used to verify and complement the interview
results.
85
86
Mentioned in how
many interviews?
17
16
15
15
14
13
13
13
12
12
11
11
11
10
10
9
8
8
8
6
6
6
6
6
6
6
6
5
5
5
5
5
4
4
4
4
4
3
3
3
3
3
3
3
2
2
2
1
1
Mentioned in how
many cases?
6
6
6
6
6
6
5
5
6
6
6
5
5
5
5
4
5
5
5
5
4
4
4
3
3
3
3
4
4
3
3
3
4
4
3
3
2
3
3
2
2
2
2
2
2
2
1
1
1
Several aspects contributing to project complexity were brought forward in all six cases,
showing wide support for particularly these aspects. In an attempt to summarize these
aspects; they were clustered in terms of the what, the who and the how of the project
as follows:
- what of the project in terms of content (interrelations between technical processes,
newness of technology, experience with technology),
- who of the project in terms of parties involved and perspectives (number of
stakeholders, variety of stakeholders perspectives),
- how of the project in terms of staffing and organizing the project (number of
different project management methods and tools, resource & skills availability, trust in
contractor, contract type).
In translating these what, who and how aspects to the complexity framework, the
what-elements logically were assigned to the technical dimension of project complexity.
The who-elements (both related to the stakeholders involved) were assigned to the
environmental dimension of project complexity. The how-elements were assigned to the
organizational dimension of project complexity. The elements describing the what, the
who and the how of a project, could be seen as the key elements determining the
projects complexity. Note that risk was mentioned as contributing to complexity in
different contexts and hence appears three times in Table 4.2.
Next to the elements listed in Table 4.2, the practitioners mentioned some elements that do
not contribute to project complexity as such but rather make it more difficult to manage the
project, e.g. factors like poor communication, poor motivation of the project team, poor
relationship management and unclear distribution of responsibilities. These aspects are
considered project management flaws that do not contribute to intrinsic complexity of the
project and hence these are not included.
Organizational
Size
Resources
Project team
Trust
Risk
Environment
Stakeholders
Location
Market conditions
Risk
87
88
89
The resulting TOE framework is presented in Table 4.4 and consists of 15 T-elements, 21
O-elements and 14 E-elements. The table includes the origin of the elements; either from
literature, from the cases (empirical data) or from both (indicated with L, E or B
respectively). The majority of the elements in the T-, O- and E- categories have literature
as well as empirical evidence (13 of 15, 18 of 21, 9 of 14 for the T-, O- and E- categories
respectively), indicating support for these elements from both theoretical and practical
perspective. In the E-category, there are 5 elements with empirical evidence only, four of
which are related to the location of the project and the fifth which is related to strategic
pressure around the project. The apparent absence of these aspects in literature might be
explained by the specific industry under consideration and/or the deliberate choice to
approach this study from a project management perspective. This explanation might also
yield for the elements with sole empirical evidence in the O-category, e.g. size of site
area and HSSE awareness, with the latter being very much related to the process
industry. The element quality requirements (in the T-category) might not be found in
literature because of the very limited attention for managing quality in the project
management literature (Turner, 2010). Two elements have literature evidence only
(number of goals and project duration). Despite their assumed applicability to the
sector, these elements were not mentioned by the interviewees; they might work on single
goal projects and see project duration as a boundary condition rather than a factor
contributing to project complexity.
In developing the TOE framework, it was decided to maintain the richness of elements
contributing to project complexity as found in literature and practice and not to reduce to a
2x2 matrix, as suggested amongst others in research of Whitty and Maylor on the
Structural Dynamic Interaction matrix (Whitty & Maylor, 2009). The broad TOE
framework with its three levels (categories, subcategories and elements) offers the
opportunity to discuss on various levels of aggregation with the different parties and
stakeholders involved in a project which aspects make the specific project complex, in
their individual views. The current setup also allows extension of the framework for use in
different industries.
The framework thus developed can be used to assess the complexity of an engineering
project. Assessing a projects complexity is a subjective process by nature, in which
perceived complexity based on previous experiences plays an important role (Geraldi,
2009). Because of differences in skills and experiences, people using the framework and
assessing a certain project or phase thereof may come to different conclusions regarding its
complexity (Maynard & Hakel, 1997). But thats fine since the objective of the framework
primarily is a better understanding of project complexity and getting a footprint of the
projects complexity for those involved in the project.
Regardless of absolute scores for the different elements, this framework enables
identification of the complexity areas in a specific project. Knowing these complexity
areas, attention could be paid to the management of these. And, as stated by Geraldi: the
assessment of complexity itself is a tool to enable such active management (Geraldi,
2009).
90
under which several concepts are defined per dimension, in total resulting in more than
100 underlying concepts. Although the levels of detail between the TOE framework (50
elements) and the MODeST model (>100 concepts) differ, the elements or concepts partly
overlap. The developments of the TOE framework and the MODeST model were done
independently from each other in about the same time frame but in different industry
sectors and following a different approach. Compared to the grounded MODEeST model,
the advantage of the TOE framework is its dual base: both literature and in-depth case
studies form the foundation of the TOE framework.
developing the TOE framework, our empirical results suggested data saturation for the
studied cases. To strengthen current results, an industry-wide survey study is performed
with a more quantitative character (see Chapter 5 of this dissertation). Another limitation is
the specific focus of the current study on engineering projects in the process industry.
More research is needed to investigate the applicability of the TOE framework (if at all) in
different industries and on less technical projects. To enable application in different
industries, additional elements can be added to the TOE framework. This can be seen as
strength of the current framework, but also brings another research limitation. We can and
will not claim completeness of the TOE framework.
93
94
Chapter 5
NAP survey study
Parts of this work were presented at the 2010 PMI research conference in Washington
(Bosch-Rekveldt, Hermanides, Mooi, Bakker, & Verbraeck, 2010a) and at the 2011 IRNOP
conference in Montreal (Bosch-Rekveldt, Mooi, Bakker, & Verbraeck, 2011b).
By means of qualitative research, a broad framework to grasp project complexity in large
engineering projects was developed in Chapter 4. The literature study (Chapter 2) and the
exploratory case studies (Chapter 3) resulted in a general understanding of front-end
activities and their perceived relevance. Although we have good reasons to assume (highlevel) relations between project complexity and project performance, as well as between
front-end activities and project performance, detailed understanding about which of the
complexity elements or front-end activities are crucial for improving project performance is
lacking.
To explore the elements that contribute to project complexity in more detail, to evaluate the
newly developed TOE framework and to investigate which front-end activities significantly
contribute to project performance, an internet survey was developed and distributed
amongst the NAP network. This Chapter 5 presents the survey, of which the results will be
analysed in more detail in Chapter 6 and Chapter 7. In Chapter 5, first it is explained why
we used a survey and how the survey relates to the earlier case studies as described in
Chapter 3. Subsequently, details of the survey design are presented as well as the data
collection and the data analysis. Finally, the general findings of the survey are presented:
descriptive results are given about the respondents background and their projects under
consideration, including the projects drivers and the projects performances. The related
research questions are presented in the chapters were they will be answered (Chapter 6 and
Chapter 7).
5.1 Methods
Following an exploratory mixed methods approach (Blaikie, 2009), p.225, the qualitative
approach followed in Chapter 3 and 4 was continued with a quantitative phase. The
building blocks of project complexity, front-end activities and project performance (Figure
1.2 on page 7) and their relations were further explored. A survey was used to gather the
relevant data.
5.1.1 Survey
Why is a survey a suitable data collection technique in this phase of the research? To
explore the relations between the different building blocks, a large number of data points is
required. A survey is considered a suitable research tool for gathering large amounts of data
points across different research units (Baarda & de Goede, 2006; Verschuren &
Doorewaard, 1999). The research unit in our study is a completed project, with the building
blocks of project complexity, front-end activities and project performance as research sub95
units. Hence by performing a survey, data from a large number of projects was gathered.
With a survey, the researcher is kept at a distance from the actual process (Blaikie, 2009).
In case the aim is to gather large amounts of data, this is a clear advantage. Although a
survey needs thorough preparation (the respondent should be able to complete it without
other than written instructions, it should be self-explaining), the actual data collection is
less time consuming and the gathered data is more objective than when structured
interviews would be performed.
A survey can have a confirmatory orientation or an exploratory orientation (Tashakkori &
Teddlie, 1998). Our survey has a dual character: it is exploratory in finding the relations
between the mentioned building blocks and it is more confirmatory when evaluating the
newly developed TOE complexity framework (Chapter 4).
Because of advantages of performing such a survey online (Wright, 2005), such as easy
access to targeted respondents, time and cost savings for the researcher as compared to a
paper version, a web based survey was designed. Research showed that one of the
prejudices against web-based surveys (web-based surveys have a lower response rate) is not
necessarily true when taking care of the process of data collection (Porter & Whitcomb,
2007), see also Section 5.3.1 on data collection.
5.1.2 Sample
The survey study was performed within the Dutch process industry, particularly within the
companies that are members of the NAP network (www.napnetwerk.nl). The NAP network
is a platform bringing together companies from the entire value chain in the Dutch process
industry, including engineering agencies and the academic community (NAP, 2009) and
consists of about 100 member organizations. The NAP member organizations vary from
large multinationals to small and medium local enterprises. The companies in this network
are heterogeneous in size and assumed to be dealing with increasing complexity in projects,
hence providing an interesting sample for both the process industry and the project
management community. Their recent publications on front-end loading and improving
project performance (de Groen et al., 2003; Oosterhuis et al., 2008), the latter publication
being a result of their special interest group on front-end loading, also demonstrates their
interest in the topics under consideration.
For this study sampling was done on a convenience basis: only companies that are part of
the NAP network were approached. These companies might be more active in project
management than companies that are not connected to such a network. On top of that, one
could argue that respondents who do contribute to this type of research by definition bias
the data by the fact that they are willing to contribute. The respondents were requested to
answer all questions for their most recently completed project. This provided some
randomization in the sample: rather than allowing the respondents to pick their favorable
project, only their most recently completed project was asked for and included in the study.
5.1.3 Validity
In the development and design of the survey, the following measures were taken to ensure
the internal validity (Tashakkori & Teddlie, 1998). Before the survey was published on the
internet, several experts were asked to test earlier versions of the survey. The experts
consisted both of academics and practitioners. Based on their feedback, questions were
reformulated and terminology was clarified. Also the number of questions was reduced as
96
much as possible without losing essential information by making a stringent split between
the need to knows and the nice to haves.
To increase the data validity, the answer options in the survey included not applicable
and/or (dependent on the specific question) do not know. Without such answer options,
people would be forced to give an answer although the question is either not applicable to
their specific situation or they simply do not know, hence troubling the data. By giving
these answer options, potentially the sample size is reduced since the not applicable and
do not know answers are removed from the data. To limit the effect of data removal,
pairwise exclusion of cases was used rather than listwise exclusion. Listwise exclusion
means that if any variable is missing, the whole case is removed from the dataset, whereas
pairwise exclusion means that if one variable is missing, this case is just not included in that
specific analysis.
Several control variables were defined such as the respondents role in the project, the
number of years of work experience, the number of years of project management
experience, (if applicable) accreditation in project management, company size, etc. See
Appendix B for the full list of variables.
The external validity of this study was positively influenced by the fact that the NAP
network contains a broad variety of companies in size and type. With the process industry
being the binding factor, all NAP contact persons within the joining companies were
invited to participate in the study. Investigating the respondents most recently completed
project increases the validity of the respondents answers (the project is fresh in their
memories). Although formally current results cannot be generalized outside the NAP
network, with care they can be generalized broader than the Dutch process industry as long
as the projects in that other industry have similar characteristics as the projects included in
this study, e.g. engineering projects, similar complexity elements and comparable front-end
activities in their current project management.
98
Table 5.1: Overview of VIPs / Best practices and selection for inclusion in this study
NAP best practices
IPA VIPs
Constructability review
Technology selection
Design-to-capacity
Value engineering
Integrated project team
Collaborative engineering
Pre-task planning
Constructability review
Technology selection
Design-to-capacity
Value engineering
Constructability
Selected for
inclusion in this
study?
Yes
Yes
Yes
Yes
Senior management
involvement
Design tools
Yes
Yes
Alignment
Yes
Benchmarking and
metrics
Quality management
Lessons learned
Benchmarking
Performance management
Knowledge management
Process safety management
Process simplification
Process reliability modeling
Process synthesis
Process intensification
Zero design
Energy optimization
Facility optimization
Waste minimization
Classes of plant quality
Standard project
specification
Minimum standards &
specifications
Standardized work
processes
Customized standards &
specifications
Team building
Planning for start-up
Pre-project planning
Zero accidents
Techniques
Customizing standards
and specifications
3-D CAD
Yes
Yes
No, too much
focused on
technical content,
not on PM aspects
Process simplification
Process reliability
modeling
Energy optimization
Waste minimization
Classes of facility
quality
Yes
Partnering
Generic engineering
Account management and
controlling
Communication
SHE review
E-commerce
Monetary and recognition
awards to individuals
Predictive maintenance
Materials management
Disputes prevention
and resolution
Change management
Implementation of CII
research
99
Taking a closer look at the ten selected VIPs from Table 5.1, two themes that were very
relevant in literature are not present (see similar observation in Section 2.4.3 when
discussing the findings of Table 2.3 on page 24): risk management (Hillson & Simon,
2007) and stakeholder management (Olander & Landin, 2005). Because of the assumed
importance of these themes and the fact that within companies in the NAP network best
practices (or VIPs) around these themes are available, a VIP on risk management and a VIP
on stakeholder management were added to the ten selected VIPs. An overview of the 12
VIPs considered in the survey is given in Table 5.2. Participants were assumed familiar
with the VIPs, but the explanation was also provided in the survey.
Table 5.2: Explanation of VIPs considered in the survey
VIP (Value
Improving
Practice)
Description
Project team
building
Technology
selection
A systematic process to select the best technology options that meet the
business objectives and improve competitive advantage.
Constructability
review
Designto
capacity
Analysing the design to ensure that the facilities can be built in a manner
that minimizes construction cost while maintaining standards of safety,
quality and schedule reduce costs/time.
Evaluating the maximum capacity of each major piece of equipment, action
is taken to reduce unnecessary excess capacity that is identified (scope
related).
Value
engineering
Operations
implementation
planning
Goalsetting and
alignment
Identifying the goals and opportunities for the project and aligning these
with the parties involved.
Risk
management
A process that results in the identification and response planning for risks to
the project.
External
benchmarking
Project quality
control
Lessons learned
Stakeholder
management
These VIPs were surveyed with 4 questions per VIP. We asked how much effort was spent
in application of the VIP (none, little, substantial), how the amount of application was
perceived (too little, sufficient, too much), whether the VIP was beneficial to the project
100
outcome (strongly agree to strongly disagree) and whether the activity was a burden to
apply in the project (strongly agree to strongly disagree).
Next to these VIPs, we included in the survey also statements on relevant front-end
activities that resulted from the exploratory case studies in Chapter 3, see Table 5.3. The
survey items were clustered around five themes. Except for the theme contracting, the
themes correspond to one of the earlier identified VIPs. Why then would we include both
VIPs and these other relevant front-end activities? The questions about the application of
the VIPs are more process oriented, whereas the statements on the other front-end
activities are more specific and often more activity oriented. Also, todays VIPs are the
normal front-end activities of tomorrow. In fact we ask for different things and look for
complementary information. Since the majority of the themes correspond, though, this
two-sided approach contributes to the internal validity of the survey.
Table 5.3: Other front-end activities considered in the survey (based on Chapter 3)
Front-end theme
Surveyed items
Late entry of parties
Social team building activities
Presence of necessary disciplines
Selection of project manager
Influence of project manager on human resourcing
Alignment of project goals
Active monitoring of project goals
Late scope changes
Intervention and co-operation between project manager
and steering committee
Intervention and co-operation between project manager
and (sub)contractors
Project meetings
Contracting
Contract type
Risk management
These front-end activities were surveyed in the form of statements to be answered on a 5point Likert scale (strongly agree to strongly disagree, see Table 7.6 on page 145 for the
exact statements). The statements were formulated in different directions, meaning
agreement could sometimes be seen as positive for the project (e.g. the business and the
project team had the same goals in mind) or negative (e.g. more social team building would
have been beneficial to the project). This was done in order to keep the interviewee
thinking about the answer and to prevent habituation (Verschuren & Doorewaard, 1999).
5.2.3 How did the project perform?
Several studies have been done on how to define the success of a project (Arkesteijn, 2009;
Balachandra & Friar, 1997; Shenhar, 2001). One project might be successful for one
stakeholder and at the same time very unsuccessful in view of another stakeholder.
Following our discussion in Section 2.4.2, the current study was mainly interested in the
managerial project performance and hence a rather narrow definition of project
performance was used, mainly focused on the traditional measures of project performance.
Good project performance was defined as delivering the project with sufficient quality,
with less than 10% budget overrun and with less than 10% schedule overrun (with respect
to the budget and schedule agreed at the final investment decision). Based on this
101
The survey was designed to be completed in about 30 minutes. This turned out to be rather
optimistic: only 5 respondents completed the survey within the targeted 30 minutes. More
than half of the respondents completed the survey within one hour. About 20% of the
respondents needed even more than 90 minutes. Beforehand, we informed the respondents
that the survey would need about 30 minutes for completion. The respondents who did not
complete the survey probably became disappointed when it took much more time than
expected and thus did not complete the survey (Peytchev, 2009).
However, in case of correlations between on the one hand project complexity and project
performance and on the other hand front-end activities and project performance, one could
carefully assume that project performance is influenced by project complexity and/or frontend activities because of the time evidence argument and because we know from literature
the importance of both on the project result. For the various analyses in Chapter 6 and 7,
also non-parametric tests are used, described in more detail in the respective chapters.
Figure 5.2: Years of work experience (left) and experience as project manager (right)
The majority of the respondents (37 out of 67) were the project manager of the project
under investigation (55%). There were 18 team members (27%) and 12 business
representative (18%). In case the respondents indicated they had several roles in the project,
they were counted for the most influential role (i.e. project manager above business
representative above team member).
104
The respondents were asked about their involvement in the different project phases. In line
with the first four phases as described in the handbook of project-based management
(Turner, 2008), the following project phases were distinguished:
1. Project proposal / Initiation: 25 respondents were not involved, 42 were involved.
2. Project design / Development: 14 respondents were not involved, 53 were
involved.
3. Project execution: 10 respondents were not involved, 57 were involved.
4. Project commissioning / close-out/handover: 26 respondents were not involved, 41
were involved.
In total 24 respondents were involved in all project phases.
Also the companys role in the project was asked for. There were 22 project owner
organizations, 33 managing or engineering contractors and 5 subcontractors amongst our
respondents. The remaining 7 companies were both owner and (managing) contractor. In
our analysis, we took together the 33 managing or engineering contractors because of the
limited number of data points in a large number of categories in case we would distinguish
them (6 managing contractors, 13 engineering contractors and 14 managing & engineering
contractors).
5.4.2 Project characterization
The capital expenditure of the projects largely ranged between 10k Euro and 7500M Euro.
Also the planned project duration ranged considerably between 4 months and 120 months.
The petro-chemical industry, including offshore, mining and (fine-)chemicals, was the
predominant sector in which the projects were executed: 39 out of 67 projects (58%). There
were 12 projects from the pharmaceutical / manufacturing sector (18%). Nine projects came
from the energy sector (13.5%) and seven projects came from the civil / construction sector
(10.5%).
The majority of the projects was characterized as a design / engineering project (28 out of
67, 42%) or a construction project (25 out of 67, 37%). Another 12 (18%) projects were
characterized as design / engineering as well as construction projects. The project sample
contained one maintenance project and one consultancy project (together 3%).
In theory, two persons could have responded in our survey referring to the same project.
Comparing crucial project characteristics (project duration, project budget, sector and type
of project) no overlapping answers could be found and hence it is assumed that the sample
contains 67 different projects.
5.4.3 Project driver(s)
Respondents were asked about the extent to which the project was driven by cost, schedule,
quality and other factors or constraints. Answers could vary between not at all, little,
substantially or completely. Respondents could indicate more than one driver. Looking at
the highest scores, the completely answers, the most important project driver in the
projects in our sample is quality (28 projects), closely followed by schedule (21 projects)
and to a lesser extent cost (15 projects), see Figure 5.3. However, when including
substantially in the analysis there are hardly any differences between these drivers: 62 out
of 67 projects are at least substantially driven by cost, 60 projects are at least substantially
driven by quality and 54 projects are at least substantially driven by schedule.
105
106
107
108
Chapter 6
Evaluating project complexity
Part of this work was presented at the IPMA World Congress 2010 (Bosch-Rekveldt, Mooi,
Bakker, & Verbraeck, 2010b)
The TOE framework to grasp project complexity consists of 50 elements, of which, as a
starting point, 15 elements were assumed to contribute to technical complexity, 21 elements
to organizational complexity and 14 elements to environmental complexity (Chapter 4). To
evaluate the newly developed TOE framework, the NAP survey contained several questions
to score the individual elements of the TOE complexity framework (see Appendix C). The
in-depth evaluation of the TOE complexity framework and the investigation towards
relations between project complexity and project performance is presented in the current
chapter.
This chapter contributes to answering the following research questions (sub-questions 3 and
7 of Chapter 1):
3. How does project complexity influence project performance?
7. How can a framework to grasp project complexity be used to improve project
performance?
To answer these main questions, several sub questions were defined:
a) To what extent do the elements of the complexity framework relate to project
performance?
b) To what extent do the elements of the framework relate to each other?
c) To what extent do the elements of the TOE complexity framework relate to
practitioners perceptions of project complexity?
d) What is the opinion of potential users on future application of the TOE
framework?
e) How can we make an aggregated framework to characterize project complexity?
After giving some general analysis notes (Section 6.1), correlations between project
complexity and project performance are calculated (Section 6.2). Next, the survey results
with respect to the TOE elements are evaluated and related to the project complexity in the
different categories as perceived by the participants (Section 6.3). Completeness of the
TOE framework is discussed in Section 6.4. In Section 6.5, the practitioners opinions
about applying a TOE-like framework are presented. To extend usability of the framework,
an aggregation of the TOE elements into a limited number of categories is proposed in
Section 6.6.
109
project
complexity
and
project
Before diving into detailed analysis of all separate elements of the TOE complexity
framework, first the presence of correlations between project performance and complexity
on high level was investigated. For this first analysis the highest level of the TOE
framework (see Section 6.6 for the calculation of the T, O and E scores) was used, only
distinguishing technical complexity, organizational complexity and environmental
complexity.
Table 6.1 shows significant relationships between project performance and technical
complexity (rs = -.401, p = .003) and between project performance and organizational
complexity (rs = -.308, p= .023). A weaker, hardly significant correlation was found
between environmental complexity and project performance (rs = -.221, p=.109).
110
Project
performance
Correlation
strength
(rs)
Sign.(p)
Technical
complexity
-.401**
.003
54
Organizational
complexity
-.308*
.023
54
Environmental
complexity
-.221
.109
54
Var2
Meaning of
correlation
Increased technical
complexity decreases
project performance
Increased
organizational
complexity decreases
project performance
Increased external
complexity decreases
project performance
The presence of these correlations, albeit with a low strength, suggests that increased
project complexity (technical, organizational, environmental) indeed decreases project
performance.
As a next step, correlations between project complexity and project performance were also
investigated on element level. Of the 50 elements of the complexity framework, 8 elements
showed a significant (negative) correlation with project performance, see Table 6.2.
Obviously one would expect negative correlations: complexity generally is assumed to
decrease project performance. This was confirmed by our research findings.
Table 6.2 shows the importance of particularly unaligned goals, unclear goals and
incompatibility of PM tools and methods for the chance of successful project delivery. The
strongest correlation (strength: moderate) was found between unaligned goals and project
performance (rs=-.492, p=.000): the absence of goal alignment significantly decreases
project performance. Weak correlations on a 0.01 significance level were found between
project performance and unclear goals (rs=-.355, p=.008) and incompatibility of different
PM methods / tools (rs=-.367, p=.007). On a lower significance level, weak correlations
were found between project performance and uncertainties in scope (rs=-.287, p=.037) and
uncertainties in methods (rs=-.276, p=.044); stressing the importance of managing
uncertainties as much as possible. Also resources and skills scarcity decreases project
performance (rs=-.292, p=.032) as well as interface problems between different disciplines
(rs=-.325, p=.016). Finally, the lack of company internal support decreases project
performance (rs=-.287, p =.036).
The absence of significant correlations between the other elements of the TOE framework
and project performance does not indicate these elements do not all influence the project
performance. In every particular project, specific complexity elements might have played a
role. However, across all projects in the current dataset, these were not seen to significantly
correlate to project performance.
111
Var2
Correlation
strength (rs)
TG2: unaligned
-.492**
goals
TG3: unclear
-.355**
goals
TS2:
uncertainties in
-.287*
scope
TT4:
uncertainty in
-.276*
methods
OS2:
incompatibility
Project
-.367**
of different PM
performance
methods / tools
ORE2:
resources and
-.292*
skills scarcity
ORE5:
interfaces
between
-.325*
different
disciplines
ES5: lack of
company
-.287*
internal support
*Correlation is significant at 0.05 level (2-tailed)
** Correlation is significant at 0.01 level (2-tailed)
6.3 Correlations
complexity
between
Sign.(p)
.000
53
.008
54
.037
53
.044
54
.007
53
.032
54
Meaning of correlation
Unaligned goals decrease
project performance
Unclear goals decrease
project performance
Uncertainties in scope
decrease project
performance
Uncertainty in methods
decreases project
performance
Compatibility problems
in PM methods / tools
decrease project
performance
Resources and skills
scarcity decreases project
performance
.016
54
Interface problems
between different
disciplines decrease
project performance
.036
54
element
scores
and
perceived
To measure the perceived complexity of the project, respondents were asked to give their
opinion on the following propositions:
- Looking back at this project, I would consider it technically complex,
- Looking back at this project, I would consider it organizationally complex,
- Looking back at this project, I would consider it environmentally complex.
Answers had to be given on a Likert scale from strongly disagree via disagree, neutral,
agree to strongly agree and do not know. The do not know answers were treated as
missing values. Results are given in Figure 6.1. The respondents agreed the least with the
proposition about the environmental complexity of the project. The respondents agreed
most with the proposition about the organizational complexity of the project. Note that our
respondents predominantly had a background in science or engineering (61 out of 67). With
their technical background, they might consider environmental complexity as something
that is not their cup of tea, or not in their daily experience. The organizational
complexities worry them more than the technical complexities, for which they are
educated to deal with. Assuming that relational approaches help in dealing with complexity,
they seem to follow the traditional school of project management in which engineering
approaches prevail (Lehmann, 2010), in contrast to the renewal school of project
management where relational approaches dominate the management style.
112
35
30
Looking back at this project, I would
consider it technically complex
Count
25
20
15
10
5
0
Strongly
disagree
Disagree
Neutral
Agree
Stronly Agree
Figure 6.1: Survey results: perceived complexity (N=67 for T and O, N=66 for E)
Inter-correlations between technical (T), organizational (O) and environmental (E)
perceived complexity are given in Table 6.3. Weak inter-correlations were found: an
increase in perceived technical complexity or perceived environmental complexity
coincides with an increase in perceived organizational complexity. This could indicate how
respondents interpret organizational complexity: both technical complexity and
environmental complexity seem to have implications for the organizational complexity in
their view. E.g. an element that contributes to either technical or environmental complexity
also contributes to the organizational complexity. Note that the (predominantly technical)
background of the respondents could cause a certain bias here.
Based on these results, it seems that respondents scored also consequences of project
complexity, whereas we intended to find causes for project complexity. Their hindsight
perception of project complexity seems not necessarily limited to the causes of project
complexity, but also includes the consequences (or implications) of project complexity.
Table 6.3: Inter-correlations for the perceived complexity scores for T, O and E
complexity
Perceived
technical
complexity
Perceived
technical
complexity
Correlation Coefficient
Perceived
organizational
complexity
Correlation Coefficient
Perceived
environmental
complexity
Correlation Coefficient
1.000
Sig. (2-tailed)
N
67
Perceived
Perceived
organizational environmental
complexity
complexity
.320**
.190
.008
.126
67
66
1.000
.287*
Sig. (2-tailed)
N
.020
67
66
1.000
Sig. (2-tailed)
N
** Correlation is significant at the 0.01 level (2-tailed)
* Correlation is significant at the 0.05 level (2-tailed)
66
113
Control variables
From literature (Howell et al., 2010) and the case study results of Chapter 3, it was
suggested that the following factors could influence the respondents view on the projects
complexity:
- project size,
- role of the respondent in the project,
- respondents experience,
- project performance (e.g. the extent to which cost and/or schedule estimates were met).
Whether the perceived complexity indeed was influenced by (one of) these before
mentioned variables, was tested using Spearmans correlation. Only one significant
correlation was found: meeting the cost estimate was shown to coincide with perceived
organizational complexity (rs=-0.337, p=0.01), indicating a better score for meeting cost
estimates indeed correlated to a lower perceived organizational complexity. Since no
significant correlations with the perceived technical complexity and perceived
environmental complexity were found, however, for the remainder it was decided to only
look at bi-variate correlations between the TOE elements and perceived complexity. When
significant correlations between a certain control variable and all aspects of perceived
complexity would have been found, the calculation of partial correlations (e.g. controlling
for a particular variable) could have been considered.
The measure of perceived complexity
How can we value the measure of perceived complexity in the survey results? Next to the
proposition questions directly related to the perceived complexity in the three separate
fields (T, O and E), another survey question was related to perceived complexity. That
question asked for factors significantly endangering the project objectives in the different
subcategories under T, O and E. Correlations of these answers to the perceived complexity
showed merely expected (nearly) significant relations with perceived project complexity in
the different aspects, see Table 6.4. The filled cells indicate the expected significant
relations.
Four out of the fourteen subcategories of complexity did not show any significant relation
to the perceived complexity scores:
- Project tasks issues
- Project size issues
- Stakeholder issues
- Project location issues
The absence of significant correlations here could indicate the absence of these issues in the
sample projects, but also misinterpretation of the related question(s). An absence of issues
played a role for the tasks issues (occurrence in only 6 responses), size issues (occurrence
in only 7 responses) and location issues (occurrence in only 6 responses). Stakeholder
issues were however present in 20 responses. For the stakeholder category as well as the
project location category, an interpretation problem of environmental in perceived
environmental complexity might play a role, which will be investigated in detail when
evaluating all individual TOE elements later in Section 6.3.3.
114
Perceived
technical
complexity
.349**
.004
67
.230
.062
67
-.035
.776
67
.371**
.002
67
.479**
.000
67
.048
.702
67
.023
.856
67
.032
.799
67
-.090
.468
67
.095
.444
67
-.183
.139
67
.017
.892
67
.034
.787
67
.026
.834
67
Perceived
organizational
complexity
.413**
.001
67
.180
.145
67
-.017
.889
67
.119
.336
67
.312*
.010
67
-.001
.991
67
.232
.059
67
.238
.052
67
.312*
.010
67
.218
.076
67
.108
.384
67
.143
.248
67
.288*
.018
67
-.066
.596
67
Perceived
environmental
complexity
.128
.306
66
.081
.519
66
.003
.980
66
.137
.274
66
.087
.485
66
-.128
.307
66
-.033
.794
66
.169
.174
66
.172
.167
66
.242
.051
66
.016
.896
66
.074
.554
66
.237
.055
66
.347**
.004
66
Table 6.4 also shows that perceived organizational complexity coincides with issues that
were assumed to correlate to perceived technical complexity or perceived environmental
complexity; confirming the results in Table 6.3 about the (weak) dependency between these
variables. To be more precise: project goal(s) issues and technical risks correlate to both
perceived technical complexity (expected) and perceived organizational complexity. This
indicates that, despite the assumed and confirmed link with perceived technical complexity,
project goal(s) issues and technical risks would also have implications for organizational
115
complexity (both occurred in 11 of the 67 projects). Trust issues remarkably correlate with
perceived environmental complexity, next to the expected correlation with perceived
organizational complexity, however there were only 13 projects in which trust issues did
play a role (out of the total of 67). The same holds for market conditions: correlations to
both perceived environmental complexity (expected) and perceived organizational
complexity are found, but only in 12 projects market conditions caused complexity in the
project.
On the one hand, the significant results in Table 6.4 give some more confidence in the
measure of perceived complexity as such, but on the other hand, some more data could
have strengthened these insights and better explained the presence and absence of certain
relations.
TOE elements and perceived complexity
To thoroughly evaluate the TOE framework, Spearmans correlations were calculated
between all 50 TOE elements and the perceived complexity (technical, organizational,
environmental), see results in Appendix D. As suggested before, the measure of perceived
complexity is not necessarily limited to the causes of project complexity, but most
probably also includes the implications or consequences of project complexity.
Only in case the respondents would have interpreted our question as being related to the
cause(s) of project complexity, we could hypothesise that all T elements would show a
significant relation with the perceived technical complexity, all O elements would show a
significant relation with the perceived organizational complexity and all E elements
would show a significant relation with the perceived environmental complexity. In that case
we would test the distinguishing capacity of the TOE framework. However, clearly
respondents felt the organizational implications of project complexity and tended to
consider their project organizationally complex, as a result of (in our view) more technical
and/or environmental complexity elements. So the correlations that we found actually
indicate how several causes of project complexity are perceived by the respondents. This
is useful to improve project management, since we need to know both cause and
consequence of project complexity in order to better manage it.
As summarized in the subsequent subsections, some of the complexity elements showed the
expected relationships with perceived project complexity. Others showed a significant
relationship with another category than expected beforehand (particularly with
organizational complexity) and some did not show any significant relationship. In the latter
case, the question was raised whether the elements measure was correct, whether the
element just does not contribute to complexity (in the current project sample), whether the
cause versus consequence discussion is influencing the results or whether any respondents
bias was obscuring our data. Correlations of all elements of the TOE framework with the
perceived complexity scores and with each other (if there is reason to do so) are discussed
in the subsequent subsections (Section 6.3.1, Section 6.3.2 and Section 6.3.3). These indepth discussions will lead to a proposal for some modifications to the current framework,
summarized in Section 6.3.4.
In evaluating the elements of the TOE framework and defining which of the obtained data
could be used in the current analysis, the following aspects were considered:
1. Did the element show a significant correlation to the expected form of perceived
complexity?
116
2.
3.
4.
5.
6.
Did the element show meaningful correlations to other elements in the framework?
Did the element show a significant correlation to the non-expected forms of
perceived complexity? If yes, could this be related to the cause versus
consequence discussion?
Could problematic results be related to the current formulation of the survey
question?
Could problematic results be related to the current project sample?
Could problematic results be related to the findings of Table 6.4?
In case the element showed a significant correlation to the expected perceived complexity,
the element data could be used in the current analysis. In case the element did not show a
significant correlation to the expected perceived complexity, but it did show meaningful
correlations to other elements in the framework, and the absence of the expected correlation
with perceived complexity could be explained by the current formulation of the survey
question or the current project sample, the element data still could be used in the current
analysis but the survey question needed reformulation for future use. Moving an element
into another category was considered when the specific element showed a significant
correlation to another form of perceived complexity. However, this was a necessary but not
sufficient condition for movement since the cause versus implication discussion plays a role
here. Only in case additional evidence was available (for example because there were only
meaningful correlations with elements from that other category), an element was moved
from one category into another category.
For some elements, no significant correlations were found with any form of perceived
complexity and there were indications that the specific question was misinterpreted. In such
situations, the obtained data could not be used in the current analysis, and whether or not
the element could stay within the TOE framework differed per situation. Corresponding
survey questions need reformulation for future use. The element results in some cases
indicated a certain overlap with other elements in the current TOE framework, leading to
proposed removal of some of these elements. Appendix D shows the results of Spearmans
correlations between all the T, O, and E elements. The main findings are presented
subsequently.
6.3.1 Correlation of T-elements and perceived complexity
Results for correlations between the T-elements of the TOE framework and perceived
complexity are shown in Table 6.5. This table also indicates whether the complexity
element showed significant and meaningful correlations with other T, O, or E elements,
whether the obtained data can be used in the analysis and whether the element should be
removed from the framework. All details can be found in Appendix D.1.
The goal related elements (number of goals, unaligned goals, unclear goals) show either a
correlation to the expected perceived complexity (technical) or meaningful correlations
with other TOE elements, hence the data can be used in the remainder of the research. The
respondents, however, perceive goal-issues (either related to clarity or to their alignment) as
having implications for organizational complexity. Since we clustered the elements in the
TOE framework in causes for project complexity and not in implications of complexity, no
move of these elements to the O-category was considered.
117
ID
Correlation
with
perceived
complexity?
Elements defined
Meaningful
correlations
with other
TOE
elements?
No
Conclusion
Goals
TG1
Number of goals
Goals
TG2
Unaligned goals
O**
Yes
Use data
Goals
TG3
Unclear goals
Yes
Scope
TS1
Scope largeness
One
Scope
TS2
Uncertainties in scope
Yes
Use data
Do not use
data, remove
element
Use data
Scope
TS3
Quality requirements
T**, E
Yes
Tasks
TT1
Number of tasks
Yes
Tasks
TT2
Variety of tasks
No
Tasks
TT3
Dependencies
between tasks
No
Use data
Tasks
TT4
Uncertainty in
methods
T*
Yes
Use data
Tasks
TT5
Interrelations between
technical processes
No
Do not use
data
Tasks
TT6
O*
Yes
Use data
Experience
TE1
T, O
Yes
Use data
Experience
TE2
Yes
Use data
Risk
TR1
T**, O*
Yes
Use data
Newness of
technology (worldwide)
Lack of experience
with technology
Technical risks
Use data
Use data
Do not use
data
Do not use
data
From the scope related elements (scope largeness, uncertainties in scope, quality
requirements) some show meaningful correlations to other TOE elements, but the element
scope largeness does not, neither to any form of perceived complexity. In the current
question, the scope largeness was operationalised by the number of official deliverables
involved in the project. Apart from the fact that a considerable number of respondents could
not answer this question (27 of the 67), the number of deliverables not necessarily has a
clear relation with the scope largeness: this considerably differs per project / sector. A
better measure for scope largeness is required, but at this stage it seems that scope
largeness is hard to operationalize other than CAPEX, number of resources, number of
different tasks, etc., which are all other elements in the TOE framework. Therefore this
element should be removed from the framework and the obtained data for this element
118
should not be used in the current analysis. The obtained data for the other scope related
elements can be used in the remainder of the study.
Two of the six task related elements (variety of tasks, interrelations between technical
processes) did not show a significant correlation to any form of perceived complexity and
neither to other TOE elements. This most probably is related to the multi-interpretable
corresponding survey questions, which need rephrasing. The obtained data for these
elements should not be used in the current analysis. Another task related element (number
of tasks) which was operationalized in the survey by asking for the number of workpackages in the project, showed meaningful correlations with other TOE elements, but no
link with any form of perceived complexity. This element actually ignores scale differences
of project and, more importantly, what is called a work-package for one respondent, might
be just a task for others. Hence this data could not be used. The other three task related
elements (dependencies between tasks, uncertainties in methods, conflicting norms and
standards) showed either a significant correlation to any form of perceived complexity or
meaningful correlations with other TOE elements. Therefore the data of these elements can
be used in the remainder of the study.
The two experience related elements (newness of technology world-wide, lack of experience
with the technology) showed meaningful correlations to other TOE elements and newness
of technology (world-wide) also showed weak positive correlations to both perceived
technical complexity and perceived organizational complexity. The obtained data for this
element can be used in the remainder of the study.
The element technical risks showed significant correlations to perceived technical
complexity, to perceived organizational complexity and to other TOE elements. The
correlations found all make sense (for example: higher technical risks coincide with higher
quality requirements, more uncertainties in methods, application of new technology, lack of
experience with technology, interface problems, higher organizational risks and occurrence
of interference with the existing site). Hence the obtained data for this element can be used
in the remainder of the study.
6.3.2 Correlation of O-elements and perceived complexity
Results for correlations between the O-elements of the TOE framework and perceived
complexity are shown in Table 6.6. This table also indicates whether the complexity
element showed significant and meaningful correlations with other T, O, or E elements,
whether the obtained data can be used in the analysis and whether the element should be
removed from the framework. All details can be found in Appendix D.2
119
ID
Correlation
with
perceived
complexity?
Elements defined
Meaningful
correlations
with other
TOE elements?
OS1
Project duration
Yes
Size
OS2
Incompatibility of
different project
management methods
and tools
O**, E*
Yes
Size
OS3
Size in CAPEX
Yes
Size
OS4
Size in Engineering
hours
Yes
Size
OS5
O*
Yes
Size
OS6
Yes
Size
OS7
Number of locations
Yes
Resources
ORE1
Project drive
O, E*
Yes
Size
120
ORE2
Conclusion
Use data,
move to Tcategory
Use data
Use data,
move to Tcategory
Do not use
data, remove
element
Use data
Do not use
data, remove
element
Use data,
move to Tcategory
Use schedule
drive data
Yes
Use data
Some
Use data
Yes
Use data
Yes
Use data
Some
Use data
Some
Use data
Yes
Use data
Some
Use data
Yes
Use data
No
Do not use
data
Yes
Use data
Yes
Use data
Yes
Use data
For the size related elements (project duration, incompatibility of different project
management methods and tools, size in CAPEX, size in engineering hours, size of project
team, size of site area, number of locations), we expected more and stronger significant
correlations of these elements with perceived organizational complexity. Particularly,
because in literature, project size, although distinguished from complexity and uncertainty
(Baccarini, 1996), was generally seen as an important contributor to the structural
complexity of the project (Williams, 2002). The reason for not finding stronger
relationships between size elements and perceived organizational complexity in our
research might on the one hand be related to the difficulty of answering the specific survey
questions (for example amount of man-hours, size of site area), but on the other hand also
because of the respondents just do not experience a clear relationship between size and
complexity. Or, similar to examples given by Williams, the complexity of the projects
under investigation simply does not match their size (Williams, 2002), i.e. other aspects in
the project were dominating the complexity perspective (compare for example a large
project without new technology and with a few stakeholders with a small project using new
technology and lots of stakeholders involved).
Note that the absence of a clear correlation between perceived organizational complexity
and size is supported by the findings presented in Table 6.4, where no relation was found
between project size issues causing complexity in the project and perceived organizational
complexity. All size related elements, however, did show meaningful correlations to other
TOE elements. Three of the TOE size elements (project duration, CAPEX and number of
locations) are proposed to move to the T-category because of their clear relation with the
project scope and hence the content of the project. Except for size in engineering hours and
size of site area, which turned out to be too difficult to assess for most of the respondents
and can be removed from the framework, the data for all size related elements can be used
in the remainder of this study.
The elements related to resources (project drive, resource and skill scarcity, lack of
experience with parties involved, lack of HSSE awareness, interfaces between different
disciplines, number of financial resources, contract types) generally showed a significant
correlation to perceived organizational complexity. Those who did not have such
significant correlation to perceived organizational complexity did show meaningful
correlations with other TOE elements. Project drive was measured by cumulating the scores
for the drive in cost, schedule, quality and other (indicated by respondent), and these scores
might have cancelled out each-other. A more detailed analysis into these separate measures
showed that from these separate measures, only the schedule drive has a weak, hardly
significant, positive correlation to the perceived organizational complexity. Hence the
project schedule drive will be considered rather than project drive. The survey question
related to the element contract type mixed the type of contracts and the number of contracts
and in future, this element should focus on the number of contracts to be managed,
regardless of contract type. The data for all resources related elements can be used in the
remainder of this study.
The project team related elements (number of different nationalities, number of different
languages, co-operation with JV partner, overlapping office hours) showed significant
correlations to perceived O or E complexity and/or meaningful correlations with other TOE
elements, except for the element overlapping office hours. This element was clearly
misunderstood by the respondents. The obtained data for this element should not be used in
121
the current analysis, but the element should stay in the complexity framework. The data for
the other project team related elements can be used in the remainder of this study.
The trust related elements (lack of trust in project team, lack of trust in contractor) showed
no significant correlation to any perception of complexity, but meaningful and significant
correlations were found with other TOE elements. For trust we know different views exist,
dependent on the role of the respondent (Pinto, Slevin, & English, 2009). The absence of a
correlation between trust (in either project team or contractor) and perceived organizational
complexity might also be explained by the fact that the majority of the companies had
experience with the involved parties and it is likely that they will not start working again
with parties (persons) which they do not trust. In other words, at the beginning of a project,
trust is not an issue, which might however change during the project. The survey did not
cover this: the trust question in the survey was focused on trust before the project started.
This explanation is supported by the weak correlation found in Table 6.4 between trust as a
factor endangering the project outcome and perceived organizational complexity. Because
of the relevant correlations with other TOE elements, the data can be used in the remainder
of this study.
The element organizational risk shows a moderate positive correlation to perceived
organizational complexity. Also several significant weak to moderate positive correlations
with a lot of other elements of the TOE framework are found, not limited to the Oelements. Higher organizational risks coincide with more misalignment in goals, unclarity
of goals, more uncertainty in methods, more conflicting norms and standards, more
technical risks, compatibility issues of project management methods and tools, larger
CAPEX, unavailability of resources and skills, interface problems between different
disciplines, varied stakeholders perspectives, higher dependencies on other stakeholders
and higher political influence. The high number of correlations of the element
organizational risk with the other elements of the TOE framework shows the general
interconnection between risk and complexity which might direct the future use of the
framework. The obtained data for this element can be used in the current analysis.
6.3.3 Correlation of E-elements and perceived complexity
Results for correlations between the E-elements of the TOE framework and perceived
complexity are shown in Table 6.7. This table also indicates whether the complexity
element showed significant and meaningful correlations with other T, O, or E elements,
whether the obtained data can be used in the analysis and whether the element should be
removed from the framework. All details can be found in Appendix D.3
Note that only a few correlations with perceived environmental complexity are found. On
the one hand, this might be related to an erroneous interpretation of environmental
complexity, i.e. in terms of protection of the environment / global warming issues /
environmental activists and not in terms of external, surrounding etc. This suggestion is
supported by the findings in Table 6.4 where issues related to two of the four Esubcategories are not correlating at all to perceived environmental complexity (stakeholder
issues and project location issues). On the other hand, project managers in general might
have less feeling for environmental aspects: the technical part they were educated in, the
organizational part is the part they are facing during their management tasks and the
environmental aspects are further away from their daily experience (although projects face
environmental influences continuously!). Finally, also the project sample might play a role.
Lets investigate this in some more detail.
122
ID
Correlation
with
perceived
complexity?
Elements defined
Meaningful
correlations
with other
TOE
elements?
Conclusion
Stakeholders
ES1
Number of
stakeholders
Yes
Use data
Stakeholders
ES2
Variety of
stakeholders'
perspectives
O**
Yes
Use data
Stakeholders
ES3
Dependencies on
other stakeholders
T*, O**
Yes
Use data
Stakeholders
ES4
Political influence
T* (neg)
Yes
Use data
Stakeholders
ES5
Lack of company
internal support
Yes
Use data
Stakeholders
ES6
Required local
content
Some
Use data
Location
EL1
Interference with
existing site
Yes
Use data
Location
EL2
Weather conditions
Yes
Use data
Location
EL3
Remoteness of
location
Yes
Use data
Location
EL4
Lack of experience
in the country
Yes
Use data
Market
conditions
EM1
Internal strategic
pressure
No
Do not use
data
Market
conditions
EM2
Instability project
environment
O, E
Yes
Use data
Market
conditions
EM3
Level of competition
Yes
Use data
Risk
ER1
Risks from
environment
E**
No
Use data
project; i.e. external stakeholders. All stakeholder elements did show meaningful
correlations with other TOE elements and thus all obtained data can be used in the
remainder of the study.
None of the location related elements (interference with existing site, weather conditions,
remoteness of location, lack of experience in the country) does clearly correlate to
perceived environmental complexity, but two of them do correlate to perceived
organizational complexity. The absence of correlations with perceived environmental
complexity might be caused by problems in interpreting perceived environmental
complexity. All location related elements, however, do have meaningful correlations with
other TOE elements. Hence the data obtained for these elements can be used in the current
analysis.
From the elements related to market conditions, the element internal strategic pressure
showed neither correlation to any perception of project complexity, nor meaningful
correlations with other TOE elements. The data for this element therefore should not be
used. The element instability of the project environment showed positive correlations to
both perceived organizational complexity and perceived environmental complexity.
Besides, there were meaningful correlations with particularly other E-elements. The
obtained data can be used in the current analysis. The element level of competition does not
correlate to any perception of project complexity, but it shows weak positive correlations to
other TOE elements (such as number of locations, interfaces between different disciplines,
number of stakeholders and the instability of the project environment; e.g. more
competition coincides with more locations, more interfaces, more stakeholders and a less
stable project environment). Because of these meaningful correlations, the obtained data
can be used in the current analysis.
Finally, the element environmental risk shows a positive correlation to perceived
environmental complexity and no meaningful relations with any other element from the
TOE framework. For the elements technical risk and organizational risk, multiple
correlations with other TOE elements were found and this was also expected for the
element environmental risk. In case people misunderstood environment, a relation can be
found between environmental risk and perceived environmental complexity (which was the
case), but not with the other E-elements where environment is not explicitly mentioned.
The current element potentially measures only a subset of our intended environmental
complexity but still the obtained data can be used in the current analysis.
6.3.4 Summary of element evaluation & proposal for adaptations to
the TOE framework
Table 6.5 to Table 6.7 present several elements that showed a significant correlation to (the
expected aspect of) perceived complexity. Overall, it is concluded that T-elements as well
as the E-elements sometimes are perceived to be organizationally complex. The analysis
made the framework structure clearer with the T-category focusing on the projects scope,
mostly content related, with the O-category focusing on internal organizational aspects and
with the E-category focusing on the external and organizational aspects with external
origin.
Based on the current analysis, some of the size related O-elements (project duration, size in
CAPEX, number of locations) will be moved to the T-category. These O-elements actually
are strongly related to the project scope and therefore more suited for the T-category.
124
125
New sub-ordering
ID
T
T
T
T
T
O
O
O
T
T
T
T
T
T
T
T
T
O
O
O
O
O
O
O
O
O
O
O
O
Goals
Goals
Goals
Scope
Scope
Scope
Scope
Scope
Scope
Tasks
Tasks
Tasks
Tasks
Tasks
Tasks
Tasks
Risk
Resources
Resources
Resources
Resources
Resources
Resources
Resources
Project team
Project team
Project team
Project team
Project team
TG1
TG2
TG3
TS2
TS3
OS1
OS3
OS7
TE1
TT1
TT2
TT3
TT4
TT5
TT6
TE2
TR1
ORE1
ORE2
ORE3
ORE4
ORE5
ORE6
ORE7
OP1
OP2
OP3
OP4
OS5
Project team
OS2
O
O
O
E
E
E
E
E
E
E
E
E
E
E
E
E
E
T
O
O
Project team
Project team
Risk
Stakeholders
Stakeholders
Stakeholders
Stakeholders
Stakeholders
Stakeholders
Location
Location
Location
Location
Market conditions
Market conditions
Market conditions
Risk
Scope
Size
Size
OT1
OT2
OR1
ES1
ES2
ES3
ES4
ES5
ES6
EL1
EL2
EL3
EL4
EM1
EM2
EM3
ER1
TS1
OS4
OS6
Elements defined
Number of goals
Unaligned goals
Unclear goals
Uncertainties in scope
Quality requirements
Project duration
Size in CAPEX
Number of locations
Newness of technology (world-wide)
Number of tasks
Variety of tasks
Dependencies between tasks
Uncertainty in methods
Interrelations between technical processes
Conflicting norms and standards
Lack of experience with technology
Technical risks
Project schedule drive
Resource & Skills scarcity
Lack of experience with parties involved
Lack of HSSE awareness
Interfaces between different disciplines
Number of financial resources
Number of contracts
Number of different nationalities
Number of different languages
Presence of JV partner
Overlapping office hours
Size of project team
Incompatibility of different project management
methods and tools
Lack of trust in project team
Lack of trust in contractor
Organizational 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
Weather conditions
Remoteness of location
Lack of experience in the country
Internal strategic pressure
Instability project environment
Level of competition
Risks from environment
Scope largeness
Size in Engineering hours
Size of site area
126
Corr.
result
T
O**
O
O
T**, E
T
O
T, O
T
T*
O*
T**, O*
O, E*
O**
O
O**, T*
O*
E
O*
O**, E*
O**
O
O**
T*, O**
T* (neg)
O
O
O, E
E**
-
From the O-category, two elements should be removed (size in engineering hours and size
of site area). Other size related elements (project duration, size in CAPEX and number of
locations) are moved to the T-category. The element project drive will be focussed on the
schedule drive only. The element contract types will be changed into the number of
contracts. The corresponding survey questions of these and the following elements need
reformulation for future use:
- number of different nationalities,
- overlapping office hours,
- lack of trust in project team,
- lack of trust in contractor,
- lack of experience with the parties involved.
From the E-category, the corresponding survey questions of two elements need
reformulation:
- number of external stakeholders,
- variety of external stakeholders perspectives,
- dependencies on external stakeholders,
- internal strategic pressure,
- environmental risk.
Table 6.8 presents the adapted TOE framework. The strikethrough elements (bottom three
lines) should be removed from the framework. The italic lines refer to elements that should
be kept in the framework, but of which currently no meaningful data is available for further
analysis.
127
Table 6.9: The most complex elements and their link to the TOE framework
128
129
The other most complex elements that could not directly be linked to current TOE elements
are related to project management flaws; e.g. poor communication and poor co-operation of
team members. At the start of the project, poor communication or poor co-operation does
not really exist: these are not root causes of project complexity. Poor communication, for
example, could be a result of the number of stakeholders involved and poor co-operation
could be a result of lack of trust in the project team.
Based on this analysis, it is concluded that all relevant most complex elements are
included in the current TOE framework.
6.4.1 What is lacking in the TOE framework?
Respondents were also asked to indicate what was lacking in the TOE framework. From the
67 respondents, only 15 respondents indicated there were aspects of project complexity,
relevant in their project, which were not in the framework (sub-) categories. Some of these
15 respondents clearly misinterpreted the question, since they answered: technical,
organizational and/or environmental, and/or one (or more) of the subcategories. The
relevant answers were analysed and an attempt was made to cluster the answers around
certain themes. Four answers were related to contractual / commercial complexities, all
others were just mentioned once, see Table 6.10.
Table 6.10: Aspects of project complexity not in TOE framework in view of
respondents
Aspects mentioned
Theme
Political, commercial
Contractual / commercial
Contractual / commercial
Contractual / commercial
Commercial
Contractual / commercial
Contracts with contractors were already made on Yellow FIDIC1
base; in spite of this the owner of the installation still wants to have a Contractual / commercial
say in execution of the work.
Chosen contract type was a big mistake.
Contractual / commercial
Contractual complexity (liabilities, ability to make profit, ability to
Contractual / commercial
control one's destiny)
The project was executed by/for a recently acquired business unit
Contractual / commercial
Open communication on all levels over and within the categories
Openness
mentioned above.
Organizational: cultural difference, ethics
Ethics
Quality (adequate commissioning, qualification and documentation
Quality
handover to user)
Scope changes
Uncertainty
Timing
Project drive
Authority requirements
Regulations
Pharmaceutical regulations
Regulations
The applied technology; i.e. the process (I see a manufacturing plant
as a process that runs in a technical installation (tech. scope) and its
Process complexity
building and/or other civil (site) envelop
1
Yellow FIDIC: Standard Conditions for electrical and mechanical plants and for building works,
designed by the Contractor
In our view, the majority of the aspects of project complexity in Table 6.10 are actually in
the TOE framework, but on a different level. For example political and commercial are
covered in elements such as political influence, level of competition, and internal strategic
pressure. Complexity related to the contracts is included in the element number of
130
contracts. Note that this element was redefined earlier in this chapter from contract types to
number of contracts since for managing the contract the number of contracts to manage
seemed more important than the contract type per se. Aspects of contract type are also
covered (implicitly) in elements such as presence of JV partner and lack of trust in project
team / lack of trust in contractor. The case of a wrongly chosen contract type, in fact is a
management flaw (that adds to complexity). Potentially, adding an additional element on
contracting (type of contract) to the TOE framework could be considered in future.
The aspect in Table 6.10 about communication on all levels over the complexity elements
in fact is one of the foreseen applications of the TOE framework; see Section 6.5 and
Section 9.5. The aspect related to cultural differences and ethics is currently only covered in
the number of different nationalities and languages involved. Additional research would be
needed to consider the importance of including the ethical side of projects (for example in
terms of social implications) in the complexity framework. The quality-related aspect
points in the direction of quality of the different project phases, hence again a management
flaw. The aspect scope changes as suggested by a respondent, is not part of the TOE
framework on purpose. In our view scope changes indeed could contribute to project
complexity, but the actual complexity cause is not scope change. The TOE framework
contains for example the elements uncertainties in project scope, uncertainty in methods,
variety of stakeholders perspectives, which could all cause scope changes. The aspect of
timing could be translated to the element project schedule drive. If timing was meant
related to market conditions, the corresponding TOE elements could be unstable project
environment, or level of competition. Aspects that at first sight also are not part of the
current TOE framework are authority requirements and industry specific regulations.
The element conflicting norms and standards, however, was meant to cover these aspects in
broadest sense. Also process complexity seems not to be in the current TOE framework, but
it is covered in dependencies between tasks and uncertainties in methods.
So, based on these survey results, it was concluded that the current TOE framework
includes the most relevant aspects contributing to project complexity, for typical projects
performed by members of the NAP network.
131
30
Count
25
20
15
10
5
0
Strongly
disagree
Disagree
Neutral
Agree
Stronly Agree
Count
30
25
20
15
10
5
0
Strongly
disagree
Disagree
Neutral
Agree
Stronly Agree
Figure 6.3: Answers related to the benefit of applying a complexity framework and its
foreseen use to create awareness about project complexity amongst its stakeholders
Finally, the use of a complexity framework in different project phases was asked for
(Figure 6.4). The majority of the respondents agreed with the benefit of applying the
framework in different phases (43 responses agreed or strongly agreed; only one response
disagreed). Whether a complexity framework could also be applied during project
execution is not clear from this survey: their answers on the proposition about applying the
framework only prior to project execution were very diverse. There were 24 respondents
(strongly) agreeing and 26 respondents (strongly) disagreeing, the others answered
neutral. However, we know the complexity of a project changes over the different project
phases, including project execution (Chapter 3), and we would suggest that the benefit of
applying a complexity framework is not limited to the early project phases.
132
40
35
Count
30
25
20
15
10
5
0
Strongly
disagree
Disagree
Neutral
Agree
Stronly Agree
found or a meaningful correlation with perceived complexity (see Table 6.8). We used the
updated version of the TOE framework, resulting from the earlier analysis in this Chapter.
To check the reliability of scales, often the Cronbachs Alpha is calculated, which is a
measure for how well the underlying construct is consistently measured over a number of
scale items (Field, 2009). To investigate the reliability of the adapted TOE framework in
Table 6.8, the Cronbachs Alpha was calculated for the T-, the O- and the E- subcategories
(Table 6.11).
Table 6.11: Reliability statistics
Technical complexity
Organizational complexity
External complexity
0.666
0.669
0.561
N
48 (19 missing)
41 (26 missing)
39 (28 missing)
The calculated is rather low for each of the categories, which indicates that a diversity of
constructs is being measured within each of the categories. On the other hand, the value of
is still high enough to have some confidence in the usefulness of these categories.
Actually, this calculation shows that the concept of project complexity indeed includes
various and very different indicators. Just measuring the total complexity or the three
dimensions of complexity by one indicator therefore has only limited use: the concept of
project complexity seems best described by numerous complexity elements.
However, this does not imply that aggregated scores for T, O and E-complexity cannot be
meaningful. For example, the T-elements do contribute to the T-complexity and one could
argue that in case more T-elements receive a higher score, also the T-complexity overall
increases (although the individual T-elements measure different aspects of T-complexity).
The simplest way of calculating an aggregated score is summing the scores for the elements
in the T, O and E-category respectively. Calculating the mean value, instead, would provide
artificially high results since missing values would be excluded.
Per category (T, O and E), the sum of the element scores was calculated. To obtain some
confidence in the aggregated scores, the correlation results of these aggregated scores with
the different perceptions of complexity are given in Table 6.12.
Table 6.12: Correlations between aggregated complexity scores and perceived
complexity
Technical
Complexity
Organizational
Complexity
External
Complexity
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Perceived
technical
complexity
.416**
.000
67
.174
.160
67
.051
.683
67
Perceived
organizational
complexity
.568**
.000
67
.575**
.000
67
.519**
.000
67
Perceived
environmental
complexity
.166
.183
66
.114
.363
66
.266*
.031
66
From Table 6.12 it is concluded that all complexity categories do correlate with the
expected form of perceived complexity (grey filled cells on the diagonal), but with different
strengths and significance levels. Besides, technical complexity and external complexity
also show a significant correlation to perceived organizational complexity (rs = .568,
p=.000 and rs=.519, p=.000 respectively) again suggesting that the organizational
implications of technical complexity and external complexity were recognized by the
respondents. These were recognized next to the pure perceived technical complexity
(rs=.416, p=.000) and pure perceived environmental complexity (rs=.266, p=.031).
Organizational complexity shows a significant correlation only with perceived
organizational complexity (rs = .575, p=.000). For external complexity, the relation with
perceived organizational complexity is considerably stronger than with perceived
environmental complexity, which most probably is related to different interpretations of the
word environmental amongst the respondents.
Based on Table 6.12, one could argue that all comes down to (perceived) organizational
complexity since the strongest correlations were found with perceived organizational
complexity, for each of the three aggregated scores. Why then still distinguishing T, O and
E complexity? Rather than focussing on symptoms or consequences of project complexity,
we would like to focus on the real (and various) causes of project complexity. We fear that
the respondents in answering the questions on their perception of project complexity did
stick to the symptoms of project complexity: a technically complex project might result in
organizational complexity, and also an environmentally complex project might result in
organizational complexity. As a project manager, organizational complexity is what you
face in daily practice. This explains the high correlations of all aggregated forms of project
complexity with perceived organizational complexity. The presence of the significant
relations on the diagonal of Table 6.12 (between all three dimensions of project complexity
and the respective expected forms of perceived complexity) however suggest that the
summed scores for T-, O-, and E-complexity are a meaningful way to characterise the
complexity of the project in the three different dimensions. By definition, these three
aggregated scores do focus on the various causes or sources of project complexity which is
what the framework was designed for.
6.7 Discussion
This chapter showed that the TOE framework to grasp project complexity, originally
developed in Chapter 4 based on literature and the explorative case studies, was thoroughly
evaluated and further developed based on the quantitative data collected with the survey.
More specifically, this chapter contributed to answering sub-questions 3 and 7 from
Chapter 1:
3. How does project complexity influence project performance?
It was concluded that project complexity negatively influences project performance. The
strongest correlations between project complexity elements and project performance
(negative) were found in the areas of goals / scope, uncertainty in methods, incompatibility
of PM methods / tools, resources and skills scarcity, interfaces between different disciplines
and a lack of company internal support. Also significant correlations were found between
separate complexity elements and perceptions of complexity, although it was also
concluded that respondents generally probably more focus on project complexity
implications or consequences rather than project complexity causes.
135
136
Chapter 7
Evaluating front-end activities
Parts of this chapter were presented at the PMI research conference 2010 in Washington
(Bosch-Rekveldt et al., 2010a) and at the Xth IRNOP conference in Montreal (BoschRekveldt et al., 2011b)
Now we have developed (Chapter 4) and evaluated the TOE complexity framework
(Chapter 6), this chapter aims to link the projects complexity characterisation, the frontend activities performed in those projects and their performance. So from a more
descriptive perspective of characterizing project complexity, we progress to an action
perspective by investigating what activities were performed in the projects under
consideration and how these activities link to the projects complexity and project
performance.
Because of the exploratory character of our study, we started exploring the high level
relations between project complexity, front-end activities and project performance by
transforming the Chapter 5 data in a 2x2 set-up. In business oriented environments, the 2x2
matrix is considered as a useful analytical tool to support business decisions (Lowy &
Hood, 2004). Often it is helpful to reduce a problem using such a simple 2x2 matrix; the
2x2 approach forces dialectical thinking. In our study, complexity and effort in front-end
activities (low complex projects or high complex projects on the one axis and low effort in
front-end activities or high effort in front-end activities on the second axis). Using this 2x2
set-up, we started exploring possible relations between the variables under consideration.
Next, we performed detailed investigations by evaluating the specific front-end activities
and their possible influence on project performance and not only the simple, direct
relations between specific front-end activities and project performance. As was shown in
Chapter 2, literature suggested a contingency approach in project management (Engwall,
2003; Shenhar & Dvir, 1996; Smyth & Morris, 2007; Williams, 2005). In such an approach
project complexity could be considered as a contingency factor. Whether one could adapt
the front-end development phase to the particular project complexity to improve project
performance, has not been tested quantitatively yet. Therefore this chapter also addresses a
quantitative assessment of these more complex, potential relationships between the three
building blocks of front-end activities, project complexity and project performance. In this
assessment, the newly developed TOE framework was used for the characterization of
project complexity.
137
This chapter addresses the following research questions (sub-questions 4 and 6 from
Chapter 1):
4.
6.
What are the relevant front-end activities to deal with project complexity?
How can contingency theory be used to fit the front-end phase to the complexity of
a project?
To answer these research questions, also the following sub-questions were defined:
a) What are relations between aggregated project complexities, aggregated front-end
activities and project performance, if any?
b) What relations can be found between aspects of project complexity, detailed frontend activities and project performance, if any?
c) How do perspectives on complexity and front-end activities differ with different
respondents roles?
Chapter 7 is structured as follows. First, the high level investigations towards the relation
between project complexity, front-end activities and project performance are presented
(Section 7.1). Next, the typically performed front-end activities are presented (Section 7.2),
followed by the direct relations between front-end activities and project performance
(Section 7.3). The more complex relations between front-end activities and project
performance, in which project complexity acts as a moderating variable, are investigated
using contingency theory in Section 7.4. Subsequently, the significant relationships found
are summarized in Section 7.5. If and how different roles of the respondents have an
influence on the outcomes is presented in Section 7.6. Finally, this chapter is concluded
with discussion on the findings and the managerial implications of the relations found
(Section 7.7).
Similar to the analysis in the previous chapter, the following rule of thumb was applied
for the strength of a correlation: below 0.19 is very low; 0.20 to 0.39 is low; 0.40 to 0.69 is
modest; 0.70 to 0.89 is high and 0.90 to 1 is very high (Cohen & Holliday, 1982).
From the original dataset of 67 projects (Chapter 5), 5 projects were removed because
neither these respondents, nor their company, were actually involved in the front-end
development phase. Based on the previously mentioned definition of project performance
(Section 5.2.3), the 62-project data set contained 19 projects with good project performance
and 31 projects with poor project performance. In this 62-project data set, for 12 projects
data on the project performance was missing, resulting in a 50-project data set with all
information available.
front-end
How project complexity and the amount of effort spent in front-end activities influence
project performance was investigated using a 2x2 set-up. The cumulated project complexity
and the cumulated effort in front-end activities were the independent variables.
Project complexity was operationalized using the updated TOE framework to characterise
project complexity, see Table 6.8 in Chapter 6. All elements scores per dimension were
cumulated to obtain a T-complexity score, an O-complexity score and an E-complexity
score, and cumulated all together they form the total complexity score per project.
138
Mean = 11.13
SD = 1.92
N = 15
Mean = 9.00
SD = 2.79
N = 11
VIP
(little effort)
Mean = 9.50
SD = 3.03
N = 10
Mean = 8.00
SD = 2.93
N = 14
Complexity
(low)
Complexity
(high)
The mean value of the project performance is highest in the group with low complexity and
high VIP effort and lowest in the group with high complexity and little VIP effort; just like
one would expect. Between the groups with little VIP effort, high total complexity and high
VIP effort, low total complexity, non-overlapping 95% confidence intervals were found.
139
From the two-way ANOVA (Corrected model: F(3,46) = 3.508; p=.023) it became clear
that only the complexity showed a significant main effect on the project performance
(F(1,46) = 5.693; p=.021). There was a non-significant main effect of VIP effort on the
project performance (F(1,46) = 2.990; p=.090) and interaction effects (VIP*complexity) did
not play a role.
Whereas one would expect a significant effect of spending effort in value improving
practices, this was not confirmed by our study. This could be related to the fact that only the
amount of application (none little substantial) for 12 VIPs was included in this
cumulated variable, which obviously limits its power. But maybe more important is the fact
that in the current analysis, the complexity of a project was summarized in one single score.
As was argued in Chapter 6, the complexity of a project can and should not be captured in
one single score because of the very different aspects that contribute to it (e.g. technical
aspects, organizational aspects and external aspects). Therefore, in the next subsection the
previous 2x2 analysis was repeated with the three main dimensions of project complexity
(Technical, Organizational and External), instead of the total complexity.
7.1.2 Results for dimensions of complexity, VIP effort and project
performance
Table 7.2 shows the descriptive statistics for the group analysis taking VIP effort and Tcomplexity as factors. The mean value of the project performance is highest in the group
with low T-complexity and high VIP effort and lowest in the group with high T-complexity
and little VIP effort; just like one would expect and little more outspoken than in Table 7.1.
Between the groups with little VIP effort, high T-complexity and high VIP effort, low Tcomplexity, non-overlapping 95% confidence intervals were found. From the two-way
ANOVA (Corrected model: F(3,46) = 4.567; p=.007) it became clear that the T-complexity
showed a significant main effect on the project performance (F(1,46) = 8.619; p=.005).
Now the main effect of VIP effort on the project performance was close to significant
(F(1,46) = 3.821; p=.057). Again the interaction effect (VIP*T-complexity) did not play a
role.
Table 7.2: Descriptive statistics (VIP effort, T-complexity, on project performance)
VIP
(high effort)
Mean = 11.36
SD = 1.86
N = 14
Mean = 8.92
SD = 2.61
N = 12
VIP
(little effort)
Mean = 9.64
SD = 2.91
N = 11
Mean = 7.77
SD = 2.92
N = 13
T-Complexity
(low)
T-Complexity
(high)
Similar results were found for the group analysis taking front-end activities and Ocomplexity as factors (Table 7.3). The groups are only little different and therefore the
mean performance results are similar. Again the highest mean performance is found in the
group with little O-complexity and high VIP effort and the lowest mean performance is
found in the group with high O-complexity and little VIP effort. Between the groups with
little VIP effort, high O-complexity and high VIP effort, low O-complexity, nonoverlapping 95% confidence intervals were found. From the two-way ANOVA (Corrected
140
model: F(3,46) = 4.823; p=.005) it became clear that the O-complexity showed a significant
main effect on the project performance (F(1,46) = 9.424; p=.004). Again the main effect of
VIP effort on the project performance was close to significant (F(1,46)=3.833; p=.056) and
the interaction effect (VIP*O-complexity) did not play a role.
Table 7.3: Descriptive statistics (VIP effort, O-complexity, on project performance)
VIP
(high effort)
Mean = 11.36
SD = 1.82
N = 14
Mean = 8.92
SD = 2.64
N = 12
VIP
(little effort)
Mean = 9.73
SD = 2.83
N = 11
Mean = 7.69
SD = 2.93
N = 13
O-Complexity
(low)
O-Complexity
(high)
For the group analysis taking front-end activities and E-complexity as factors, the outcomes
are less outspoken (Table 7.4). Although the mean value of the project performance is still
highest in the group with high VIP effort and low E-complexity, and lowest in the group
with low VIP effort and high E-Complexity, differences are smaller. All four confidence
intervals overlapped to some extent. The two-way ANOVA analysis did not result in a
significant Corrected model (F(3,46) = 2.089, p=.115); i.e. none of the four groups had a
significantly different mean value. However, the VIP effort showed a significant main
effect on project performance (F(1,46) = 4.165; p=.047).
Table 7.4: Descriptive statistics (VIP effort, E-complexity, on project performance)
VIP
(high effort)
Mean = 11.00
SD = 1.78
N = 13
Mean = 9.46
SD = 2.96
N = 13
VIP
(little effort)
Mean = 8.73
SD = 3.26
N = 11
Mean = 8.54
SD = 2.90
N = 13
E-Complexity
(low)
EComplexity
(high)
Compared to the analysis with the total complexity (Table 7.1), more significant results are
obtained when different dimensions of complexity are distinguished (Table 7.2 to Table
7.4). Looking at Table 7.1 to Table 7.4, in all cases, the project complexity was seen to
significantly influence the project performance. Only in case we distinguished different
dimensions of complexity, also the effort in VIPs became more significant. Still, it seems
that spending effort in VIPs could be relevant: performance scores were in all analyses
higher in case more effort was spent in application of VIPs.
A reason for not finding an overwhelmingly clear effect of VIPs on project performance
could be that this operationalization of front-end activities (a cumulative effort score based
141
on the application of 12 VIPs) is not sufficiently detailed and averages out effects of the
separate VIPs. Also, when aiming to adapt the front-end phase of a project to its specific
complexities, only looking at cumulative effort scores is not enough. Therefore, it is
investigated in more detail what front-end activities particularly could influence project
performance in the next sections.
Burden
Beneficial
Amount
Effort
None
Little
18 19 21 22
16 19 14 21
30
Substantial
39 28
45
34 31 31 30
41 10 43 36
20
Missing
Too little
13 2
15 19 18
13
21
Sufficient
45 49
47
48 37 35 39
39 33 45 44
34
Too much
Missing
11
18 5
Strongly disagree
Disagree
Neutral
15
12
18 11 17 13
14 8
12
19
Agree
35 23
27
22 28 18 29
26 11 37 34
17
Strongly agree
14 8
13
12 2
Missing
15
10
11 13 13 12
Strongly disagree
17 11
18
16 3
Disagree
29 25
26
29 24 22 25
24 10 30 31
21
Neutral
10
12 13 11 10
12 10 11 12
14
Agree
Strongly agree
Missing
15
11 13 12 11
34 7
14
11 13
12 3
15 8
Stakeholder management
21 2
Lessons learned
18 20
External benchmarking
Risk management
Value engineering
Design to capacity
Constructability review
Technology selection
35 7
15
10 9
10
143
Table 7.6: Survey results of questions about the other front-end activities
Numbers of cases in which particular answer was given, N = 62
Grey filled cells are discussed in the text
Strongly
disagree
Disagree
Agree
Strongly
agree
31
15
16
26
11
17
11
22
34
11
41
13
31
13
11
10
24
10
13
26
17
35
10
25
19
12
23
11
14
16
20
15
30
35
13
19
20
19
16
18
Neutral
Missing
145
This finding is more in line with literature suggesting poor application of risk management
in practice (Hillson & Simon, 2007; Papke-Shields, Beise, & Quan, 2010). Our findings
show there is room for improvement in the field of proper and effective application of risk
management.
Further comparing the findings of Table 7.6 with the VIP results in Table 7.5 shows that
while the vast majority of the respondents agrees with the opinion that the business and the
project team had the same goals in mind, still the VIP goal setting and alignment was
applied too little in about one third of the projects. The benefits of the VIP project team
building seem to be recognized in performing a number of the other practices related to
project team building, such as the PM had a say in the resourcing, the team included all
relevant disciplines and the close co-operation between PM and the SC.
Number of
possible
relations
Number of
significant
relations
Percentage of
significant
relations
12+12+16=40
10
25%
Table 7.7 lists the percentage of significant relations found. This percentage of significant
relations of all possible relations should be considerably higher than the used significance
level since the significance level represents the probability of making a Type-I error
(believing there is a genuine effect in the population, when actually it is not there (Field,
2009)). Correlations were considered significant when their significance level was 5% or
better.
Table 7.8 shows significant correlations between front-end activities (VIPs and the other
activities) and project performance, with strengths of low to modest. The four strongest
correlations with project performance (the application of operations implementation
planning, active monitoring of project goals, both modestly correlated to project
performance and the amount of application of project team building and the lack of team
cohesion, both weakly correlating to project performance) were significant on a 0.01 level.
The relatively high strength of the correlation between project performance and the
application of operations implementation planning is interesting since a large number of the
respondents applied it only little and found the amount of application insufficient. Hence
there seems major room for improvement. The same yields for the amount of application of
external benchmarking: often it was not applied but still the sufficient application of
external benchmarking increases project performance.
Several significant correlations with project performance relate to goal alignment /
monitoring. Active monitoring of project goals increases project performance, sufficient
application of goal setting and alignment increases project performance and also goal
alignment between the business and the project team increases project performance.
146
Confirming literature results (Cleland, 1994; van der Merwe, 2002) and empirical research
(Scholten, Mooi, & Wijngaard, 2010), the importance of goal alignment and monitoring is
apparent from our study.
Table 7.8: Significant correlations between project performance and front-end
activities
Var1
Var2
Project
performance
2. Project goals
were actively
monitored
VIP: Amount of
application of goal
setting and
alignment
1. The business and
project team had
the same goals in
mind for this
project
VIP: Amount of
application of
project team
building
6. A lack of team
cohesion
endangered the
project outcome
8. More social team
building would
have been
beneficial to project
outcome
11. Co-operation
with
(sub)contractors
was hampered by
contract type
16. The project
suffered from late
entry of parties
VIP: Application of
operations
implementation
planning
VIP: Amount of
application of
external
benchmarking
Correlation
strength
(rs)
Sign.(p)
.412**
.003
50
.358*
.013
47
.292*
.039
50
.380**
.008
47
-.379**
.007
50
-.315*
.026
50
-.329*
.022
48
-.342*
.015
50
.444**
.001
49
.324*
.044
39
Meaning of correlation
Active monitoring of
project goals increases
project performance
Perceived sufficient
application of goal setting
and alignment increases
project performance
Goal alignment between
business and project team
increases project
performance
Perceived sufficient
application of project
team building increases
project performance
More problems due to a
lack of team cohesion
decrease project
performance
More social team building
decreases project
performance
Co-operation with
(sub)contractors that was
hampered by contract type
decreases project
performance
Late entry of parties
decreases project
performance
Application of operations
implementation planning
increases project
performance
Perceived sufficient
application of external
benchmarking increases
project performance
Also confirming other research (Bakker et al., 2010), several significant correlations with
project performance relate to the project team, in view of the respondents. A sufficient
147
amount of project team building and the lack of team cohesion show a direct relation to
project performance. In view of the respondents, apparently more project team building
enhances team cohesion, thus increasing project performance. The negative correlation
found (more social team building does not contribute to better project performance) can be
explained by the fact that in the majority of projects, team building was already applied
substantially and sufficiently: e.g. there is no room for further improvement. This result
actually shows that more is not always better. The challenge in real project management is
to determine what exactly is the sufficient amount of application, for the particular project.
The importance of timely co-operation using the right contract type, in view of the
respondents, became also clear from Table 7.8: a late entry of project parties decreased
project performance and co-operation that was hampered by contract type also decreased
project performance.
example (Figure 7.1), this would mean that variable B would be a variable indicating
project performance. In order to maximize B, one would have to try to match independent
variable A (front-end activities) to the contingency variable C (project complexity). This
fit between A and C, resulting in high B, is central to contingency theory.
Step 1: Look for direct relationships between the variables under investigation
(front-end activities) and performance (project result).
Step 2: Look for moderated relationships between the variables:
o Step 2a: Look for direct relationships amongst the variables under
investigation (complexity, front-end activities). Relationships found
constitute possible fit(s).
o Step 2b: Test the relationships found in step 2a to determine whether the
possible fit(s) are related with result. If so, a moderated relationship
exists.
Step 3: Check whether the fit found in step 2b causes result. If so, the moderator is
a contingency factor.
hence requiring for instance a longitudinal research design (Donaldson, 2001). Note
however this is different in case the project result is involved, since result simply follows
after front-end development took place and after the project faced a certain complexity. We
should be careful drawing such conclusion because there might be other (uninvestigated)
factors that are determining the project performance.
Step 1 of this framework, the direct correlations with project performance, was already
discussed in Section 7.3. The subsequent subsections will focus on step 2 of the framework:
investigating the moderated relationships. To find these moderated relationships, first
relations between front-end development and project complexity have to be investigated.
These relationships are the possible fit(s). Next, these possible fit(s) will be assessed on
their relation with the project performance. Finally, the outcome of Step 3 of the analysis
framework is discussed. Figure 7.2 indicates where the different relationships are discussed
in Section 7.3 and 7.4.
151
152
Integrally looking at Table 7.9, four front-end activities correlated to two complexity
dimensions. These correlations had different strengths but were in the same direction
(strongest correlation is mentioned first between the brackets):
Perceived amount of application of goal setting and alignment (O, T)
The project suffered from late entry of parties (O, T)
Perceived amount of application of risk management (T, E)
More social teambuilding would have been beneficial for the project (E, O)
This suggests that the dimensions of project complexity (T, O, E), as defined in our
research, are not fully independent, see also Chapter 6. It even might suggest that one form
of complexity is causing another form of complexity, for example technical complexity
leading to organizational complexity. Or even more complicated, that one form of
complexity (T?) requires certain front-end activities (more goal setting and alignment?)
which in turn contributes to another form of complexity (O?). However, in the current
research we cannot conclude on causality in the simple relations between complexity and
front-end activities, let alone the complicated ones.
Concluding this subsection, several significant correlations were found between the frontend activities and the three dimensions of project complexity, which was step 2a of the
analysis framework. The relations show that the respondents often think that more effort is
needed in certain activities, with increasingly complex projects. How this potentially links
to the project performance is presented next.
7.4.4 Subgroup analysis to test for moderated relationships
After establishing the relations between the front-end activities and project complexity in
step 2a, step 2b of the analysis involves the test for fit between the relations of step 2a and
the project result. If (one of) these relations show a fit with project result, a moderated
relationship exists. To test for these moderated relationships, subgroup analysis was used
(Donaldson, 2001). Our relatively small dataset did not allow for another type of regression
analysis.
Subgroup analysis involves breaking down the data into subgroups based on fit or result.
The interpretation of this analysis is based on a simple principle: if a moderated relationship
exists, the associations found in the different subgroups should significantly differ (Bryman
& Cramer, 2009; Donaldson, 2001). In our study, subgroups were defined based on project
performance:
- Good project performance (less than 10% over cost- and schedule estimates, at
least neutral perceived quality score) 19 projects
- Poor project performance (more than 10% over cost- or schedule estimate or less
than neutral perceived quality score) 31 projects
For the subgroup analysis, the front-end variables relating to application of the VIPs, the
sufficiency of the amount of application of these VIPs and the other practices were
included. Note that these are merely subjective variables: the perception of the respondent
is measured, it is not assessed what actually has been done.
Results subgroup analysis
The relationships that were found to be significant in the subgroups are presented in Table
7.10. The total number of possible relations was 240 (40 front-end variables, 3 complexity
variables, 2 subgroups). Only 12 significant relations were found which equals to 5% of the
153
154
155
In the group of projects with poor performance, the strongest correlation was found
between organizational complexity and intervention of the PM in the work of the
(sub)contractors (rs=441, p=.013). In view of the respondents, increased organizational
complexity coincides with regular intervention of the PM in the work of the
(sub)contractors, contributing to poor project performance. In the group of projects with
poor performance, almost all significant correlations were found with organizationally
complex projects, hence indicating that particularly this area (managing the organizational
complexity) needs improvement. In our dataset, significant correlations were found
between organizational complexity and several normal practices related to co-operation
and team building: a lack of team cohesion (rs=.408, p=.023), more social team building
would be required (rs=.403, p=.025), co-operation was hampered by contract type (rs=.374,
p=.046) and regular interventions by the steering committee (rs=.359, p=.047), all of which
would negatively influence project performance. Another theme that is addressed in the
group of projects with poor performance is the perceived importance of goal setting, goal
alignment and active monitoring of project goals. A weak negative correlation was found
between organizational complexity and the perceived amount of goal setting and alignment
(rs=-.368, p=.046): with increasing organizational complexity, the respondents perceived
too little application of goal setting and alignment. Also, with increasing technical
complexity, active goal monitoring was applied less, in view of the respondents (rs=-.385,
p=.033).
Moderated relationships
How to find now the moderating relationships from the findings in Table 7.9 and Table
7.10? In case a moderated relationship exists, the correlation strength of the relation found
in step 2a (Table 7.9) should significantly differ between the subgroups (projects with good
performance, projects with poor performance, Table 7.10). None of the relations found in
step 2a (Table 7.9) were significant in both subgroups (Table 7.10) but also the absence of a
correlation in one of the subgroups does indicate a difference in correlation strength in our
current project sample.
In case a direct relationship existed between the front-end activity and project performance
(step 1 of the analysis framework, Table 7.8), there was no need to look for a moderated
relationship (Bryman & Cramer, 2009; Donaldson, 2001). The presence of this direct
relationship makes it impossible to truly recognize the moderated one. An example of a
direct relationship found by using these criteria is the amount of application of project team
building. This activity was directly correlated to project performance (see Table 7.8), so
there was no need to look for a moderated relationship. In case a correlation was found
between any type of project complexity and front-end activity in step 2a (Table 7.9), no
direct relation between the front-end activity and project performance and in only one of
the subgroups of step 2b (Table 7.10), it was considered a moderated relationship.
The only moderated relationship resulting from this research is between project complexity
and the perceived amount of application of risk management. This activity was not directly
correlated to project performance. However, a relation was found in step 2a between
technical and external complexity and the perceived amount of application of risk
management (see Table 7.9) and again in the subgroup of projects with good performance
in step 2b (see grey rows in Table 7.10).
156
Finally, step 3 of the analysis framework involved testing whether the fit found in step 2b
causes the result. From our data, the only moderators found were the technical and external
complexity. Based on the current data, we cannot conclude that the fit between these
complexities on the one hand and the perceived amount of application of risk management
on the other hand caused the project performance. There were many front-end activities that
were shown to have a direct influence on the project performance in our limited dataset and
hence we cannot claim causality for the moderated relationship.
Although we cannot conclude that project complexity can be considered a contingency
factor in project management, using the contingency approach provided a means to identify
other than just the direct relationships. To be more specific, the results of this research
suggest a relationship between risk management and project performance that is moderated
by the technical and external project complexity. Subsequent research should investigate
whether and how project complexity can be considered a contingency factor for project
management.
with lower sufficiency of application of project team building; e.g. even more
team building is required for organizationally complex projects. Note however that
more social teambuilding not necessarily improves the chance of good project
performance: more is not always better. Whether there is room for improvement
really depends on the actual current amount of application.
- A lack of perceived team cohesion decreases the chance of good project
performance. Since we also found that increased organizational complexity
coincides with more problems due to a lack of team cohesion, it seems important
to achieve team cohesion, particularly for organizationally complex projects.
- Late entry of parties decreases the chance of good project performance. We also
found that increased technical complexity coincides with problems due to late
entry of parties, hence in case of technically complex projects, all measures should
be taken to prevent late entry of parties; e.g. ensure timely involvement of the
relevant parties.
Evidence for these empirical relations between front-end activities, project complexity and
project performance could not be found in literature: at best the relation between only two
of the three factors are described, which shows the added value of this dissertation.
management, project success, and technological uncertainty (Raz, Shenhar, & Dvir, 2002).
In that study, it was concluded that risk management practices were used in only a limited
number of projects at that time, but in case it was applied, it appeared to be related to
project success. They showed that for high-risk projects (high technological uncertainty),
risk management techniques seemed even more useful than for low-risk projects, but in
general, application of risk management was in its infancy. Although their results are
almost 10 years old, our 2009 survey results still show considerable room for improvement
in application of risk management practices. In recent literature, more often prescriptions
are given to project managers on how to manage risk in projects, rather than assess the
relative effectiveness of those prescriptions (Kutsch & Hall, 2010). Our research, however,
does suggest the effectiveness of risk management, particularly for increasingly complex
projects.
Next to these relationships between project complexity and certain front-end activities with
a link to project performance, there were some relationships between project complexity
and certain front-end activities without showing a link to project performance (based on
Table 7.9:
- Increased technical complexity coincides with perceived too little application of
lessons learned: e.g. technically complex projects could focus on more application
of lessons learned.
- Increased organizational complexity coincides with not taking into account the
foreseen complexity when selecting the project manager: e.g. for organizationally
complex projects attention should be paid to take into account the foreseen
complexity when selecting the project manager.
- Increased external complexity coincides with less co-operation between PM and
steering committee: e.g. for externally complex projects, attention should be paid
to the co-operation between PM and the steering committee.
The absence of a relationship with project performance is at least interesting: one would
expect that these activities (sufficient application of lessons learned, selection of the PM
and PM co-operation with SC) would show a clear (and positive) link with project
performance. Why these relations with project performance were not found might be
related to limitations in our current sample.
2.
This section presents the results of investigations towards whether and how the role of the
respondents and/or their companies significantly influenced their perspectives on project
complexity and front-end activities. Because of the non-normally distributed data, a nonparametric method was used: the Independent Sample Kruskal-Wallis Test. This method
tests equality of population medians amongst different groups (3 or more), based on ranked
data. Significant results are reported in the subsequent subsections with H as the test
statistic, the associated degrees of freedom (number of groups minus 1) and the
significance. The higher is the value of H, the bigger is the differences between (some of)
the groups. Note that the Kruskal-Wallis Test as such only reports there is a difference
between the groups, not exactly between which of the groups. Groups do not need to be of
the same size. Subsequent analysis, based on the mean ranks, was performed to find
between which of the groups the differences were most apparent.
7.6.1 Respondents role in the project
As indicated in Section 5.4.1, three different roles were distinguished: project manager
(N=37), business representative (N=12) and team member (N=18). Table 7.11 summarizes
the significant results of the Kruskal-Wallis Tests: the test item as well as the test result.
Table 7.11: Kruskal-Wallis Test results: significant differences between project
managers, business representatives and team members (N=67)
Test item
Complexity
elements
(50 in total)
Front-end
activities
(64 in total)
6.45*
Project
manager
35.97
Mean Rank
Business
representative
41.25
Team
member
25.19
12.86**
27.69
31.77
46.50
7.78*
35.80
30.17
24.09
9.49**
31.05
14.50
29.80
6.28*
26.56
34.00
38.84
6.58*
28.00
39.86
37.84
6.57*
37.15
26.17
26.78
10.65**
27.28
40.04
42.41
6.97*
28.41
44.27
35.71
17.07***
41.13
26.38
20.47
H(2)
Number of goals
Incompatibility of different
PM methods and tools
Perceived amount of VIP
goal setting and alignment
Perceived benefit of VIP goal
setting and alignment
Perceived burden of VIP risk
management
Too many project
management meetings were
held
The project manager
cooperated closely with the
steering committee
A lack of team cohesion
endangered the project
outcome
The project suffered from late
entry of parties
The foreseen complexity was
taken into account when
selecting the project manager
***
161
As shown in Table 7.11, significant differences in rank were found for two complexity
elements. The team members score the element number of goals considerably lower than
the project managers and the business representatives. This could indicate that the team
members were not fully aware of all project goals. The team members scored the element
incompatibility of different PM methods and tools considerably higher than the project
managers and the business representatives, i.e. the team members faced more complexity
due to incompatibility of PM methods and tools. These two differences were the only
significant differences found. Both differences could have been expected. First, the more
high level gap related to the number of project goals, between the team members on the
one hand and the project managers and business representatives on the other hand. Second,
a more operational gap where team members face problems due to PM tool related issues.
Particularly the first gap is concerning: the team members seem not fully aware of what the
project is actually meant for.
Also, significant differences in rank were found for several front-end activities. The groups
had a different view on the perceived amount of goal setting & alignment. The project
managers scored closest to sufficient. The business representatives scored slightly lower,
almost sufficient, and the team members scored in between too little and sufficient.
Hence the team members were most critical and project managers were satisfied about the
amount of goal setting & alignment performed in the project. The different perception of
the number of goals (one of the complexity elements described before) strengthens this
finding since team members seemed unaware of all project goals, which could have been
treated by thorough goal setting & alignment sessions. The groups also had a different view
on the perceived benefit of goal setting & alignment. Both project managers and team
members scored equally high on the perceived benefit of this VIP and considerably higher
than the business representatives. A gap seems present here between the project managers
and business representatives whereas these groups were aligned in other goal related PM
aspects.
Significant differences were also found for the perceived burden of risk management. The
project managers considered risk management least of a burden, followed by the business
representatives. The team members experienced relatively the most burden of risk
management, but still with a score that was close to neutral. Team members maybe lack the
overview to see the benefits of risk management whereas they have to provide input to the
project manager. The project manager normally is the main and final responsible for risk
management in a project.
Similar to the findings about the perceived burden of risk management, again the team
members agreed most with the statement too many project management meetings were
held, albeit still on neutral level. The project managers tended to disagree with this
statement but the mean ranks of other groups were considerably higher, indicating
agreement. Important part of the work of project managers is in project management
meetings, which explains their disagreement with the statement.
The project managers agreed most with the statement the project manager cooperated
closely with the steering committee. The business representatives and the team members
scored slightly lower. One could argue that the answer of the team members should be
taken most seriously here, because the others are personally involved (PM or SC member).
162
Note that the project managers valued their co-operation with the steering committee
slightly higher than the SC members (business representatives) did.
The project managers least agreed with the statement a lack of team cohesion endangered
the project outcome. The business representatives and the team members both scored
(equally) higher. An explanation might be that project managers feel a lack of team
cohesion as a personal failure as project manager and therefore will not easily admit a lack
of team cohesion.
The business representatives scored highest on the statement the project suffered from late
entry of parties, in between neutral and agree. The team members scored neutral and the
project managers scored lowest: little lower than neutral. Timely involving the relevant
parties can be considered one of the tasks of the project manager, which could explain their
disagreement with this statement.
The most outspoken result was found for the statement the foreseen complexity was taken
into account when selecting the project manager. The project managers agreed with this
statement, whereas the business representatives were neutral and the team members were in
between neutral and disagree. Possibly some wishful thinking influenced the responses of
the project managers, e.g. considerations like they selected me, because I am the perfect
candidate to manage this particularly complex project, which interestingly was recognized
neither by team members nor by business representatives.
One of the general findings of the above analysis is that team members have most handson experience and therefore might have a different opinion than the business
representatives or the project managers. This was for example recognized in their opinion
on the number of project management meetings, the perceived burden of risk management
and the number of goals. The project managers possibly show socially desirable behavior,
while answering some of the above questions. Still, important perspective gaps were
apparent in fields that really matter in project management, such as goal setting and
alignment, risk management, team cohesion and selection of the project manager.
The absence of other significant results indicates that no other significant differences were
found amongst the project managers, the business representatives and the team members in
the current data set. The next analysis therefore focused on the specific company role in the
project.
7.6.2 Role of the respondents company
As indicated in Section 5.4.1, three different roles were distinguished with respect to the
role of the respondents company in the project: owner (N=22), (managing) contractor
(N=33) and subcontractor (N=5). In another 7 projects, the respondents company was
involved with more than one role. These 7 projects were not included in the analysis. Table
7.12 summarizes the significant results of the Kruskal-Wallis Tests.
As shown in Table 7.12, significant differences in rank were found for four complexity
elements. The project owners scored the element conflicting norms and standards
considerably lower than the (managing) contractors and subcontractors. This can be
explained by the fact that often the (managing) contractors simply have to follow the
owners norms and standards. The strongest project schedule drive was experienced by the
(managing) contractors, both project owners and subcontractors experienced a somewhat
163
lower schedule drive (although still higher than neutral). That schedule drive was
experienced higher in perspective of the (managing) contractors seems logical: the owner
has a stronger position and maybe is more in charge in defining deadlines etc. Follow-up
Mann-Whitney tests showed that the somewhat surprising result that the subcontractors
experienced a slightly lower schedule drive was not significant.
Table 7.12: Kruskal-Wallis test results: significant differences between owners,
(managing) contractors, subcontractors (N=60)
Mean rank
Test item
Complexity
elements
(50 in total)
Front-end
activities
(64 in total)
21.86
24.55
20.76
22.25
Managing
Contractor
33.56
35.45
28.81
35.73
Subcontractor
32.88
24.00
10.83
32.30
8.37*
35.38
26.25
17.50
9.40**
32.58
20.38
32.50
7.07*
31.43
22.02
17.33
6.76*
21.23
27.70
42.00
6.61*
31.19
25.89
12.75
7.81*
28.68
18.67
16.00
6.22*
33.93
24.90
20.13
7.80
6.03*
29.18
32.38
25.07
22.66
6.17
29.13
8.12*
24.97
31.71
18.75
7.58*
31.83
31.52
12.30
H(2)
Owner
7.62*
6.92*
7.18*
8.24*
**
*
The managing contractors scored highest on the element lack of trust in the contractor. This
implies that they faced relatively highest complexity due to trust issues. This could indicate
they experience trust issues with the owners and/or subcontractors. However, the owners as
well as the subcontractors seem more positive and scored this element lower.
The project owners scored lowest on the element lack of experience in the country, i.e. they
experienced least complexity as a result of a lack of experience in the country where the
project was undertaken. Both (managing) contractors and subcontractors scored similar and
slightly higher than the project owners; they might have had less experience in the country
where the project was undertaken, faced more problems with it or were maybe closer to the
problems occurred as a results of a lack of experience in the country. Possibly the owner
164
organizations in the dataset have a more multinational character than the contractor
organizations in the dataset.
Also, several significant differences in rank were found for several front-end activities. The
most prominent difference between project owners and (managing) contractors and
subcontractors was related to the VIP operations implementation planning. The project
owners did experience the amount of the VIP operations implementation planning as
sufficient, whereas, surprisingly, both (managing) contractors and subcontractors scored the
perceived amount of the VIP operations implementation planning considerably lower
(between too little and sufficient). Similarly, the benefit of the VIP operations
implementation planning scored highest amongst the project owners and the subcontractors.
The (managing) contractors scored considerably lower. So although they perform the
activity and think they should do it even more, they seem to not really believe in it (yet?).
This result could indicate that in view of the (managing) contractors operations
implementation planning is, as yet, part of the job of the project owner, who they blame for
not performing it (well) enough.
Differences were also found for the benefit and burden of the VIP goal setting and
alignment. The majority of the respondents were positive about the benefit of the VIP goal
setting and alignment. The project owners experienced the most benefit of the VIP goal
setting and alignment, compared to the (managing) contractors and the subcontractors. This
seems logical since the (managing) contractors and the subcontractors just will follow the
procedures that the owner requests. In general, the scores for the perceived burden of any of
the VIPs were very low, but from the low scores for the VIP goal setting and alignment, the
subcontractors scored relatively high with a mean value of neutral. Their relatively high
score might be related to the fact that subcontractors are more at distance.
The VIP stakeholder management was relatively mostly applied by the project owners,
closely followed by the (managing) contractors. The subcontractors applied considerably
less stakeholder management. Again this is as expected and can logically be related to their
different roles. Similar to these results, the benefit of the VIP stakeholder management was
also scored higher by the project owners, followed by the (managing) contractors and the
subcontractors.
The benefit of the VIP project team building, the benefit of the VIP value engineering and
the benefit of the VIP lessons learned were scored as highly beneficial for the project by the
owner, higher than the (managing) contractors and the subcontractors did. As mentioned
before as well; the owner sees added value of the VIPs and therefore simply requests that
certain procedures have to be followed. These findings show that the owners indeed believe
in the benefits of applying these VIPs.
The influence of role seems also apparent in the application of the VIP constructability
review. The (managing) contractors most substantially applied this VIP, followed by the
project owners and to a lesser extent the subcontractors. Subcontractors probably were
hired to execute a certain piece of well-scoped work. Even in case constructability review
would be part of that work, most probably the (managing) contractor and/or project owner
would be involved as well.
Both project owners and (managing) contractors were satisfied with the co-operation
between the project manager and the steering committee: they scored this item
165
considerably higher than the subcontractors. Probably the subcontractors were not so
closely involved and therefore have a different opinion than the other two groups.
The above analysis shows a number of differences between the groups of project owners,
(managing) contractors and subcontractors that could logically be expected and related to
their roles. The findings suggest that the project owners generally see more benefit of
applying VIPs than the (managing) contractors and subcontractors. Since the owners
normally determine what procedures will be followed in the project, this is logical.
Interesting to see is the different view of project owners and (managing) contractors on the
VIP operations implementation planning: maybe (managing) contractors consider applying
this activity as a typical task for project owners?
A limitation of the current analysis is that both engineering contractors and managing
contractors were combined in one group. Managing contractors could be expected to
behave closer to project owners and engineering contractors could be expected to behave
closer to subcontractors, thereby cancelling out some of the effects. However the current
dataset did not allow more detailed group analysis.
Based on the current analysis we conclude that the different perspectives due to different
roles of the companies do matter in perspectives on certain complexity elements or frontend activities, but they are not surprising. Particular attention should be paid, though, to the
VIP operations implementation planning.
7.7 Discussion
This chapter investigated relations between front-end activities, project complexity and the
project performance. Finally, it was investigated how the different respondents roles
influenced their opinions on project complexity and front-end activities. The findings of
this chapter contributed to answering the following research questions (sub-questions 4 and
6 from Chapter 1):
4. What are the relevant front-end activities to deal with project complexity?
Several front-end activities showed a significant correlation with (dimensions of) project
complexity:
- Active goal monitoring (technical complexity)
- Goal setting and alignment (technical and organizational complexity)
- Timely involvement of parties in the project (technical and organizational
complexity)
- Applying teambuilding (organizational and external complexity)
Distinguishing the groups of project managers, team members and business representatives
amongst the respondents, significantly different opinions were found in the field of goal
setting and alignment, team cohesion and selection of the project manager. Between
contractors and owners, the most important difference found was in the value improving
practice operations implementation planning. This VIP was perceived to be more
beneficial and more sufficiently applied in view of the project owners, which seems
inherently related to their different roles.
6.
How can contingency theory be used to fit the front-end phase to the complexity of a
project?
The application of contingency theory to project management was explored by
investigating the relations between project complexity, front-end activities and project
166
practices and their link with project performance (Papke-Shields et al., 2010). In their
study, they concluded that those practices that make the difference (like risk management),
are not necessary the ones most frequently used. Our findings are consistent with their
findings.
How do this chapters results compare to recent findings of IPA? Most important to
improve project performance would be (IPA, 2011):
- having clear business objectives (aligns with our goal setting and alignment),
- team integration (partly aligns with our team building),
- continuity of the team (partly aligns with our team building and late entry of
parties),
- front-end loading (aligns with the overall idea of thorough definition before
project execution starts).
Hence it is concluded that the current study results are well supported by the generic IPAIndustry Benchmarking Consortium findings.
Results of our study were not only compared to recent (literature) findings. Over 35 years
ago, it was already concluded in a study on conflict management in project life cycles that
different perspectives on project priorities are amongst the most intense sources of conflict
in early project phases (Thamhain & Wilemon, 1975). Such different perspectives on
project priorities could be seen as a counterpart of our findings on goal setting and
alignment. The fact that our findings still suggest the importance of goal setting and
alignment shows: a) the importance of the topic, and b) the difficulty of improving the
situation.
More has been said about the importance of alignment of project priorities amongst
different parties involved (Halman & Burger, 2002): particular expectations of both
project owners and project managers concerning project purpose and scope as well as
their particular role in the process should be thoroughly discussed and aligned during the
design phase of the project start-up workshop, p.88. This conclusion well reflects our
finding on the importance of goal setting and alignment.
In Chapter 2, we already concluded the need for a broader approach in project management,
broader than the traditional control perspective. Crawford et al. divided the practices they
investigated in a recent study into those with a control agenda and those practices with a
process agenda (Crawford, Aitken, & Hassner-Nahmias, 2011). If we apply their view on
our significant results, we can conclude that the dominant orientation is process focused, on
top of some more control aimed elements (goal setting, parts of risk management). One
could argue that this is the case because of the selected VIPs for this study, but in the
overview of the VIPS in Table 5.2 clearly more control focused VIPs can be recognized (to
give an example: project quality control). Hence the findings of this chapter confirm the
broadening trend in project management.
7.7.3 Managerial implications
Taking into account the methodological limitations, managerial implications were
identified based on the results with the current dataset. More evidence would strengthen the
results, but, having said that, some main fields of interest were identified. These main fields
of interest are goal setting and alignment, team building, risk management, external
benchmarking and operations implementation planning. Next to these front-end
168
development fields of interest, the different perspectives related to the different roles of
the parties involved deserve particular attention.
Goal setting and alignment: the importance of goal setting and alignment seems clear from
the current results, but differences were found amongst the different groups. For some goals
related front-end activities, the project managers opinion was aligned with the business
representatives, but for other goal related front-end activities, the project manager was more
aligned with the team members. Actually, for the project manager it is important to align
with both groups. Particularly for highly complex projects, either technically and/or
organizationally, more attention could be paid to active monitoring of project goals.
Team building: whereas team building was seen to positively contribute to the projects
performance, results also suggested that applying it too much would counteract this positive
contribution. Hence the challenge is to find which amount suffices for the particular project.
The owners tend to see more benefit of teambuilding than the (sub/managing) contractors.
Risk management: in view of the respondents, risk management is applied too little with
increasingly technically and, to a lesser extent, environmentally complex projects. Risk
management would simply need more application. This relation between risk management
and project performance was moderated by the technical and environmental complexity:
more complex projects would benefit more from risk management. As a first step to
improve risk management, the risk register could more actively be used to monitor risk
throughout the project. In this study, it was shown that in the current project sample, the
risk register was actively used as often as it was not used, which gives considerable room
for improvement.
External benchmarking: in view of the respondents, external benchmarking is performed
too little hence decreasing the chance of good project performance. Only in 10 projects
external benchmarking was performed substantially, indicating the room for improvement.
However, not all projects might be well suited to perform external benchmarking.
Operations Implementation Planning: the results suggest a significant difference in
perspective between the (managing) contractors and the project owners on the amount and
benefit of operations implementation planning (OIP): owners are more positive on the
amount of effort spent (sufficient, in their view) and the benefit of this VIP. A relation was
found across the whole dataset indicating that applying operations implementation planning
(OIP) would positively contribute to the project performance. Since one third of the
respondents indicated that OIP was applied too little, giving OIP adequate attention could
contribute to improve project performance, regardless of the project complexity.
Overall, the project owners seem to be more positive about the benefit of applying Value
Improving Practices (VIPs). As they are the ones who set the rules, (sub)contractors often
simply have to comply with these rules. The relation between owner and contractor actually
by definition is unbalanced, depending on the market conditions (buyers (owners) vs.
sellers (contractors) market).
How to use results of the current study in project practice? Early in a project, a complexity
footprint could be defined using the TOE framework, indicating in which areas and from
which sources complexity can be expected in the project. Preferably both project owners
and contractors are present when determining the expected project complexity, as well as
169
the project manager and team members, thereby stimulating a constructive dialogue. Based
upon the composed complexity footprint, the (additional) effort in specific front-end
activities could be determined. For example, using Figure 7.3 and Figure 7.4, in case of a
technically complex project, specific attention could be paid to goal setting, alignment &
monitoring, risk management, and timely involvement of the involved parties. In case of an
organizationally complex project, specific attention could be paid to goal setting and
alignment, timely involvement of the involved parties and aspects of team building. In case
of an environmentally complex project, specific attention could be paid to risk management
and, again, aspects of team building.
To increase the value of these managerial implications, this exploratory NAP survey was
followed by in-depth investigations towards how the mentioned VIPs (goal setting and
alignment, team building, risk management, operations implementation planning and
external benchmarking) were actually applied and contributing to project performance. This
subsequent in-depth study is described in Chapter 8.
170
Chapter 8
How do Value Improving Practices contribute to
project performance?
An earlier version of this chapter was presented at the 2011 EURAM conference in Tallin
(Bosch-Rekveldt, Smith, Mooi, Bakker, & Verbraeck, 2011c).
As we saw earlier in this dissertation (Chapter 2), literature stresses the importance and
influence of the early project phases for the project performance (Morris, 1994; Morris et
al., 2006a). In the early project phases (called Front-End Development or FED), little has
been decided upon and many options are still open. Changes to the project scope can be
made easily and with relatively little regret. When the project matures, it becomes more
difficult to make changes. Major decisions have been taken and because interdependencies
are large, small changes typically lead to a large amount of rework. Therefore, the front-end
development phase needs thorough attention. However, investing too much time in the
front-end development phases might result in spending unnecessary resources and finally
could also lead to overruns in schedule or missed opportunities because competitors deliver
faster. The main goal of front-end development is to ensure that the owner company obtains
sufficient knowledge timely to decide at the moment of the final investment decision (FID)
whether or not a project is worth investing in.
What exactly should be done in the front-end development phases is subject of practical
debate, see Section 5.2.2 for an overview of Value Improving Practices and Best Practices
(Table 5.1 on page 99). How an organization has implemented these practices in practice
varies widely over different companies. This is because there are major differences in
project management maturity across companies, but also because not all practices might be
that relevant for all projects.
In Phase II of this PhD research, we found a number of particularly relevant Value
Improving Practices (VIPs) to increase the chance of good project performance (Chapter 7).
However, we only know that these VIPs play a role, not how they played a role. Therefore
Phase III, described in this Chapter, aimed at an in-depth investigation of these VIPs by
answering the following research question (sub-question 5 in Chapter 1).
5. How do front-end activities contribute to better project performance?
To answer this question, the following sub-questions were defined:
a) How are VIPs actually implemented in a number of companies?
b) How do they influence the project delivery performance?
c) What does really matter in VIP application?
171
This chapter addresses the answers on these questions and is structured as follows. First the
applied methods are explained and the five investigated cases are introduced (Section 8.1).
Results are subsequently presented in Section 8.2 and thoroughly discussed in Section 8.3
and Section 8.4. The chapter ends with the conclusions of this research and
recommendations in terms of managerial implications as well as suggestions for future
research (Section 8.5).
8.1 Methods
According to Yin, a case study is perfectly suited to illuminate why decisions were taken,
how they were implemented and with what result (Yin, 2002). Since this is what this
chapter aims to investigate, a case study approach was followed. In Chapter 3, the case
studies had an exploratory character, but now it is more explanatory, focusing on how
certain VIPs were actually implemented and how they were contributing to successful
project delivery.
8.1.1 Case study design
Again a multiple-cases embedded design (Yin, 2002) was followed. The embedded design
refers to the application of different VIPs to be analyzed within one case and the
multiplicity refers to the inclusion of a number of cases (5) as opposed to inclusion of a
single case. The focus was on technically complex projects.
Per case, semi-structured interviews were performed with the project manager and, if
available, one or two team members involved. All interview questions are listed in
Appendix F. The interview questions were focused on the implementation of certain VIPs,
namely those VIPs that resulted from the research described in Chapter 7. Results of
Chapter 7 suggested that for engineering projects, particularly the following VIPs were
contributing to good project performance:
Team Design,
Goals (setting, alignment, monitoring),
Risk management,
External benchmarking,
Operations implementation planning.
A brief explanation of these VIPs was already provided in Table 5.2 on page 100.
8.1.2 Case selection
To find how these VIPs actually were implemented in the projects under investigation and
how these could have contributed to the projects performance, in-depth case studies were
performed. From the existing dataset of 67 projects, four cases were selected in which the
above VIPs were applied, following the case selection procedure in Table 8.1.
Table 8.1: Case selection procedure
Identification
step
0
1
2
3
4
5
172
Criterion
Cases left
67
62
25
14
7
4
Starting with 67 projects from the survey study, those projects were selected in which the
interviewee was actively involved in the FED phase (62 projects left). Subsequently, those
projects in which the respondents were willing to participate in subsequent research were
selected (25 projects left). From these 25 projects, 14 projects applied the VIPs under
consideration little or substantial in view of the respondents, of which 7 projects were
perceived technically complex. From these 7, finally the 4 cases were selected where the
contact person acted as the project manager, since the project manager was considered the
most relevant person to involve in the in-depth studies.
From these 4 selected cases, 3 were performed by contractors and only one by an owner
organization. Since different opinions were expected between contractors on the one hand
and project owners on the other hand (see Section 7.6), another project which was
performed by an owner organization was included; the 5th case. This case came from a
well-established owner company in the process industry, also member of the NAP network.
This additional case met all requirements that were defined for the other 4 cases with regard
to application of VIPs. In total 11 semi-structured in-depth interviews were conducted
across these 5 cases. A summary of the selected cases is given in Table 8.2.
Table 8.2: Summary of selected cases
Case
Case
REF-ID
Role in
project
Project
performance
Interviews
Owner
Good
41
Contractor
Good
42
Contractor
Very poor
83
Contractor
Poor
1; PM
Additional
Owner
Good
The performance score mentioned in Table 8.2 was based on three aspects: schedule
overrun, budget overrun and perceived quality performance. In case a project was delivered
with sufficient quality within 10% budget and schedule overrun, the project performance
was called good. The project performance was called poor in case either one of these
conditions was not met. The project performance was called very poor in case none of
these conditions was met. Scoring on these criteria, the five selected cases included three
cases with good performance, one case with poor performance and one case with very poor
performance. So although these five cases scored similarly on the application of VIP
activities (e.g. the independent variables), this resulted in very different performance scores
(e.g. the dependent variable), based on the survey results. Figure 8.1 shows the overview of
the selected cases and their performance scores.
173
This chapter presents the analysis of the in-depth interview results for the five cases as
follows. First, each of the 5 cases is presented at glance, summarizing the main
characteristics of the project (the objective, why the project was undertaken, who was
involved, whether or not cost- and schedule estimates were met). Next, the application of
the VIPs is discussed (Team Design, Goals, Risk Management, External Benchmarking,
Operations Implementation Planning), followed by a reflective case summary. In the
subsequent cross-case analysis, the five cases are compared by focusing on each of the
VIPs and their application across these cases as well as by comparing their performance
and how the application of VIPs contributed to the project performance.
creating acceptance and buy-in of the site owners. Future users were asked for input already
in the design phase. Also the facilitation of training sessions for operators and maintenance
personnel was contributing to the flawless start-up, in view of the interviewees.
Reflecting on the above analysis, it seems integration and involvement played a prominent
role in achieving good project performance. Integration is in terms of the team composition
(including owner specialists and the contractor staff), but also by involving the future users
already in the design phase as part of OIP. Because of the good team atmosphere and good
relation and trust between the owner and EPCM (Engineering Procurement Construction
Management) contractor, a potential conflict was solved without escalating, according to
the interviewees. Involvement is in terms of involving the team in defining the detailed user
requirements and the initial risk analysis.
8.2.2 Case B: A turnaround project by a contractor (good project
performance)
The key objective of this project was to increase the capacity of a clients already
functioning plant by 50% by placing additional equipment and replacing current equipment,
using partly unproven technology. This design and engineering turnaround project was
undertaken on request of the client, for operational necessity. It was a 100% investment of
the client. Next to the client, the key stakeholder was the operations manager of the current
plant. The cost estimate of 7MEuro was achieved within 10%; the schedule estimate of 22
months was met. The slight cost overrun was caused by late scope changes of the client, in
view of the interviewees.
The project team was composed of personnel of both the contracting company and the
project owner. The team consisted of about 15 multidisciplinary engineers of the contractor,
coordinated by dedicated lead engineers and led by the project manager from the
contractors side. The owner also appointed a project manager and delivered two process
engineers to the integrated project team. According to the contractors project manager the
team composition (integrated and multidisciplinary) beneficially contributed to the project
performance as it supported quick communication, sharing and evaluating ideas concerning
design and engineering issues. He also indicated that many years of collaboration (20 years)
and the six years that they are preferred supplier now (in the form of a Global Framework
Agreement) resulted in trust between them and the project owner, which also contributed to
the good working environment and success of the project team.
The goal of this project was to investigate the technical feasibility and subsequently define
the technical scope in the early FED phase. Joint effort was undertaken by owner and
contractor, resulting in alignment and broad understanding. Goals were also clear amongst
the team members, in view of the interviewees. Goal monitoring was actively done by the
project manager based on input and reports of all team members (via the lead engineers).
All interviewees stated that having clear goals and monitoring the progress was important
to keep the project on track.
Systematic risk identification was performed several times during the later FED phase and
the execution phase. The methods used to identify risks included mind mapping and
analysis of simulation models. The subcontractors and engineering disciplines (civil,
piping, mechanical, construction), were involved in the reviews. During the reviews, risks,
mitigations and actions were identified and appointed to corresponding specialists. In view
of the project manager, appointing risk owners influenced the project performance
176
positively, because persons, who were best aware, monitored those risks. Even more
important, in his view, it prevented having unsafe situations during the turnaround, and
hence directly contributed to the good safety performance.
External benchmarking was performed by IPA during the front-end phase, simply because
benchmarking was a requirement from the client for projects above 5 million US$. During
FED, the contractor delivered documentation for benchmarking. The results of the IPA
study were used by the clients decision board as an indication of project fitness. The good
IPA score contributed to a positive investment decision. Recommendations from the
benchmarking study (effective management of interfaces, involvement of the site and
preservation of a strong team set up) were followed up by the project management.
Regarding operations implementation planning, it seems the contractor could not look
beyond the current project. For him, operations implementation planning was ensuring that
all equipment was delivered in time, installed correctly and thoroughly checked. Applying
operations implementation planning, however, could have avoided the late scope change
that was requested by the client as a result of (too) late consultation with the operations
team.
Reflecting on the above analysis, it seems trust amongst the parties played an important
role. The trust between the owner and contractor was developed in the 20 years of
collaboration of which 6 years under a global framework agreement. Also because of the
good long term relationship, integration and involvement are keywords to characterize this
good performing project. Integration, i.e. the project owner was collaborating closely to the
contractor. However, because of the high trust relationship, formal stakeholder involvement
was given in sufficient attention, resulting in unnecessary, late scope changes. Formal risk
management was applied and successfully contributed to the safe turnaround in view of the
project manager, particularly because the high technological uncertainties faced in this
project. Operation implementation planning (OIP) in fact was not applied.
8.2.3 Case C: A public civil engineering and construction project by
a contractor (very poor project performance)
The key objective of this project was to design and build a new transportation hub. The
involved municipality acted as the project owner. The business justification to undertake
this project for the contractor was to obtain margin growth, to build a long-term relation
with the project owner and the partner company, to gather knowledge and experience in the
field and to get introduced in a new market. The key stakeholders were the municipality
and a related project that was executed in parallel. The cost estimate of 12MEuro was
exceeded by about 20%; the schedule estimate of 120 months was exceeded by more than
20%.
A collaborative project team was formed by members of two companies, both contractors.
These contractors were legally bound by forming a joint venture for this project. The
project team was multidisciplinary and consisted of more than ten electrical and civil
engineers. The roles of the engineers were set by the standard work procedures of the
interviewed contractor. The functions and responsibilities per team member were described
in the project plan. Based on the tender, the necessary discipline engineers were already
selected and once the bid was approved, these engineers were added to the project team. In
view of the project manager, a good working environment was created by having clear
177
178
a FED activity, but about truly investing effort in an activity in order to obtain alertness for
the dynamics of the project environment.
8.2.4 Case D: A plant modification project by a contractor (poor
project performance)
The objective of the project was to modify several of the refinery processes of the project
owner in order to make them compliant with European environmental legislation and to
reduce capital and operating costs with 20%. New technology was included in the project.
The business justification to undertake this project for the contractor was to maintain
current margin and to build a long-term relationship with the client. The key stakeholders
were the project owner (100% investment in the project) and the contractor. The cost
estimate of 36MEuro was met; the schedule estimate of 12 months (for one of the three
subprojects) was exceeded by more than 20%. The other two subprojects were delivered in
time.
The project team consisted of engineers from both the project owner and the contractor
(multidisciplinary: engineering disciplines, procurement and contracting, cost controllers,
schedulers). In total 40 team members were involved, of which 15 came from the
contractor. In view of the project manager, the integrated team was contributing to good
project performance as it enabled quick communication with lead engineers of the client,
which increased the pace of the project. Furthermore the integrated team enabled alignment
between contractor and client, which in his view enhanced the client satisfaction. The
project manager stated that team performance was heavily dependent upon the different
people involved. According to the project manager, the team composition was not only
based on the disciplines needed but also on the competencies and soft skills that were
required for this project. In his view, this was a very important contribution to the overall
project performance, as it avoided people functioning in wrong positions.
The project goals were set jointly by the client and the manager of the contractor. Based on
the main goal, the goals were divided further on a discipline level for the different
engineers, the key members of the procurement and contracting department, the cost
controllers and the schedulers of the contractor. The joint effort towards defining goals was
considered important as it guaranteed the goals were understood correctly by all parties and
were in line with present European legislation. The project goals were monitored by
evaluating them on a monthly basis by means of a progress report. The various engineers,
procurement and contracting staff, cost controllers and schedulers delivered input to the
progress report. The project manager indicated that the progress reports were also used to
anticipate on opportunities: when steel prices were expected to drop, the planning of the
purchase of piping was adjusted.
Only after the FED phase, at start of project execution, the project team and other key
players performed a risk management session. In this session risks and opportunities were
identified, mitigation strategies were explored and responsible people were assigned to
monitor these risks or opportunities. The risks, mitigations and risk owners were
documented in a risk register. The risks were evaluated every three months. In view of the
project manager, investing effort in risk management pays off since a safe project execution
was realized without near misses and accidents. However, an extensive identification and
detailed analysis of project schedule risks during the development phases could have
reduced the project delay and would have subsequently enabled a more successful project
delivery.
179
After redefining the business case, the project scope was frozen. The project manager
experienced that the joint effort of reframing the project scope provided a new, essential
and vital foundation to continue and enhanced the team spirit. The new project goals as
defined in the project plan, including schedule and budget realization, were monitored
during weekly progress meetings with the lead engineers and the project manager. In the
view of the project manager it was important to monitor goals together: it offered the
possibility for early problem identification and solving. In case of problems, the contractor
had procedures in place to cope with formal scope changes, which were used by the owner
to integrate the changes in the project.
Risk analysis was performed in phase 1 by an external consultant. Before starting phase 2,
when reformulating the project goals and scope, risks were identified, mitigations were
defined, risk owners were allocated and actions were distributed. During phase 2, no
additional risk analysis was performed, nor were formal risk management tools in place. In
view of the project manager, risks related to the start-up were foreseen, but could not be
fully mitigated because of the strategy to be on the market as soon as possible, hence
limiting R&D time.
External benchmarking was applied at the end of the project, as part of the project
evaluation. Generally this is done earlier in the project. In this case, external benchmarking
was not experienced as very useful, since results were not communicated back to the
project team. Results of the benchmarking study indicated that the decision making was a
relatively slow process. This could for example refer to the fact that R&D came regularly
with new results, resulting to scope changes over and over again.
According to the project manager, the key to ensure a good start-up was to integrate
operations early in the project team. Operations had clear milestones during the Front-End
Development phase to ensure that the operators were ready when the factory was
commissioned. Operations main responsibility was to gather sufficient information in
order to write operation manuals, job instructions and maintenance requirements.
Furthermore their input was enquired for the design. Still, the targeted production after
project delivery was delayed because of start-up problems. Some intended processes could
not be executed because of time restrictions (i.e. not 100% practice what you preach).
Reflecting on the above analysis, it seems a good second start was made for this project
resulting in successful project delivery (despite some start-up problems after delivery).
Although the joint effort in reframing the project did not avoid scope changes, it gave a new
vital foundation to continue with the project and it enhanced the team spirit. An integrated
project team existed, consisting of contractor and owner employees, but the R&D
department was formally not integrated in the project team despite their crucial role in the
project. However, R&D members were involved in weekly progress meetings, thereby
actively contributing to the project (albeit informal). It was a conscious choice to limit the
R&D time. In case R&D had been given more time to develop the technology, a number of
scope changes could have been avoided and likely a better start-up could have been
realised. Neither risk management or external benchmarking, nor operations
implementation planning where thoroughly and correctly applied.
the cross-case analysis is focussed on the application of the separate VIPs across the cases,
e.g. discussing the rows in Table 8.3. Subsequently, the similarities and differences
between the cases are discussed, e.g. focussing on comparing the columns of Table 8.3.
The level of application of the different VIPs in the different cases was determined based
on the interview results (i.e. this is an interpretation of the researchers).
Table 8.3: Summary of case results
Application of VIP?
VIP
Project team
building: Having
an integrated
project team?
Goal setting
Monitoring
project goals
Risk
identification
and management
External
benchmarking
Operations
implementation
planning
Case A
Owner
Performance:
good
Case B
Contractor
Performance:
good
Case C
Contractor
Performance:
very poor
Case D
Contractor
Performance:
poor
Case E
Owner
Performance:
good
Yes
Yes
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Partly
Yes
Partly
Partly
Partly
No
Yes
No
Partly
Partly
Yes
No
No
Partly
Partly
182
Having a project team with team members that have collaborated for a long time, likely
results in the development of trust. An important benefit mentioned in case B, is that trust
results in a good working environment, which favours the motivation of sharing and
criticizing ideas. One of the factors that likely contribute to the development of trust is to
have a steady composition of the team. Long term relationships between parties enable such
steady team compositions.
The case study results reinforce the suggestion that collaborative project teams are desirable
and can help improve teamwork effectiveness (Anderson, Patil, Gibson, & Sullivan, 2004).
A good team design will also influence stakeholder management and risk management
positively. In conclusion, team design is an important FED activity that needs thorough
consideration as it might affect many other elements of delivering a project with good
performance.
8.3.2 Findings on goal setting
Goals were formulated for all the cases by means of joint effort. What this joint effort
entailed varied by case. It could be a workshop to set goals with the entire project team and
relevant stakeholders. Alternatively, it could involve a joint study to the feasibility of a
project or to define the technical scope. Joint effort constituted alignment amongst the
stakeholders involved, in view of the interviewees. Although joint effort in goal setting
seems to enable alignment, for case C it did not work out very well. Even though goals
were framed by the various stakeholders, it seemed that the stakeholders could not keep
alignment on the main project goals, as alterations in requirements and legislation caused
changes to the project scope several times. Such (external) changes would have needed
some sort of resetting workshop. Hence applying joint goal setting does not automatically
lead to good project performance.
Not only joint goal setting, but especially joint effort is important to create alignment and
commitment. When joint effort is undertaken for finding an optimal solution and for
developing implementation action plans, this likely contributes to an improved
understanding of each others capabilities and expectations. As a result of such better
understanding and involvement, a reduction of major scope changes can be expected,
contributing to better client satisfaction. Consequently, undertaking joint effort can be seen
as a kind of team building exercise since it enables the development of trust, confirming
literature findings (Kadefors, 2004). In a project environment with many stakeholders,
which all have a high possibility to influence a projects scope, it is important to keep
sufficient attention to (joint) goal setting.
8.3.3 Findings on monitoring project goals
The case results confirm the benefit of monitoring project goals. This activity was applied
in all cases, and the interviewees seemed very much aware of the importance of this
activity. In their view, it is, amongst others, a means to make people aware of abnormalities
in schedule and/or budget and hence to keep on track.
All cases, both with good and (very) poor performance, had structured procedures to check
project progress and take action to overcome any deviation from achieving the project
goals. Hence, applying this FED activity does not automatically lead to good project
performance. In case C, the major problem of continuous scope changes was not overcome
by monitoring project goals and also case D displayed poor performance although
monitoring project goals was applied, according to the interviewee. Just applying this
183
activity does not necessary suffice; it is essential to choose the right monitoring means and
to take appropriate action, if needed.
The right amount and type of effort to invest in project goals monitoring obviously relates
to the project environment and should be treated differently for each project. The more the
project environment is dynamic, the more effort is needed to monitor the project goals. In
monitoring project goals, the challenge is to limit the scope changes. Limiting scope
changes can be supported by the use of integrated teams and thorough interface
management.
8.3.4 Findings on risk management
The application of risk management seems to be contingent with the project environment.
This is confirming our Chapter 7 findings in which a moderated relationship was found
between risk management and project performance with project complexity as the
moderator. Increasing technical complexity was shown to coincide with the need for more
(better?) risk management, resulting in better project performance. Also earlier literature
suggests that risk management techniques are more helpful for high-risk projects (Raz et
al., 2002).
The case studies suggest that risk management beneficially contributed to the project as it
offered the opportunity to identify deficiencies in early stages, thereby avoiding rework.
But even more important, it contributed to an increase in safety performance during
execution, in view of the interviewees. Risks were identified when defining the business
case and the user requirements. Techniques used to identify the risks were brainstorming
and mind mapping sessions. Later on in the project, more technical risks were identified
and assessed.
The case results indicate only partial applications of risk management in practice. Often
actions and owners were allocated to the identified risks, but risk registers or formal risk
monitoring were not generally applied. Becoming alert for the most important risks seems
to get priority over formally codifying and, particularly, monitoring. In a very stable project
environment this could work, but in more dynamic project environments (like we
normally face) using formal procedures (or at least, have more continuous attention) for
risk management could be beneficial.
Based on the distinction between projects with good performance and (very) poor
performance in this case study, it seems that applying risk management does not
automatically result in good project performance. Moreover, the cases with (very) poor
project performance (case C and D) were the only cases that had risk registers in place. The
cases with good project performance more implicitly implemented risk management
practices in the management of the project. Thorough risk identification was followed by
allocation of actions and (implicit) identification of risk owners. Formal risk monitoring,
risk reassessment or risk registers were not used in two of the three projects with good
performance. The success of these projects, still, can be explained by the fact that the risk
identification was done by integrated teams, including technical experts. Those risks that
were identified likely were the risks that mattered for those projects. Hence the quality of
the risk management seems more important than the quantity. And maybe more important
are the people involved: integrated teams likely are more alert for the risks that matter
that might appear in a project.
184
Reflecting on the above analysis, it seems it is not about applying risk management with a
tick the box mentality, but it is about truly investing effort, in order to obtain alertness of
the (integrated) project team. Look for example at the annual risk workshop in case C: it
ticks the box but does not really help the project. A means to improve risk management is
to have the right people incorporated in the project team who are alert and able to cope with
the technical risks and the dynamics of the project environment. And it doesnt stop with a
good start. A thorough risk identification session, including the appointing of risk owners,
should be followed by serious risk monitoring in order to take the appropriate actions to
achieve the project goals.
8.3.5 Findings on external benchmarking
Although some companies see external benchmarking as an important way to improve their
projects, it was substantially applied in only three of the five cases. And from these three
cases, only in one case (B) it was 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 FED 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 D) illustrated a more traditional owner contractor
relation. Here the contractor did not see the value of applying external benchmarking: it
was just applied because it was requested by the project owner. In case of real integrated
teams, more feedback of the benchmarking results and integration of these results in the
project would be expected. The additional case also applied external benchmarking but it
seems it was applied simply too late to be effectively included in the project.
The reason why, in the remaining cases, external benchmarking was not substantially
applied was either that it was not a common practice in the industry (case C); or it was not
desired to benchmark because of the patented and unique products involved (case A), in
view of the interviewees. Applying external benchmarking could have enabled early
anticipation in the FED phase on the negative developments in case C. For example, an
external benchmarking study could have recommended paying more attention to interface
and stakeholder management. A study from within the construction industry also suggests
that benchmarking can support project management, by learning from best practices of
others and stimulation of continuous improvement within the organization (Luu, Kim, &
Huynh, 2008).
Summarizing the above, we conclude that it is likely that external benchmarking has the
potential to positively contribute to project performance, despite its poor application (in
quantity and quality) in our current case studies.
8.3.6 Findings on operations implementation planning
In 1998, the construction industry institute (CII, 1998) stated that the industry did not have
sufficient tools to facilitate effective planning for start-up. Apparently a lot has happened in
the industry since then, as illustrated by our case study results. Nowadays, procedures are
operational, for example for the preparation for start-up. Next to these procedures with a
technical focus, it was also considered essential that the future user (often the operations
department) is integrated in the project team or otherwise involved early in the project. This
enabled the inquiry of feedback for the design in order to identify flaws in an early stage.
Furthermore the early involvement enabled them to have operation manuals, job
185
that apply the VIPs. A formal structure of performing VIPs is necessary (e.g. in company
work processes), but not necessarily sufficient to achieve good project performance. Jointly
applying VIPs promotes team integration. Here, integration and involvement are keywords.
With integration we refer to integration of the results of the different VIPs, integration of
the different disciplines in a multidisciplinary team and integration of the different parties
involved (e.g. close collaboration of contractor and owner). Involvement means that the
team members are involved in setting project goals, in risk workshops, etc. And, preferably,
the same parties (even better: persons) are involved in the different project phases,
including the technical specialists and the future users. Long term relationships between the
project owner and contractors enable team integration.
Whereas about ten years ago, already a plea was made for better interaction between client
and engineering contractor (Love et al., 2002; van der Velde & van Donk, 2002), our
results suggest that this interaction can be stimulated by establishing integrated teams.
Integration, in turn, can help team work effectiveness (Baiden & Price, 2011).
Taking a helicopter view, it appears that trust (between the team members, but also between
the contractor and project owner) and alertness (to anticipate on the changes in the project
or project environment) can influence successful application of the value improving
practices. Spending joint effort in VIPs, or broader front-end activities, seems to support the
development of trust within a project team: when working together, interpersonal relations
are build which help in solving problems later on. It is not always about the result of
applying the VIPs, but also about the fact that joint awareness is created by performing a
VIP with a truly integrated project team.
Control and trust need to be balanced (Atkinson, Crawford, & Ward, 2006). In dealing with
increasingly complex and uncertain projects, traditional control methods become
insufficient and trust becomes more and more important. Our case study results confirm the
importance of trust in technically complex projects. Note however that different groups
may have different perspectives on trust (Pinto et al., 2009). They distinguished between
integrity trust (the belief that one party will routinely look after the interests of another
party, p.641) and competence trust (the belief that the other party has the ability to
perform the work assigned, p.641) and investigated its impact on project success in view
of clients and contractors in Canadian construction industry. They found that for owners,
both integrity trust and competence trust are important, whereas for contractors, mainly
integrity trust is important.
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). Our
research also suggests that people are key elements in projects. Still, formally and truly
(e.g. not as tick the box exercises) applying VIPs is deemed beneficial as they provide the
guidance in performing those activities that are relevant for achieving good project
performance. 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.
Independent Project Analysis also observed that in applying VIPs, spending joint effort (in
an integrated team) is beneficially contributing to project performance (IPA, 2011).
The findings of this research support developments in literature in which it is argued that
the people in the project play the crucial (but interwoven) role (Baiden & Price, 2011;
Cooke-Davies, 2002; Lechler, 1998). But it is not only the people: the VIPs under
investigation do add value: having a formal system in place for applying VIPs is a first
necessary step in professionalising project management. On top of such a formal structure,
the people are the ones that make or break the project.
In the studied cases, the value improving practices team design (integrated
multidisciplinary project teams), goal setting & monitoring and operations implementation
planning were implemented according to the best practices known from literature.
Integrated teams particularly seemed to beneficially contribute to project performance as it
increased efficiency in decision making. Based on the findings of this research it seems
likely that trust and the composition of a team, not only in terms of disciplines but also in
terms of competences, have to be taken into account when designing a team. Risk
management was implemented in the cases under investigation to a lesser extent than
described in the literature; it seemed to stop after the risk identification. Appointing risk
owners was highly beneficial in view of the interviewees, see Case B to illustrate best in
class risk management practice.
From this qualitative study, the following managerial implications are suggested for
technically complex projects:
- Work in integrated teams (contractor & owner),
- Involve the operations people early on in the project,
- Try to keep key persons in the team across the different project phases (starting
with R&D),
- Perform goal setting with the integrated team, in a joint effort, and keep on doing
that,
- Perform external benchmarking and actively involve the results in the project,
- Actively monitor and manage risks after thorough risk identification and
appointing of risk owners.
Of this list of managerial implications, the most important is working in integrated teams. It
is about establishing true integration between all parties involved, which can be improved
by better (and jointly!) applying VIPs. Long term relations contribute to trust between
parties and both support such true integration. Project teams working together for a longer
period of time developed effective problem solving skills (de Jong & Elfring, 2010).
In project management, it seems all tools are available for successful project delivery, but
we keep on nailing using pincers. How you apply the VIPs e.g. the people factor seems
important on top of that you apply them.
Limitations of this research concern the limited availability of interviewees in some of the
cases under investigation. The strong point of this study, however, is that it shows the
qualitative story behind some of the cases from our quantitative dataset (results described in
Chapter 7), and the results reinforce each other.
This research suggests the importance of integrated teams and long term relationships
between project owner and project contractors. Further research into particularly this area is
recommended: how to establish such long term relationships and how to maintain them,
and how can innovative contracting help in this?
188
Chapter 9
Validating the TOE framework for potential use
Thus far, explorative case studies were performed (Phase I) to develop the framework to
grasp project complexity and to explore different perspectives on project complexity
(Chapter 3). This work resulted in the TOE framework (Chapter 4). Next, an explorative,
quantitative survey was performed (Phase II) to evaluate the framework to grasp project
complexity and to investigate the relations between FED, project complexity and project
performance, including investigations towards the different perspectives (Chapters 5, 6 and
7). Subsequently, Phase III investigated by means of explanatory case studies how frontend activities contributed to better project performance (Chapter 8). These chapters resulted
in:
1. A (partly) validated TOE framework and recommendations for improving the
TOE framework.
2. Indicative relations between project complexity, FED and project performance.
3. Indications of different perspectives of project owners and contractors on
complexity aspects and the application of front-end activities.
After Phase II, the TOE framework was only partly validated. On the one hand, this was
because of limitations in the Chapter 5 project sample and/or difficulties with the survey
questions (unclear phrasing of questions, resulting in misunderstanding). On the other hand,
this was caused by the respondents who experienced the consequences of project
complexity, whereas the TOE complexity framework aims to grasp the causes of project
complexity. As a result, when respondents were asked about their perception of project
complexity, their answers were reflecting its consequences rather than its causes. In order to
overcome this, this final chapter presents a more general, non-project specific approach in
which the TOE elements are explicitly evaluated on their potential contribution to the
complexity of the project. Next to evaluating the TOE framework as such, it is also
discussed how the project managers would deal with certain aspects of complexity in the
front-end development phase and what the potential of the framework for practical use
might be.
In this chapter, it is aimed to answer the following research question (sub-question 7 in
Chapter 1):
7. How could a framework to grasp project complexity be used to improve project
performance?
To answer this research question, several sub-questions were defined:
a) To what extent do the various elements in the TOE framework contribute to
project complexity?
189
b) How would project managers treat the elements most contributing to project
complexity in the front-end development phase?
c) How do perspectives of owners and contractors differ in complexity assessment
and treatment of project complexity?
d) How could a project manager use the TOE framework?
This chapter is structured as follows. First, the final TOE framework is presented in Section
9.1. Next, the survey design is presented in Section 9.2 and the data treatment is discussed
in Section 9.3. Subsequently, results are presented and analysed in Section 9.4. This chapter
ends with a discussion of the results in Section 9.5.
190
Organizational Complexity
(16 elements)
External Complexity
(14 elements)
Nonalignment of
project goals
Unclarity of project
goals
Dependencies on external
stakeholders
Uncertainties in scope
Political influence
Strict quality
requirements
Project duration
Size in CAPEX
Number of contracts
Number of locations
Number of different
nationalities
Weather conditions
Newness of technology
(worldwide)
Number of different
languages
Remoteness of location
Presence of JV partner
Number of tasks
Variety of tasks
Dependencies between
tasks
Incompatibility between
different project management
methods / tools
Level of competition
Uncertainty in methods
Involvement of different
technical disciplines
Organizational risks
Technical risks
Subsequently, the elements that were scored substantial or very much by the
respondent were listed on the screen and the respondent had to select those three elements
that in their opinion contributes most to a projects complexity. For these three elements,
they could also express which Value Improving Practice(s) they would use to treat this
aspect of complexity in the front-end development phase. Again, the VIPs as selected in
Chapter 5 were used (see Table 5.1 and Table 5.2 for selection of these VIPs) and more
191
than one answer could be selected (see Table 9.2). Next, the elements that were scored
none or little by the respondent were listed on the screen and the respondent had to
select which three of these would contribute least to project complexity. All survey
questions are listed in Appendix G.
Table 9.2: Survey question on additional effort for element(s) most contributing to
project complexity
Additional effort was spent in the following VIP(s), more than one answer is possible
No additional effort
Constructability review
DesigntoCapacity
External benchmarking
Goal-setting and alignment
Lessons learned
Operations implementation planning
Project quality control
Project team building
Risk management
Stakeholder management
Technology selection
Value engineering
Other:
Finally, the respondents were asked for their opinion about the potential use of the TOE
complexity framework by means of three open questions:
1. How would you apply the TOE project complexity framework in your daily
practice?
2. What would be the added value of using the TOE framework in your projects, if
any?
3. What suggestions do you have for further development of the TOE framework?
For this part of the survey, open questions were used as they do not restrict the respondent
in their answers. Their answers were used for fine-tuning of the TOE framework. The
mixture of open questions and closed questions in one survey perfectly fits a mixed
methods approach (Blaikie, 2009).
In the development and design of the survey, the following measures were taken to ensure
the internal validity. Before the survey was published on the internet, several experts were
asked to test concept versions of the survey. Based on their feedback, questions were
reformulated and terminology was clarified. The internal validity was also enforced by
related questions on scoring complexity elements: control questions (the elements that
overall scored highest and the overall respondents top-3). The external validity of this
study was positively influenced by the fact that the survey was distributed amongst four
totally different companies, all actively involved in the NAP network.
companies. These companies were considered as belonging to the active, key players of the
NAP network and were chosen because they were expected to have a broad view on project
management in the process industry and relatively mature project management approaches
in place. Per company, the head of the project management department was approached.
All approached companies were willing to participate and the approached heads distributed
the link to the web based survey amongst their project managers. In total, 111 survey
requests were sent and the survey was started by 68 respondents. Of these respondents, 64
indeed completed and submitted the completed results, hence obtaining a high overall
response rate of 58%. For the contractor group (smaller in size), the response rate was little
higher than for the owner group. An overview of the response rate, overall as well as per
group (owner / contractor), is given in Table 9.3.
Group
Response rate
Total
111
64
58%
Contractor
35
24
69%
Owner
76
40
53%
While completing the survey, the progress was saved on the participants computer.
Measures were taken to prevent double submissions from one participant. The respondents
could indicate their willingness to be involved in subsequent research. Apart from their
typical company role and their work experience, no specific information about the
respondents was included in the data analysis.
As opposed to the exploratory survey described in Chapter 5 (80 questions), the current
survey had a more focused and evaluating character (20 questions). Again, the survey was
developed and executed in the web-based application NetQ (www.netq.nl). The NetQ data
was stored in SPSS compatible format. The survey was designed to be completed in about
15 minutes. This estimate was little too positive: most of the respondents needed between
15 and 30 minutes to complete the survey (see Figure 9.1). The respondents spending more
than 75 minutes probably did not close the window in which they opened the survey and
probably spent considerably less time for real completion. All data was gathered within
four weeks (February 25th 2011 till March 21st 2011).
Figure 9.2: Years of experience as project manager (left) and at the company (right)
194
195
Technical
Non-alignment of project goals
58%
Uncertainties in scope
56%
55%
Organizational
Lack of resource and skills availability
70%
50%
38%
External
Variety of stakeholders perspectives
58%
44%
28%
28%
Table 9.4 shows that the top-3 of most often mentioned T-elements includes elements
related to project goals and project scope and that these elements were mentioned by more
than half of the respondents. There seems considerable agreement amongst the respondents
about the importance of these elements, which also confirms recent research in construction
industry (Hassen, Al-Tmeemy, Abdul-Rahman, & Harun, 2011). The most often mentioned
O-element is a lack of resource and skills availability, mentioned by about 70% of the
respondents. This seems a trivial element contributing to complexity of a project: if
resources are lacking; realizing project objectives becomes troublesome. Also it might
highlight a serious problem that occurs in current project practice which has to deal with
196
Technical
Number of tasks
45%
45%
34%
Organizational
Involvement of different time zones
64%
56%
42%
External
Weather conditions
53%
Level of competition
45%
Remoteness of location
28%
The percentages in Table 9.4 and Table 9.5 indicate more agreement amongst the
respondents on the elements (either most or least) contributing to O-complexity. Results for
the T- and E-categories are more dispersed. Generally, for all three categories, the highest
scoring elements are hardly mentioned as least contributing to project complexity and vice
versa, which improves the reliability of the results. Surprisingly, the elements explicitly
related to risk (either Technical, Organizational or Environmental) were hardly
mentioned (see also appendix H).
If the data would be divided into an owner respondents group (N=40) and a contractor
respondents group (N=24), would there be any significant differences amongst the groups?
Differences between the owners and contractors perspective were investigated by
performing an independent samples Mann-Whitney test on the distributions of the scores of
the 47 TOE elements. Several significant results were found (Table 9.6), indicating that
indeed for some elements the distribution of the results is significantly different amongst
the two groups, all with small to medium effect size (Field, 2009). The effect size was
197
calculated by dividing the z-score (the normalized test score) by the square root of N
(number of responses). A negative effect size indicates that owners perceived this element
as contributing more to project complexity; a positive effect size indicates that contractors
perceived this element as contributing more to project complexity.
Table 9.6: Significant results for Mann-Whitney test (distinguishing owners and
contractors)
N
Mann-Whitney
(Test Statistic U)
Significance
Effect
size r
64
271
0,001
-3,177
-0,397
64
307,5
0,007
-2,702
-0,338
64
320
0,017
-2,397
-0,300
64
331
0,024
-2,259
-0,282
64
340
0,026
-2,225
-0,278
64
631.5
0,023
2,272
0,284
Size in CAPEX
64
622,5
0,037
2,087
0,261
Number of locations
Instability of project
environment
64
613
0,043
2,023
0,253
64
611
0,046
1,992
0,249
Element
Company internal
pressure
Required local content
Organizational risks
Unclarity of project
goals
Variety of external
stakeholders
perspectives
Technical risks
The results of Figure 9.3 (cumulative element scores) were redrawn in Figure 9.4,
presenting the results of the owner group and the results of the contractor group separately.
To enable fair comparison between the two groups, Figure 9.4 shows normalized scores.
From Table 9.6 and Figure 9.4, it is concluded that the owners considered several aspects as
contributing more to complexity than the contractors: company internal pressure, required
local content, organizational risks, unclarity of project goals and variety of stakeholders
perspectives. The different perception on company internal pressure might be related to the
specific (and limited number of) companies involved in this study. The different perception
of required local content might be related to lower applicability of this element for the
contractors involved, just because of the selected companies.
The different perception of organizational risks between owners and contractors can be
explained in case the project owners are also the owners of these risks, but of course this is
related to the chosen contract form, which might be different for different projects. Also the
contractor might not recognize organizational risks, thereby underestimating project
complexity. However, this cannot be firmly concluded based on the current data set.
For improving project practice, more relevant are the different perceptions on unclarity of
project goals and variety of stakeholders perspectives, since these elements are also in the
top-3 of elements most contributing to project complexity (see Table 9.4). These elements
are most contributing to project complexity and owners and contractors do have a
significantly different opinion about them. Possibly, contractors do underestimate the
relevance of these elements in practice. Here, the TOE framework could help a real project
198
Figure 9.4: Cumulative element scores per group, displayed in average normalized
scores
The contractors considered several aspects more complex than the owners: technical risks,
size in CAPEX, number of locations, and instability of the project environment. Apart from
the latter, these elements belong to the T-category, possibly suggesting that contractors by
their role have a narrower view on the project. Compare for example their assessment of
organizational risks with their assessment of technical risks; technical risks scored
considerably higher in their contribution to project complexity. That size in CAPEX is
valued as more complex by the contractors is probably related to their different reference:
the typical size of an owners project is probably considerably larger than the typical size of
a contractors project. Also the size of contractor companies, generally smaller than the size
of owner organizations, might play a role here. None of these elements, considered more
complex by the contractor than by the owner, made it to the top-3 of complexity elements.
199
So contractors do perceive some aspects in the project more complex than the owners do,
but these are not the most important aspects that determine project complexity in general.
9.4.3 How to deal with complexity?
For the top-3 of complexity elements in the T, O and E categories, results on how the
respondents would deal with those complexity elements are presented in Figure 9.5, Figure
9.6 and Figure 9.7. Results are normalized to the number of respondents actually answering
that question. Again, two groups were distinguished; owners and contractors. None of the
respondents indicated that no additional effort was spent to treat these complexity elements.
To investigate potentially different perspectives of project owners and contractors, again
Mann-Whitney tests were performed on the results. Only one significant difference
between owners and contractors was found: owners would more often apply stakeholder
management to treat non-alignment of project goals (Mann-Whitney U=77.5, z = -2.98,
p=.004). Although the other differences in assumed application of activities displayed in
Figure 9.5 to Figure 9.7 are statistically not significantly different between the owner and
contractor group, together they might indicate what could be the preferred approach of
owners and contractors in treating project complexity. Therefore the results are discussed
distinguishing the owner and contractor groups.
Figure 9.5 (how to deal with most contributing T-elements) shows that goal-setting and
alignment and stakeholder management would mostly be applied to treat non-alignment of
project goals or unclarity of project goals (both scored higher than 80%). To a lesser
extent, additional effort would be spent in project team building and risk management (4060% of the respondents). Stakeholder management would be applied more often amongst
the owner respondents: to deal with non-alignment of project goals they would spent more
effort in stakeholder management (next to spending more effort in goal-setting and
alignment). This suggests that the orientation of the owners generally is more externally
focussed (outside the project team) than the orientation of the contractors, who seem to be
more internally focussed. This suggestion is supported by the fact that teambuilding, more
internally focussed, was more often applied in the contractor group than in the owner
group. The contractors unanimously indicated they would apply goal-setting & alignment
to treat non-alignment of project goals (100%). Additional effort also would be spent in the
VIP risk management, both by owners and contractors (> 40%).
Uncertainties in scope would be treated by additional effort in goal setting & alignment,
risk management and value engineering. The percentages are considerably lower than for
treating unclarity of goals and non-alignment of project goals (about 60% for treating
uncertainties in scope). This suggests that the complexity aspect uncertainties in scope is
less obvious treatable with the current set of VIPs. For the contractors, also constructability
review is a way to deal with uncertainties in scope, this differs largely from the owners
view. In the open answers, performing scope reviews and putting effort in timely scope
alignment with the client was suggested (6 occurrences). The VIP value engineering is also
widely applied to treat uncertainties in scope (50% of the respondents).
200
Figure 9.5: How to deal with project complexity (%): most contributing T-elements
201
Figure 9.6 (how to deal with most contributing O-elements) shows that respondents were
less outspoken about how lack of resource and skills availability and high schedule drive
could be treated. Obviously, these elements are less directly related to the VIPs in the list,
which is also reflected by the relatively high number of answers in the category other for
treating a lack of resource and skills availability:
- Front-End Loading
- Develop alternative strategy
- Training
- Recruiting
- Train resources, execute elsewhere, modularize
- Resource management in time! Awareness of capacity on "external" market
- Pursue Company management to deliver the right people on the job
The majority of these answers point in the direction of improving resource management and
considering the whole project portfolio when assigning resources. For delivering the right
people on the job, it should be clear which competences and skills are needed for the
particular project (-task). The TOE framework could be used to characterize the expected
complexity areas as a first step in finding the right people. A VIP on this resource aspect
seems lacking: a new VIP could be developed on portfolio wide resource allocation, hence
explicitly linking the project to the companys project portfolio.
To treat a lack of trust in the project team, the respondents would most often apply the VIP
teambuilding (Figure 9.6). This was indicated by more than 80% of the respondents, both
owner respondents and contractor respondents. Also stakeholder management and goalsetting and alignment would be applied by more than 40% of the respondents.
To treat a high schedule drive, most often risk management would be applied (80% of the
respondents, both owner and contractor), followed by project team building and operations
implementation planning (Figure 9.6). Generally the percentages were high to treat this
complexity aspect. Contractor respondents would more often than owners apply external
benchmarking and to a lesser extent operations implementation planning, although these
differences were not statistically significant. The difference between owners and
contractors was largest for the VIP external benchmarking. This actually contradicts the
results in Chapter 8, where contractors did merely apply external benchmarking, if at all,
only because it was requested by the owner organizations for which they performed the
project. The contractor respondents in the current survey maybe hope that by external
benchmarking, it becomes clear that the schedule drive is unrealistically high.
202
Figure 9.6. How to deal with project complexity (%): most contributing O-elements
203
Figure 9.7: How to deal with project complexity (%): most contributing E-elements
204
Figure 9.7 (how to deal with most contributing E-elements) shows that to treat a variety of
stakeholders perspectives the dominant approach would be stakeholder management and
goal-setting and alignment (both about 80% of the respondents), without significant
differences between owner respondents and contractor respondents. These two VIPs would
also be most often applied to treat a lack of company internal support in view of the
respondents, but the percentages now are about 60%. Although the difference is not
significant, the owner respondents more often mentioned stakeholders management here,
again suggesting that the view of the project owners is more outwards oriented, e.g. outside
the project (not necessarily outside the company). Also additional effort would be spent in
the VIP risk management (>50% of the respondents).
Figure 9.7 also shows that about 70% of the respondents would apply constructability
reviews and operations implementation planning to treat interference with the existing site.
Next to application of these two VIPs, the owner respondents seem to prefer application of
goal setting and alignment, whereas the contractor respondents seem to prefer application
of lessons learned. Owners and contractors seem to have a very different view on how to
treat interference with the existing site. To treat a lack of experience in the country,
contractor respondents would also, more often than owners, apply lessons learned. Hence
for these two elements, the contractor respondents seem to favor the application of lessons
learned. Note that the total number of respondents (18) was relatively low for these two
complexity elements.
Overall looking at how the respondents would treat particular aspects of project complexity,
the VIPs goal setting & alignment, stakeholder management, risk management and project
team building would be most widely applied. The owner respondents would, more often
than the contractor respondents, apply stakeholder management. The contractor respondents
would, more often than the owners, spend additional effort on team building. Although
differences are only small, in the results an outward view of owners and a more inward
view of contractors can be recognized.
Recent IPA results showed the importance of having clear business objectives, team
integration, front-end loading (thorough definition before authorization) and continuity of
key persons in the project team (IPA, 2011). The results of our empirical study point in the
same direction.
9.4.4 Application of the TOE framework
The answers to the open question How would you apply the TOE framework in your daily
practice? provided very diverse insights. Often a link was made to risk management and
early project assessment, but owners and contractors expressed quite a different view on the
application of the TOE framework. To analyse the outcomes, we made a rough
classification, based on first interpretation of the data and similarities in the data.
Subsequently, all answers were assigned to the following categories, see also Table 9.7:
- Risk management (17 occurrences)
- Project assessment / checklist (17 occurrences)
- Team / stakeholders (12 occurrences)
- Not useful (3 occurrences)
- Not applicable (6 occurrences)
- Dont know (8 occurrences)
- Question not well understood (3 occurrences)
A few answers (2) covered more than one category and were attributed to more categories.
205
Owners responses
(N=40)
6
14
9
3
5
3
2
Contractors responses
(N=24)
11
3
3
0
1
5
1
The owners most often (14 times) indicated that the application of the TOE framework
could be to assess the expected complexity of a project upfront and define actions
accordingly:
- I would apply the TOE as early as possible in a project to analyse the "new" project.
- It may make it possible to quickly assess the complexity of a project and underlying
reason.
- "Per start of each project phase execute a TOE complexity assessment. Select the
major complications and define an action plan to decomplex."
The complexity framework would be used to determine the extent of the effort needed
at the right time (staged approach), to reduce complexity. So use it as a reference to
support decisions
In order to deal with the expected complexity, several owners seem to propose reduction of
complexity; compare for example with a more mechanic approach as described by Geraldi,
as opposed to their proposed organic approach (Geraldi, 2008a). With their process
management approach, De Bruijn and Ten Heuvelhof also favor a more organic approach
(de Bruijn & ten Heuvelhof, 2007). Rather than reducing complexity, they even propose to
expand complexity in the problem definition phase to solve a complex problem (p 76).
Reduction of complexity matches the traditional engineering solution that is based on a
preferred reductionist, analytical approach (Lintsen, 1985). However, awareness of the
complexity aspects in a project and preparation for treatment thereof already could help the
project, without explicitly reducing the complexity.
A few times the owners indicated that the TOE framework could be used to assess projects
at the early project stage and then linked this to risk management (6 times):
- Assessment of projects at early stage () to identify preventive actions for risk
mitigation.
- Identification of potential risks.
Here a link is perceived between risk management and the TOE framework. This link is
very strong within the contractor group, see discussion below.
Other owner respondents saw the application area for the TOE complexity framework in
alignment amongst the stakeholders and within the project team (9 times):
- During the starting of the project, for defining the scope and align stakeholders.
- Ensure alignment.
To achieve alignment amongst stakeholders and within the project team, application of the
TOE complexity framework is foreseen in early project phases.
206
Also more critical responses were obtained amongst the owners, like:
- We don't apply this framework at the moment! Everyone within the organization
should contribute to this system, maybe then it will work. It won't work if only Project
Management will be involved.
- Every project is different!! So different. Also changing in time for risk. You cannot
apply one matrix strategy!! Too simple. Experience, guts feeling, good leaders and
(sub)leaders in the disciplines are the key.
The first critical response indicates that for successful implementation of the TOE
complexity framework, wide company support is needed. To create this support, the value
of the framework should be clear to all involved. The potential value of the TOE
complexity framework is more thoroughly discussed in Section 9.4.5. Note that this
respondent had more than 20 years company experience and might have gained some
hesitance against new frameworks over the years. Also the second example of a critical
response comes from a very experienced person (over 25 years company experience). This
second response actually illustrates why this research was undertaken: no one approach
fits all, as was already stated in Chapter 1 of this dissertation. It was not the intention of
the TOE complexity framework to determine the single, universal complexity of the
project, but to identify the areas in which complexity can be expected to arise. Since this
will be different in the different project phases (see also Section 3.9.2), (different)
application of the framework in different project phases is foreseen.
The contractors responses on application of the TOE complexity framework were
dominated by the link with risk (11 times):
- Not sure if the framework is trying to analyse "complexity" itself or risk. In the
process industries the complexity of a project is a concern because of the inherent risks
involved and the large amounts of capital that are at stake.
- At project start for setting the goals and targets and continued during the project with
regular risk review sessions.
- As a reference, in addition to our existing management system. Also as a checklist for
risk management/execution planning.
- At start by providing input to the project execution plan followed by daily monitoring
of the key success and risk factors.
In view of the respondents, the TOE complexity framework could be used early in the
project as a sort of checklist to identify risks. The respondents seem to realize that the use
of the framework is not only beneficial in the early project phases, but also later during
project execution. Hence the results suggest that they recognize the dynamic character of
complexity; changing over time.
A checklist or guideline character of the TOE complexity framework was also expressed by
other contractor respondents (3 times):
- I would use it as a guideline to identify requirements and methods to mitigate the
effects that different complexity elements may have on my project.
- Prioritize on important issues, delegate.
Here the focus is on prioritization and mitigation.
The role of the TOE complexity framework for alignment also became apparent in the
contractors responses (3 times):
- By making sure that the project execution plan addresses the TOE items for that
specific project and that this is shared with the project team in project
review/engineering meetings
207
Owners responses
(N=40)
6
8
4
5
4
0
1
2
2
7
3
Contractors responses
(N=24)
2
4
0
3
3
3
2
2
1
5
1
As shown in Table 9.8, owners see the value of using the TOE complexity framework in
achieving better alignment in the team and better communication with stakeholders:
- To appoint the project risks in a structured way and translate these to the project
team, so everybody in the team has the same understanding.
208
respondents did not know the answer on this question. The 12 dont knows show that the
potential value of the TOE complexity framework should be made more clear to potential
users, to increase the chance of successful application in future. Generally, the project
owner respondents seem to have a broader and more positive view on the value of the
complexity framework, they seem to be more receptive than the contractor respondents.
This is illustrated by the higher number of counts (also relative) on the value of the TOE
framework in better alignment, a more structured approach or supporting stakeholder
communication. By their traditional role, owners might be more interested in the broader
design of the project, whereas the contractors in their traditional role are the performers
rather than the designers (note that our research, however, favours an integrated approach,
see Chapter 8).
Although the TOE complexity framework could create awareness for expected
complexities (or complexity areas) in a project amongst the different parties involved, just
delivering a tool never should be the ultimate goal. In the end, more important is the actual
application, which should be done by the people in the project and hence is determined by
aspects like company culture, perceived value, availability / adoption / diffusion in the
company and incentives for use. The people in the project are the ones that deliver, which
was stressed throughout in this dissertation. As said by one of the owner respondents in this
Chapters survey on the value of the TOE framework: () people make and break
projects.
9.4.6 Further development of the TOE complexity framework
About half of the respondents provided suggestions for further development of the TOE
complexity framework. These valuable suggestions were categorized in content
suggestions, application suggestions and dissemination suggestions.
Content suggestions
Regarding the content of the TOE complexity framework, it was suggested to better explain
what T, O and E stands for, including theoretical background on the definition of
complexity. Also some suggestions were done for adding elements or refining elements,
such as adding a complexity element on subcontracting schemes involved in the project.
Dissemination suggestions
To disseminate the current results and improve the likelihood of application in real projects,
it was suggested to develop a visual impression of the TOE complexity framework. Such a
visual impression of the TOE framework is presented in Section 9.5.1.
Application suggestions
For application of the TOE complexity framework, it was suggested to develop a database
of example projects, to enable benchmarking of projects. This could be within the sector,
but also wider across sectors: it was also suggested to compare different sectors (chemical,
IT, aerospace, ) to see if the criteria or weights of certain complexity elements would
change. The suggestion to align the application of the TOE complexity framework with
PDRI (Project Definition Rating Index, see also Chapter 2) was also in the field of
benchmarking. Alignment with project risk review sessions was also suggested, next to
expansion of the TOE complexity framework towards management actions to be taken to
() reduce the impact of the most relevant complexity elements. More respondents
focused on the most relevant complexity elements and openness on how to deal with these
elements; it was suggested to focus on () common dominators and learn from each
210
others methodology to tackle the related project risks and improve the project result. In
their view, the Holy Grail would be the generation of a sort of algorithm that can be used
in project practice to make project assessments, e.g. based on a complexity footprint the
suitable management approach (application of certain VIPs) is defined. Finally, the
outcome of a TOE complexity assessment was suggested to be linked to the contract
format: who will bear the risks related to those identified complexities?
These suggestions are taken into account for further and future developments of the TOE
complexity framework, see Section 9.5.5.
Next to the suggestions described above, some generally interesting remarks were received.
The first shows the perceived close link with risk management:
Looking at your questions with respect to VIPs it further suggests to me that you are really
using the framework for risk management. All projects in the process industries are
"complex" to a greater or lesser degree. The important question for investors and
contractors is to identify the risks resulting from this inherent complexity and having a
structured program to manage them.
The respondent is right in his statement that projects in the process industry are complex
to a greater or lesser degree. Also his conclusion, that it is about identifying risks that stem
from the expected complexities in the project, is right. The TOE framework in that sense
could be seen as an extensive list with potential risk categories / areas. However, the
framework is meant to be applied also broader than just directly related to risk
management.
A second remark shows that indeed it is not about just applying the TOE complexity
framework and in order to solve all project problems:
The TOE framework is not a miracle in resolving complex issues on projects but should be
seen as a tool to help on projects. It remains a tool and is not the almighty way to success.
Common sense and applying in a fit-for-purpose way the general Project Execution
Practices should not be forgotten
Indeed, the TOE complexity framework can be a starting point for complexity assessment,
a sort of checklist to identify complexity areas, but if no action is undertaken to treat those
identified elements or areas, it cannot be beneficial for the project.
A third and final remark actually shows why this type of research still is relevant:
I do not see what is new here. () the TOE framework seems to be a Risk Management
Framework with a different name, combined with strategies to mitigate the risks. This is
applied by all companies already.
This response was cited from a contractor respondent with 5-10 years company experience.
Our reply to this comment expresses a different view. First of all, the TOE framework is
aimed to be broader than just a risk management framework. And second, even if such risk
management framework were already available, the current dissertation (Chapter 7) shows
that proper risk management is not yet commonly applied in about half of the projects
under investigation.
Also it was investigated how project managers would treat most contributing complexity
elements and how perspectives of actors involved would differ in complexity assessment
and treatment of project complexity. Finally, it was studied how a project manager would
use the TOE framework, what could be the value of using the framework and how it could
be further developed. These aspects are discussed in more detail subsequently.
9.5.1 The TOE complexity framework
This chapter presented a thorough evaluation of the TOE complexity framework. The TOE
complexity framework contains 47 elements in 3 categories: Technical, Organizational and
External. According to the 64 respondents, of which 40 owner respondents and 24
contractor respondents, the elements most contributing to project complexity in the Tcategory were non-alignment of project goals, uncertainties in project scope and unclarity
of project goals. The elements most contributing to project complexity in the O-category
were a lack of resource and skills availability, a lack of trust in the project team and a high
schedule drive. The elements most contributing to project complexity in the E-category
were a variety of stakeholders perspectives, a lack of company internal support,
interference with existing site and a lack of experience in the country. Amongst the
elements most contributing to project complexity, there were several elements related to
standard project management (goal / scope / resources / stakeholders, compare with
Turners definition of the functions of project management (Turner, 2008), but also the
concept of trust seems important. Dealing with these complexity elements, if they occur in
the project, might get extra focus (although the other elements should not be forgotten). If
any priorities have to be set, (executive-) training could start with dealing with these most
contributing complexity elements. Since the vast majority of the elements in the TOE
framework were clearly recognized as contributing to project complexity, training on
dealing with the other elements should follow.
What extra information did we obtain in this chapter, compared to the results of Chapter 6
(Table 6.8)? We found evidence that all TOE elements indeed are relevant in determining
project complexity in the different aspects, except for the elements different time-zones,
number of different nationalities and weather conditions. More than 50% of the
respondents indicated that these three elements were least contributing to project
complexity in their perspective. The presence of the element weather conditions in the
framework was based on earlier empirical evidence only, whereas for the other two
elements also literature evidence was found (see Table 4.4). Because the subsequent
empirical analysis described in this chapter did not confirm the earlier empirical work, it
was decided to remove the element weather conditions from the TOE framework. The other
elements are kept in the TOE framework. Additional analysis of the Chapter 6 results also
indicated the suggested relevance of the element contract type, which was therefore added
to the final framework.
A visual impression of the TOE complexity framework is given in Figure 9.8. The check
boxes allow for indication of the relevance, for the project under consideration.
212
The owner respondents would, more often than the contractor respondents, apply
stakeholder management. This is supporting the Chapter 7 results, which also showed that
owners applied more stakeholder management than the (sub)contractors. Also, the
contractor respondents would, more often than the owner respondents, apply project team
building to treat aspects of project complexity. This also links to the importance of
integrated teams, as argued in Chapter 8. Future research could focus on treating particular
aspects of project complexity, paying additional attention to different preferred
management styles of project owners (outward oriented?) and contractors (more inward
oriented?).
9.5.3 An owners perspective versus a contractors perspective?
Not only did owner respondents and contractor respondents show a different perspective on
how to treat particular aspects of project complexity, also significant differences were
observed (based on a Mann-Whitney distribution test) in their opinion on the extent
elements would contribute to the complexity of the project. Remarkable differences were
found; particularly since some of them appear in the top-3 of elements that would most
contribute to project complexity overall: unclarity of project goals and variety of
stakeholders perspectives. In the Chapter 7 survey results (Table 7.12) no significant
differences were found for these complexity elements between the owners and the
contractors, but this might be related to the limitation of including managing contractors
and engineering contractors in one group.
Earlier work of Bakker et al. concluded the presence of inward and outwards contractor
perspectives as well as an outward owner perspective (Bakker et al., 2010). The current
study also suggests the existence of a different focus amongst these groups with, in our
case, outward oriented owners and inward oriented contractors. Other literature also
reported differences in client versus contractor perspectives (Bryde & Robinson, 2005). In
their study on project success criteria in the UK construction industry, they found that
clients were more focused on satisfying the needs of other stakeholders (e.g. externally
oriented) and contractors were more focused on minimizing project cost and duration (e.g.
internally oriented).
This finding on the presence of different perspectives is very relevant, since this will
influence the relation between an owner and a contractor. Using the framework to make a
complexity footprint of a project by both parties might highlight such perspective
differences.
9.5.4 Foreseen use of the framework
Based on the suggestions obtained in the 64 responses on this survey and on earlier ideas,
use of the framework could be as follows. In the very early project phase, even before a
project manager is appointed, the line manager sits together with a resource manager and
they try to assess the complexity of the project under development. Depending on where
they expect project complexity, they select an available project manager. This project
manager also starts his/her assignment by completing the TOE complexity framework for
the particular project: in which areas could complexity be expected? This complexity
footprint is carved in sand rather than set in stone; it will change throughout the different
project phases.
The project manager composes the project team based on the early complexity assessment
and also uses the complexity assessment as preparation for an initial risk workshop as the
214
TOE framework provides an extensive list of categories were risks could be expected. The
application of the TOE framework, however, is not limited to identifying risks. The
exercise of completing the framework in the different project phases can stimulate team
integration and facilitate discussion and communication in the project team and amongst
relevant stakeholders. The result of the TOE complexity assessment could be used for
stakeholder management, risk management, monitoring & control, etc. A structured
approach to create awareness for the foreseen complexities seems beneficial for broad
alignment amongst the relevant stakeholders, hence positively contributing to project
performance.
Ideally, the TOE complexity assessment could become a part of a company project
management guideline. To account for the dynamics of project complexity, the TOE
complexity assessment could be done at distinct point in the project life-cycle (to be
determined in the FED phase, like for all VIPs), in order to be prepared as much as possible
for the next phase.
This foreseen use of the framework is aligned with the conclusions of Chapter 6 on the
application of the TOE framework: to support project management, to create awareness
amongst stakeholders and to be used during different project phases.
9.5.5 Further development of the TOE framework
To use the current TOE complexity framework in actual project management, some further
development of the framework would be needed. In the current situation, respondents could
only very subjectively indicate to what extent an element would contribute to a projects
complexity. To improve this situation, a clear scale could be developed for all elements of
the TOE complexity framework to allow for comparing project complexity footprints
across projects. Should this improved scale have absolute or relative measures?
For the improved TOE elements scales, we suggest still relative (and hence by definition
subjective) measures, rather than absolute measures. How companies and people perceive
project complexity is heavily influenced by, for example, their company characteristics and
previous experience. A project that is highly complex for a small inexperienced company
might be not complex at all for a very large experienced company. In our view, relative
measures would serve best the ultimate goal of the TOE framework to grasp project
complexity, which is supporting the management of a specific project in dealing with
particular complexities / complexity areas.
Based on scores in certain complexity areas, preferred management actions could be further
investigated. And finally, also expansion towards other types of projects and industry
sectors should be considered.
215
216
Chapter 10
Discussion, conclusions and recommendations
In this concluding chapter, we summarize our contribution to the improvement of project
management practice and hope to stimulate the on-going scientific debate in the field of
project management. Throughout the study, several issues were raised which need some
additional thoughts. These issues are taken care of in the discussion in Section 10.1.
Subsequently Section 10.2 presents the conclusions of this PhD work. Finally, Section 10.3
gives suggestions for application of the results in practice and, last but not least,
recommendations on directions for further research.
10.1 Discussion
In this discussion section, the validity of the research is discussed, including some
comments on the use of mixed research methods in the current research. Next, our scientific
contribution is summarized, after which the limitations of the research are made explicit.
10.1.1 Validity of the current research
To assess the validity of the total research design, the concepts of construct validity,
internal validity, external validity and reliability were addressed (Blaikie, 2009; Tashakkori
& Teddlie, 1998; Yin, 2002). To start with the latter, the concept of reliability (the study
could be repeated with the same results) was ensured by developing case study protocols,
recording interview data, storing all case study results in databases and storage of the
survey data files and relevant computations in the form of scripts. This mainly ensured
repeatability of the analysis, but also repeatability of the data collection was given thorough
attention by the case study protocol. However, interviews by definition are non-repeatable
since respondents are biased after the first interview.
The external validity (the domain to which the findings can be generalized) originally was a
concern, because of the specific character of the projects under consideration. By
expanding the unit of analysis in the fourth phase from specific projects in a specific
company to the particular sector, the external validity was broadened from company
specific in Phase I towards sector specific in Phase IV. To illustrate the broader domain
coverage, Figure 10.1 shows how the data was collected from the different companies and
respondents in the NAP network across the four project phases.
Phase I involved only one company and 18 respondents. None of the Phase I respondents
were involved in Phase II, but the company was. The exact number of different companies
involved in Phase II is not known, since providing the company background was not
obligatory. Based on the respondents contact details (if available), respondents from at
least 25 companies participated in Phase II. Based on the Phase II sample, the companies
and cases for Phase III were selected: one case was from outside the Phase II results but
from within the NAP network. Finally, in Phase IV, four NAP companies were involved,
from which two were also involved in Phase III. Only some of the Phase IV respondents
were involved in Phase II.
217
Figure 10.1: Data collection within the NAP network overview of responses
So in our research, we broadened our focus from one company to the complete NAP
network. The results of the current study are therefore assumed generalizable to similar
engineering projects with comparable project management tradition and project
management approaches.
The internal validity (are causal relationships found indeed caused by the factors studied)
only was a concern in those parts of the study with a more explanatory character, hence
Phase II and to a lesser extent Phase IV. Because of dataset limitations, we carefully
formulated our conclusions and clearly stressed the necessity to gather more project data to
more firmly underpin the current results.
The construct validity (do we use the correct operational measures to study the concept: do
we measure what we intend to measure?) was ensured by asking the participants in the case
study to review and approve the interview reports. Multiple sources of evidence were
included by interviewing more than one key person per project. Also, company sensitive
information was made anonymous thereby enabling other researchers to feedback on the
research. In the interviews, the opinion of the interviewees on the concept(s) under
discussion was explicitly asked for and taken into account during the analysis. In the
surveys, control questions were included to strengthen the construct validity.
Overall, extensive use was made of triangulation (Yin, 2002): triangulation in the sense of
data sources, triangulation in the sense of involving participants with different roles in
projects, and triangulation in the sense of using multiple methods. Starting qualitatively to
build the framework (Chapter 3, Chapter 4), the research progressed with a more
quantitatively oriented evaluation of this framework (Chapter 5, Chapter 6, Chapter 7),
subsequently dived into an in-depth understanding of certain activities of the front-end
phase (Chapter 8) and concluded with the final evaluation of the TOE complexity
framework that was both quantitative and qualitative (Chapter 9). Actually, this research
widely applied a mixed methodology approach (Tashakkori & Teddlie, 1998), combining
qualitative and quantitative methods.
218
What did this mixed-methods approach bring us? Whereas pure positivists favour
quantitative methods, pure constructivists favour qualitative methods (Tashakkori &
Teddlie, 1998). As indicated in Chapter 1, the current research aimed to follow a
constructivist approach in which positivist elements were embedded, in other words,
applying qualitative methods as well as quantitative methods. Indeed, these different
methods were applied; both with specific aims but also to overall strengthen the results. To
give an example of the specific aims of the different research methods: Chapter 7 identified
which relations were present between certain front-end activities, project complexity and
project performance (descriptive question, quantitative approach) and the subsequent
Chapter 8 aimed at investigating how certain front-end activities were contributing to
project performance (explanatory question, qualitative approach). And to give also an
example of results that were strengthened because they were confirmed by multiple
sources: the importance of integrated teams was concluded from the Chapter 3 case studies,
as well as from the Chapter 8 case studies. By applying mixed-methods in our study, a rich
set of results has been gathered with scientific value, as is discussed subsequently.
10.1.2 Scientific contribution
Our research made several scientific contributions. In their editorial in the special issue of
Research Policy on innovation in complex products and systems, Hobday, Rush and Tidd
posed the question: What do we know about best practices in the management of
CoPS? (Hobday et al., 2000), p.797. Our study at least partly answers this question. We
investigated the application of Value Improving Practices (or best practices) in projects in
the Dutch process industry and found benefits of some of these VIPs. We concluded
however that applying VIPs is necessary but not necessarily sufficient: also how and by
whom VIPs are applied is crucial in the successful execution of CoPS projects. Our study
confirms the overall importance of the early project phases (Artto et al., 2001; Flyvbjerg et
al., 2003; Morris, 1994; Morris et al., 2006a; Thamhain & Wilemon, 1975).
In developing the TOE framework, we consciously build upon earlier work. In the nineties,
project complexity was already taken as one of the factors to classify engineering projects
(Shenhar, 1998, 2001; Shenhar & Dvir, 1996). They developed a classification method
based on four levels of technological uncertainty and three levels of system scope
(complexity). This complexity, however, was treated as a sort of black box. Our study
opened this black box by identifying project complexity factors from various and different
sources and perspectives, resulting in a rich framework to grasp project complexity.
Different than Shenhar and others (Halman, 1994; Pich et al., 2002; Sommer & Loch,
2004), we did not place complexity next to uncertainty, but we consider uncertainties as
factors (seriously) contributing to project complexity.
Looking back at the overview of project management research (Sderlund, 2011), see also
Section 2.3, our research breaths the influence of different schools in project management.
The factor school is recognized in our narrow success definition and investigations towards
success factors in projects. The decision school is recognized in our focus on the early
project phases. The behaviour school is recognized in our focus on the people factor and
the importance of integrated teams. Finally, the contingency school is recognized in our
focus on the projects environment and our choice for investigating project complexity as a
possible contingency factor for project management in early project phases. Our study
successfully integrated different research approaches (both qualitative and quantitative), not
limited to one particular school, hence embracing the desired pluralism.
219
220
10.2 Conclusions
The conclusions are presented by first answering the research questions, followed by some
overall conclusions not necessarily linked to the research questions.
10.2.1 Answers to the research questions
In this dissertation, the main research question to be answered was:
How could the front-end phase be adapted to the projects complexity in order to improve
project performance?
In order to find the answer to this question, several sub-questions were defined, which are
answered subsequently. After the answers to the sub-questions, we return to the main
research question.
1. What is project complexity as experienced by project professionals?
From Chapter 3, it was concluded that various aspects contributed to the complexity of the
projects under investigation (as summarized in Section 3.8.1). In view of these Phase I
interviewees, organizational complexity prevailed over external complexity and technical
complexity. It was concluded that the technically well-educated interviewees were well
prepared to deal with technical complexities, did recognize external complexities to a lesser
extent and particularly faced organizational complexities in their project. Working with a
joint venture (JV) partner considerably contributed to organizational complexity, in their
view. We proposed to categorize project complexity in technical, organizational and
external complexity and these categories were very differently scored per project by the
vast majority of the interviewees, hence indicating the importance and usefulness of using a
project complexity measure consisting of these multiple categories. Project complexity was
shown to be a subjective concept and highly dynamic. Both findings have consequences:
discussion amongst the relevant stakeholders is required when assessing project complexity
and the evolution of the complexity of a project should be regularly reviewed during the
project life cycle.
As shown in Table 6.5, Table 6.6 and Table 6.7, the Phase II survey resulted in several
significant relations between the complexity elements and respondents perceptions of
technical, organizational and external complexity. The perceptions of the respondents,
however, were often implications or consequences of project complexity, and not the
causes we were looking for. Often, respondents perceived organizational complexity, not
only as a consequence of organizational causes, but also of technical and external causes.
In view of the Phase IV respondents (Chapter 9), aspects most contributing to complexity
were non-alignment of project goals, unclarity of project goals, uncertainties in scope, high
project schedule drive, lack of resources and skills availability, lack of trust in the project
team, variety of stakeholders perspectives, lack of company internal support, interference
with existing site and lack of experience in the country, as demonstrated in Table 9.4.
Significantly different perceptions were found between contractor respondents and project
owner respondents on the complexity elements: unclarity of project goals and variety of
stakeholders perspectives, which needs attention because these elements were also
amongst those elements most contributing to project complexity, in view of all respondents.
221
Chapter 7 also investigated whether and how the role of the respondent (in team role and
company role) would have had an influence on the survey findings. Some important
different opinions between project managers, team members and business representatives
were found in the field of goal setting and alignment, team cohesion and selection of the
project manager. Between contractors and owners, the most important difference found was
in the value improving practice operations implementation planning. This VIP was
perceived to be more beneficial and more sufficiently applied in view of the project owners,
which seems inherently related to their different roles.
Chapter 9 (Phase IV) also resulted in relevant front-end activities to treat project
complexity (Figure 9.5, Figure 9.6 and Figure 9.7). It seems that the value improving
practices goal setting & alignment, stakeholder management, risk management and project
team building would be most widely applied. The owner respondents would, more often
than the contractor respondents, apply stakeholder management. This is supporting the
Chapter 7 results, which also showed that owners applied more stakeholder management
than the (sub)contractors. Also, the contractor respondents would, more often than the
owner respondents, apply project team building to treat aspects of project complexity. For
the complexity element a lack of resources and skills availability no particular VIP was
available, see also the recommendations in Section 10.3.2.
5. How do front-end activities contribute to better project performance?
From the Phase II results, it was concluded that applying front-end activities was beneficial
to project performance using a high level 2x2 matrix. To resolve which activities
particularly contributed to better project performance, detailed analysis was carried out
which suggested the importance of:
- Goal alignment between business and project team
- Applying operations implementation planning
- Applying external benchmarking
- Adequate contract type in co-operation with (sub)contractors
These activities were shown to be important regardless of complexity type. To answer more
specifically how these activities contributed to better project performance, additional case
studies were performed in Chapter 8 (Phase III). From Chapter 8, it was concluded that
how one applies (and with whom) certain front-end activities is relevant. It seems that
project performance benefits from joint effort (by an integrated project team, composed of
owner employees and contractor employees) in performing front-end activities for
technically complex projects. How you apply these, seems more important than that you
apply them (in other words: application as such is beneficial, but not sufficient). Here the
role of integrated teams is a crucial one: integration in terms of involving all relevant
parties in the team (owner and contractor, but also different departments within a company)
and also integration in terms of resource continuity throughout the different project phases
(researchers as well as operations people). Integrated teams have short communication
lines, which enable efficient decision making and potentially avoid major late scope
changes.
6.
How can contingency theory be used to fit the front-end phase to the complexity of a
project?
In Chapter 7 (Phase III) the application of contingency theory to project management was
explored by investigating the relations between project complexity, front-end activities and
project performance with project complexity as a contingency factor. Results of this
exploration indeed suggest that with particular complexities, spending more effort in
223
224
studies (Chapter 8) and was also explicitly mentioned in the survey responses of the fourth
phase (Chapter 9).
The importance of integrated teams, in which owner employees and contractor employees
work closely together became clear already from case 1 in Chapter 3 onwards. An
integrated team enabled alignment amongst the parties, stimulated constructive debate and
facilitated adequate scope definition as well as early scope changes, if needed, as opposed
to late scope changes that are known to cause project delays (Love et al., 2002). Such an
integrated team is preferably even physically integrated in terms of using the same project
office. How integrated teams and long term relationships can be stimulated by the choice of
certain contract types is one of the future research opportunities, see Section 10.3.2.
One of the observations in this dissertation is that project professionals seem well aware of
what could contribute to improve project performance, but this does not imply they actually
apply it in their projects (Chapter 7). Hence major improvement could potentially be
achieved by actually applying risk management, operations implementation planning and
external benchmarking, hence just practice what you preach. Our findings are supporting
recent literature findings that the project management practices that actually can make the
difference are not necessarily those most widely applied (Papke-Shields et al., 2010)
Risk management proved to be an important, but neglected front-end activity in our
researched cases and survey data. Although respondents in the survey (Chapter 7) did see
the importance of risk management, it was applied as often as not. Also the Chapter 8
findings indicate that currently, risk management often stops after (thorough) risk
identification. To beneficially contribute to project performance, risks could be better
managed by appointing risk owners, defining appropriate risk mitigation and active risk
monitoring.
Generally, engineers seem well capable of dealing with technical complexity (Chapter 3,
Chapter 6). They seem to have more difficulties in dealing with organizational complexities
or, even more distant, external complexities. The TOE framework, which aims to grasp
project complexity, at least helps them recognizing the different complexity aspects that
might appear in their projects and suggests taking actions accordingly (like inclusion of
colleagues with complementary competences in the team, see also Section 10.3.1).
Finally, we conclude that our findings throughout confirm the broadening trend of project
management beyond the old control perspective (Pollack, 2007). Amongst the front-end
activities significantly contributing to project performance, dominantly process oriented
activities were found, aiming at for example alignment amongst different stakeholders,
increasing shared understanding and team integration. Also in the application of the TOE
framework, we foresee a broach approach: rather than aiming to fully predict and control
the complexities that will arise, the aim is to prepare the project team for what complexities
might arise.
225
10.3 Recommendations
This section presents the recommendations of the research. First the recommendations for
use of the results in practice are provided, followed by recommendations for further
research.
10.3.1 Recommendations for use of the results in project practice
To translate the above conclusions specifically for project managers and other
professionals, this section provides a summary of the project managerial implications: how
to use results of the current study in project practice?
Early in a project, a complexity footprint could be defined using the TOE framework,
indicating in which areas and from which sources complexity can be expected in the
project. Preferably both project owners and contractors are present when determining the
expected project complexity, as well as the project manager and team members, thereby
stimulating a constructive dialogue. Based upon the composed complexity footprint, the
additional (and kind of) effort in specific front-end activities could be determined. For
example, using Figure 7.3 and Figure 7.4 of this dissertation, in case of a technically
complex project, specific attention could be paid to goal setting, alignment & monitoring,
risk management, and timely involvement of the stakeholders. In case of an
organizationally complex project, specific attention could be paid to goal setting and
alignment, timely involvement of the stakeholders and aspects of team building. In case of
a project with expected external complexity, specific attention could be paid to risk
management and, again, aspects of team building.
If possible, organize the project work in integrated teams, consisting of both owner and
contractor staff. Next, decide on joined work practices as the first action of the integrated
team.
A simple aspect like putting the project team physically together could already be beneficial
as was learnt from one of the cases in Chapter 3. To positively influence team-building, key
activities like goal setting should be performed in a joint setting. Such a joint setting, in
which different viewpoints are taken seriously, stimulates constructive discussions and
reduces the chance of negative surprises in the project.
Because of the dynamic character of project complexity, complexity assessment could be
repeated at every stage gate. Over the different project phases, the complexity of the project
is likely to change, not only in amount, but also in area.
Without awareness of potential complexity areas, one cannot properly prepare for them.
Similar to the development of modern management of projects, broader and away from the
traditional control connotation of project management, our research showed that more
focus is needed to the other-than-control aspects of project management such as people
management and process management. In earlier research (Arkesteijn, 2009), however, it
was shown that amongst 38 project managers, particularly the less experienced ones tended
to rely on the traditional control project management style.
Anecdotal evidence might support the above. Think of a simple renovation project
consisting of some painting and some new furnishing in an office building. Technically all
clear and easy going, which would ask for a junior project manager. But then look at the
other aspects: the building is a very prominent one (company internal strategic pressure is
high) and should be partly available during the renovation (lots of interference with existing
226
site), and the project has a very tight schedule (strict high project schedule drive). With
these aspects (from the TOE framework) on the table, what kind of project manager would
you appoint?
10.3.2 Research recommendations
This research resulted, amongst others, in a framework to grasp project complexity of
engineering projects in the Dutch process industry. How this framework could be applied
for different types of projects, in the same sector or in different sectors, provides research
opportunities for the next couple of years. A first attempt was already made by Wentink in
2010, who under our supervision investigated how the TOE framework could be applied for
maintenance projects in the oil and gas sector executed by a contractor in the refining
industry in Singapore (Wentink, 2010). His work showed indeed the application potential
of the framework and the extension possibilities towards different types of projects.
Currently, research initiatives are undertaken to investigate how the TOE framework can be
applied in different sectors, such as the ICT sector and high-end manufacturing equipment.
Such initiatives could be broadened for example towards innovation projects, construction
projects, infrastructure projects, new product development projects, etc. Based on the
findings, the TOE framework could be further shaped and developed. Generally, more data
could be gathered by repeating the current surveys in broader audience, in order to find
more significant relations between project complexity, front-end activities and project
performance.
Particularly the link with innovation projects would be interesting to investigate because of
the cross-fertilisation of innovation management and project management as observed
during the latest IRNOP conference (IRNOP-X, Montreal, June 2011). This trend is also
stressed by recent literature, that suggests that a modern project approach based on systems
thinking is also beneficial for innovation projects (Kapsali, 2011): it provides the flexibility
to manage innovativeness, complexity and uncertainty in innovation projects more
successfully (p. 396). How could we therefore link the results of the current research to
management of innovation projects? In studying potential contingency factors in Chapter 2,
we came already across Balachandra and Friar, who identified the following contextual
variables: nature of the innovation, nature of the market, nature of the technology
(Balachandra & Friar, 1997). Adapting the management approach to the value of these
variables would be beneficially contributing to project performance. By choosing project
complexity as the contingency factor in our research, e.g. the factor on which we propose to
adapt the front-end phase of a project (Chapter 2), in fact we consider project complexity as
another -additional- contextual variable. Such a contextual approach in innovation
management is suggested by academics from innovation management as well (Ortt & van
der Duin, 2008). Then a relevant question is whether project complexity in innovation
projects can be grasped by the TOE complexity framework, as developed in this study.
Product complexity and process complexity would need explicit attention and additional
research, but aspects of both are already in the current set of framework elements.
Subsequently, managing (or preparing for) the particular complexities in innovation
projects needs investigation.
Although the dynamics of project complexity was investigated generally in the exploratory
case studies in Chapter 3, all individual elements of the resulting TOE framework (Figure
9.8) could have a dynamic character: some will be more present in early project phases,
some will be more present in later project phases. To investigate the dynamics of project
complexity in more detail, subsequent longitudinal research would be required.
227
The completeness of the TOE complexity framework was checked twice in the research,
but as time progresses, new elements might be discovered causing project complexity from
technical, organizational or external sources, or even from undisclosed sources. As the
social impact of projects increases, responsibility aspects might become more relevant and
some sort of social or moral complexity could become a fourth complexity dimension.
Future developments of the project complexity framework will take into account as much
as possible new insights, given the specific application areas.
From Chapter 9, preferred management approaches were distilled about dealing with
certain types of project complexity, very roughly. An example of dealing with certain types
of project complexity would be to select a project manager based on the particular project
complexity. Research to match the project managers competences towards the specific
expected project complexity was already initiated (Bosch-Rekveldt et al., 2009b; Vonk
Noordegraaf, 2011) and could be further extended.
A lack of resource and skills availability was indicated as one of the most contributing
elements to project complexity. To be able to manage this aspect of project complexity, just
looking at the single project is not sufficient: the whole portfolio of projects in a company
should be taken into account from a resource point of view. We therefore support recent
literature trends to more explicitly look at project portfolio management (Laslo, 2010;
Meskendahl, 2010), and focus future research not solely, but also in the direction of project
portfolio management.
The current research was explicitly focused on the front-end development phase of projects,
particularly on the extra activities (value improving practices). It assumed that the frontend basic activities were all performed well, which might be too positive and requests
further research and follow-up research on the 2008 NAP Special Interest Group on FrontEnd Loading (Oosterhuis et al., 2008). Besides, if thorough front-end development is
followed by poor project execution, the value of the front-end is rather limited. Thorough
front-end development could be seen as a necessary, but not sufficient condition for good
project performance. Therefore, future research could be focussed on more deeply
investigating potential links between thorough front-end development and poor project
execution. In this research also the process content of the front-end development phase
could be more deeply investigated: what are other ways to improve project performance?
One of the conclusions of the research was that integrated project teams, in which there is
close collaboration between project owner and project contractor, are an important means to
improve project performance. How the contract type can stimulate integrated project teams
would be worth to investigate. Also the role of trust in this, and how long term
relationships, or partnerships, can be successfully established and contribute to project
performance is an area for further research, which is presently being undertaken at the Delft
Centre for Project Management.
228
References
Aaltonen, K., Jaakko, K., & Tuomas, O. 2008. Stakeholder salience in global projects.
International Journal of Project Management, 26(5): 509-516.
Achterkamp, M. C., & Vos, J. F. J. 2008. Investigating the use of the stakeholder notion in
project management literature, a meta-analysis. International Journal of Project
Management, 26(7): 749-757.
Altman, D. G. 1991. Practical Statistics for Medical Research. London: Chapman & Hall.
Anderson, S. D., Patil, S. S., Gibson, J. G. E., & Sullivan, G. R. 2004. Owner-Contractor
work structures: process approach. Journal of Construction Engineering and
Management, 130(5): 680-690.
Antoniadis, D. N., Edum-Fotwe, F. T., & Thorpe, A. 2011. Socio-organo complexity and
project performance. International Journal of Project Management, In press:
doi:10.1016/j.ijproman.2011.1002.1006.
Arkesteijn, R. 2009. Present perspectives on project success. Unpublished MSc, Delft
University of Technology, Delft.
Artto, K. A., Lehtonen, J., & Saranen, J. 2001. Managing projects front-end: incorporating
a strategic early view to project management with simulation. International
Journal of Project Management, 19(5): 255-264.
Artto, K. A., & Wikstrm, K. 2005. What is project business. International Journal of
Project Management, 23(5): 343-353.
Ashby, W. R. 1957. An Introduction to Cybernetics. London: Chapman & Hall Ltd.
Atkinson, R., Crawford, L., & Ward, S. 2006. Fundamental uncertainties in projects and the
scope of project management. International Journal of Project Management,
24(8): 687-698.
Baarda, D. B., & de Goede, M. P. M. 2006. Basisboek Methoden en Technieken.
Groningen: Wolters-Noordhoff.
Baccarini, D. 1996. The concept of project complexity - a review. International Journal of
Project Management, 14(4): 201-204.
Baiden, B. K., & Price, A. D. F. 2011. The effect of integration on project delivery team
effectiveness. International Journal of Project Management, 29(2): 129-136.
Bakker, H., Arkesteijn, R., Bosch-Rekveldt, M., & Mooi, H. 2010. Project success from the
perspective of owners and contractors in the process industry, IPMA 24th World
Congress. Istanbul.
Bakker, H. L. M. 2008. Management of Projects: a People Process (inaugural adress).
Delft: Delft University of Technology.
Balachandra, R., & Friar, J. H. 1997. Factors for success in R&D projects and new product
innovation: A contextual framework. IEEE Transactions on Engineering
Management, 44(3): 276-287.
Barlow, J. 2000. Innovation and learning in complex offshore construction projects.
Research Policy, 29(7-8): 973-989.
Birol, F. 2006. World Energy Outlook 2006. In R. Priddle (Ed.). Paris: OECD /
International Energy Agency.
Blaikie, N. 2009. Designing Social Research (2nd ed.). Cambridge: Polity Press.
Bosch-Rekveldt, M. G. C., Hermanides, S., Mooi, H. G., Bakker, H. L. M., & Verbraeck,
A. 2010a. The influence of project front end management and project complexity
on project success - A contingency approach in project management research, PMI
Research and Education Conference 11-14 July 2010. Washington.
229
Bosch-Rekveldt, M. G. C., Jongkind, Y., Bakker, H. L. M., Mooi, H. G., & Verbraeck, A.
2011a. Grasping project complexity in large engineering projects. International
Journal of Project Management, 29(6).
Bosch-Rekveldt, M. G. C., & Mooi, H. G. 2008. Research into project complexity
classification methods. In A. Valenti, & V. Massari (Eds.), IPMA 22nd World
Congress 2008, Vol. 1: 104 -108. Rome: Animp Servizi Srl
Bosch-Rekveldt, M. G. C., Mooi, H. G., Bakker, H. L. M., & Verbraeck, A. 2010b.
Evaluating a complexity framework - a practitioners view on project complexity,
IPMA 24th World Congress. Istanbul.
Bosch-Rekveldt, M. G. C., Mooi, H. G., Bakker, H. L. M., & Verbraeck, A. 2011b. The
value of FED practices: What different levels of analysis learn us, IRNOP X, June
19-22 2011. Montreal.
Bosch-Rekveldt, M. G. C., Mooi, H. G., Verbraeck, A., & Bakker, H. L. M. 2009a.
Perspectives of project professionals on project complexity in the process and
energy industry, IRNOP IX, 11-13 Oct 2009. Berlin.
Bosch-Rekveldt, M. G. C., Mooi, H. G., Verbraeck, A., Sjoer, E., Wolsing, B., & Gulden,
C. 2009b. Mapping project manager's competences to project complexity. In K.
Kknen, A. S. Kazi, & M. Rekola (Eds.), IPMA 23rd WorldCongress, Research
Track Human Side of Projects in Modern Business, Vol. 1: 85-96. Helsinki:
Project Management Association Finland (PMAF) and VTT Technical Research
Centre of Finland.
Bosch-Rekveldt, M. G. C., Smith, J., Mooi, H. G., Bakker, H. L. M., & Verbraeck, A.
2011c. The application of Value Improving Practices: team integration pays off!,
EURAM track 30: Project Organizing. Tallinn, Estland.
Braster, J. F. A. 2000. De Kern van Casestudy's. Assen: Van Gorcum.
Briggs, R. O., Davis, A. J., Murphy, J. D., & Carlisle, T. F. 2007. Transferring a
collaborative work practice to practitioners: a field study of the value frequency
model for change-of-practice, Lecture Notes in Computer Science, Vol.
4715/2007. Berlin / Heidelberg: Springer
Briggs, R. O., Murphy, J. D., Carlisle, T. F., & Davis, A. J. 2009. Predicting Change: A
study of the Value Frequency Model for Change of Practice, 42nd International
Conferences on System Sciences. Hawaii: IEEE Computer Society.
Bryde, D. J. 2003. Project management concepts, methods and application. International
Journal of Operations & Production Management, 23(7-8): 775-793.
Bryde, D. J. 2008. Perceptions of the impact of project sponsorship practices on project
success. International Journal of Project Management, 26(8): 800-809.
Bryde, D. J., & Robinson, L. 2005. Client versus contractor perspectives on project success
criteria. International Journal of Project Management, 23(8): 622-629.
Bryman, A., & Cramer, D. 2009. Quantitative Data Analysis with SPSS 14, 15 & 16. Hove:
Routledge.
Bu-Bushait, K. A. 1988. Relationship between the applications of project management
techniques and project characteristics. Project Managment, 6(4): 235-240.
Burns, T., Stalker, G. M., & Woodward, J. 1961. The Management of Innovation. London:
Tavistock.
Callan, K., Sieimieniuch, C., & Sinclair, M. 2006. A case study example of the role matrix
technique. International Journal of Project Management, 24(6): 506-515.
Caupin, G., Knoepfel, H., Koch, G., Pannenbcker, K., Perez-Polo, F., & Seabury, C. 2006.
ICB - IPMA Competence Baseline Version 3.0. Nijkerk, the Netherlands: Van
Haren Publishing, Zaltbommel.
230
References
Chandler, A. D. J. 1962. Strategy and Structure: Chapters in the History of the American
Industrial Enterprise. Cambridge, MA: MIT press.
Chang, C.-Y., & Ive, G. 2007. The hold-up problem in the management of construction
projects: A case study of the Channel Tunnel. International Journal of Project
Management, 25(4): 394-404.
Charette. 1996. Large-scale project management is risk management. IEEE Software,
13(4): 110-117.
Child, J. 1972. Organizational structure, environment and performance - role of strategic
choice. Sociology-the Journal of the British Sociological Association, 6(1): 1-22.
Child, J. 1975. Managerial and organizational factors associated with company
performance. Part 2: contingency analysis. Journal of Management Studies, 12(1):
12-27.
Cho, C.-S., & Gibson Jr, G. E. 2001. Building project scope definition using project
definition rating index. Journal of Architecture Engineering, 7(4): 115-125.
Cicmil, S., Williams, T. M., Thomas, J., & Hodgson, D. 2006. Rethinking project
management: researching the actuality of projects. International Journal of
Project Management, 24(8): 675-686.
CII. 2009. Construction Industry Institute Best Practices, http://www.constructioninstitute.org/scriptcontent/bp.cfm?section=aboutcii.
Cleland, D. I. 1994. Project Management: Strategic Design and Implementation (2nd ed.).
New York: McGraw-Hill.
Cleland, D. I., & King, W. R. (Eds.). 1983. Project Management Handbook. New York:
Van Nostrand Reinhold Company Inc.
Cohen, L., & Holliday, M. 1982. Statistics for Social Scientists. London: Harper & Row.
Cooke-Davies, T. 2002. The "real" success factors on projects. International Journal of
Project Management, 20(3): 185-191.
Cooke-Davies, T., Cicmil, S., Crawford, L., & Richardson, K. 2007. We're not in Kansas
anymore, Toto: mapping the strange landscape of complexity theory, and its
relationship to project management. Project Management Journal, 38(2): 50-61.
Crawford, L. 2005. Senior management perceptions of project management competence.
International Journal of Project Management, 23(1): 7-16.
Crawford, L., Aitken, A., & Hassner-Nahmias, A. 2011. Embracing the implementation of
change. Paper presented at the IRNOP, Montreal.
Crawford, L., Hobbs, J. B., & Turner, J. R. 2005. Project Categorization Systems: Aligning
Capability with Strategy for Better Results. Newtown Square, Pennsylvania:
Project Management Institute, Inc.
Crawford, L., Morris, P. W. G., Thomas, J., & Winter, M. 2006. Practitioner development:
From trained technicians to reflective practitioners. International Journal of
Project Management, 24: 722-733.
Crawford, L., Pollack, J., & England, D. 2006. Uncovering the trends in project
management: Journal emphases over the last 10 years. International Journal of
Project Management, 24(2): 175-184.
Damanpour, F. 1996. Organizational complexity and innovation: Developing and testing
multiple contingency models. Management Science, 42(5): 693-716.
Dawes, J. 2008. Do data characteristics change according to the number of scale points
used? An experiment using 5-point, 7-point and 10-point scales. International
Journal of Market Research 50(1): 61-77.
de Bruijn, J. A., de Jong, P., Korsten, A., & van Zanten, W. 1996. Grote projecten:
Besluitvorming & management. Alphen aan de Rijn: Samson HD Tjeenk Willink.
231
de Bruijn, J. A., & Herder, P. M. 2009. Systems and actor perspectives on sociotechnical
systems. IEEE Transactions on Systems, Man and Cybernatics - Part A: Systems
and Humans, 39(5): 981- 992.
de Bruijn, J. A., & ten Heuvelhof, E. F. 2007. Management in Netwerken: Over Veranderen
in een Multi-actorcontext (Derde ed.). Den Haag: Lemma.
de Bruijn, J. A., ten Heuvelhof, E. F., & in 't Veld, R. 2002. Procesmanagement. Over
procesmanagement en besluitvorming (2e herziene druk ed.). Den Haag: SDU.
de Bruijn, J. A., ten Heuvelhof, E. F., & in 't Veld, R. J. 2003. Why Project Management
Fails in Complex Decision Making Processes. Dordrecht: Kluwer Academic
Publisher.
de Groen, T., Dhillon, J., Kerkhoven, H., Janssen, J., & Bout, J. 2003. 2x2: A Guide for Key
Decision Makers in the Process Industry. Nijkerk: NAP.
de Jong, B., & Elfring, T. 2010. How does trust affect the performance of ongoing teams?
The Academy of Management Journal, 53(3): 535-549.
Dessler, G. 1976. Organization and Management - A Contingency Approach. Englewood
Cliffs, N.J.: Prentice-Hall.
Dewar, R., & Hage, J. 1978. Size, technology, complexity, and structural differentiation:
towards a theoretical synthesis. Administrative Science Quarterly, 23(1): 111-136.
DMO. 2006a. Acquisition Categorisation Framework - Policy for the Categorisation of
Projects (Defence Materiel Organisation): 6-13. Canberra: Australia Government.
DMO. 2006b. Competency Standard for Complex Project Managers Version 2.0 - College
of Complex Project Managers and Defence Materiel Organisation. Commonwealth
of Australia: Department of Defence.
Dombkins, D., & Dombkins, P. 2008. Contracts for Complex Programs: A Renaissance of
Process. Charleston: Booksurge Publishing.
Dombkins, D. H. 2008. Project categorisation framework (PCAT) - System for the
categorisation of projects, version 2.0, March 2008.
Donaldson, L. 1985. Organization design and the life-cycles of products. Journal of
Management Studies, 22(1): 25-37.
Donaldson, L. 1996. The Normal Science of Structural Contingency Theory. Londen: Sage
publications.
Donaldson, L. 2001. The Contingency Theory of Organizations. Thousand Oaks: Sage
publications.
Drazin, R., & van de Ven, A. H. 1985. Alternative forms of fit in contingency theory.
Administrative Science Quarterly, 30(4): 514-539.
Duncan, W. R. 2006. Sifting with the CIFTER, Vol. 2006: www.pmpartners.com.
Dvir, D. 2005. Transferring projects to their final users: The effect of planning and
preparations for commissioning on project success. International Journal of
Project Management, 23(4): 257-265.
Dvir, D., Lipovetsky, S., Shenhar, A., & Tishler, A. 1998. In search of project
classification: a non-universal approach to project success factors. Research
Policy, 27(9): 915-935.
Dvir, D., Raz, T., & Shenhar, A. 2003. An empirical analysis of the relationship between
project planning and project success. International Journal of Project
Management, 21: 89-95.
Dvir, D., Sadeh, A., & Malach-Pines, A. 2006. Projects and project managers: the
relationship between project manager's personality, project types, and project
succes. Project Managment Journal, 37(5): 36-48.
Eisenhardt, K. M. 1989. Building theories from case-study research. Academy of
Management Review, 14(4): 532-550.
232
References
Engwall, M. 2003. No project is an island: linking projects to history and context. Research
Policy, 32(5): 789-808.
Fangel, M. 1993. The broadening of project management (comment). International Journal
of Project Management, 11(2): 72.
Field, A. 2009. Discovering Statistics Using SPSS (Third ed.). London: SAGE Publications.
Flood, R. L. 1990. Liberating Systems Theory. New York: Plenum Press.
Flyvbjerg, B. 2006. Five misunderstanding about case-study research. Qualitative Inquiry,
12(2): 219-245.
Flyvbjerg, B. 2011. Case study. In N. K. Denzin, & Y. S. Lincoln (Eds.), The Sage
Handbook of Qualitative Research, 4th Edition ed.: 301-316. Thouand Oaks, CA:
Sage.
Flyvbjerg, B., Bruzelius, N., & Rothengatter, W. 2003. Megaprojects and Risk. An
Anatomy of Ambition. Cambridge: Cambridge University Press.
Freeman, R. E. 1984. Strategic Management: a Stakeholder Approach. Boston:
Pitman/Ballinger.
Fry, L. W., & Slocum, J. W. 1984. Technology, structure and workgroup effectiveness - A
test of a contingency model. Academy of Management Journal, 27(2): 221-246.
Fry, L. W., & Smith, D. A. 1987. Congruence, contingency, and theory building. Academy
of Management Review, 12(1): 117-132.
Galbraith, J. 1973. Designing Complex Organizations. Boston, MA: Addison-Wesley.
Galtung, J. 1967. Theory and Methods of Social Research. Oslo: Universitetsforlaget.
GAPPS. 2006. A Framework for Performance Based Competency Standards for Global
Level 1 and 2 Project Managers: www.globalstandards.org.
Geraldi, J. G. 2008a. The balance between order and chaos in multi-project firms: A
conceptual model. International Journal of Project Management, 26(4): 348-356.
Geraldi, J. G. 2008b. Patterns of complexity: the thermometer of complexity. Project
Perspectives 2008, XXIX: 4-9.
Geraldi, J. G. 2008c. Reconciling Order and Chaos in Multi-Project Firms: Empirical
Studies on CoPS producers. Gttingen: Sierke Verlag.
Geraldi, J. G. 2009. What complexity assessments can tell us about projects: dialogue
between conception and perception. Technology Analysis & Strategic
Management, 21(5): 665-678.
Geraldi, J. G., & Adlbrecht, G. 2007. On faith, fact, and interaction in projects. Project
Management Journal, 38(1): 32-43.
Gibson, J. G. E., Wang, Y.-R., Cho, C.-S., & Pappas, M. P. 2006. What is preproject
planning, anyway? Journal of Management in Engineering, 22(1): 35-42.
Gidado, K. I. 1996. Project complexity: the focal point of construction production planning.
Construction Management and Economics, 14(3): 213-225.
Girmscheid, G., & Brockmann, C. 2007. The inherent complexity of large scale
engineering projects. Project Perspectives 2007: 22-26.
Hacker, M., & Doolen, T. 2007. Alignment at the top: A case study investigating this
critical factor in project implementation. Engineering Management Journal, 19(1):
38-42.
Hall, P. G. 1981. Great Planning Disasters. London: Weidenfeld and Nicholson.
Hall, R. H. 1979. Organisations: Structures, Processes and Outcomes. Upper Saddle River:
Prentice - Hall.
Halman, J. I. M. 1994. Risicodiagnose in produktinnovatie: Ontwikkeling van de
risicodiagnosemethode RDM. Technische Universiteit Eindhoven, Eindhoven.
Halman, J. I. M., & Burger, G. T. N. 2002. Evaluating effectiveness of project start-ups: an
exploratory study. International Journal of Project Management, 20(1): 81-89.
233
Hass, K. 2007. Introducing the project complexity model - A new approach to diagnosing
and managing projects (part 1 of 2). PM World Today, IX(VII): 1-8.
Hassen, S. M., Al-Tmeemy, M., Abdul-Rahman, H., & Harun, Z. 2011. Future criteria for
success of building projects in Malaysia. International Journal of Project
Management, 29(3): 337-348.
Hillson, D., & Simon, P. 2007. Practical Project Risk Management - The ATOM
Methodology. Vienna, VA: Management Concepts.
Hobday, M. 1998. Product complexity, innovation and industrial organisation. Research
Policy, 26(6): 689-710.
Hobday, M., Rush, H., & Tidd, J. 2000. Innovation in complex products and system.
Research Policy, 29(7-8): 793-804.
Hodgson, D., & Cicmil, S. (Eds.). 2006. Making Projects Critical. Basingstoke: Palgrave
Macmillan.
Hodgson, D., Paton, S., & Cicmil, S. 2011. Great expectations and hard times: the
paradoxical experience of the engineer as project manager. International Journal
of Project Management, 29(4): 374-382.
Howell, D., Windahl, C., & Seidel, R. 2010. A project contingency framework based on
uncertainty and its consequences. International Journal of Project Management,
28(3): 256-264.
Hutchinson, R., & Wabeke, H. 2006. Opportunity and Project Management Guide
(OPMG). The Hague: Shell International Exploration and Production B.V.
Hyvri, I. 2007. Project Management Effectiveness in Different Organizational Conditions.
Unpublished PhD, Helsinki School of Economics, Helsinki.
IPA. 2009a. Independent Project Analysis - Value Improving Practices Workshop,
http://www.ipainstitute.com/home/programs/description.aspx?id=15.
IPA. 2009b. Industry Benchmarking Consortium 2009: IPA.
IPA. 2011. Industry Benchmarking Consortium 2011: IPA.
IPMA. 2007. Evaluation of project management complexity on level B (draft): part of
ICRG: IPMA.
Jaafari, A. 2001. Management of risks, uncertainties and opportunities on projects: time for
a fundamental shift. International Journal of Project Management, 19(2): 89-101.
Jaafari, A. 2003. Project management in the age of complexity and change. Project
Management Journal, 34(4): 47-57.
Jaccard, J., & Wan, C. K. 1996. LISREL Approaches to Interaction Effects in Multiple
Regressions. Thousans Oaks: Sage.
Jelinek, M. 1977. Technology, organizations and contingency. Academy of Management
Review, 2(1): 17-26.
Kadefors, A. 2004. Trust in project relationships - inside the black box. International
Journal of Project Management, 22(3): 175-182.
Kapsali, M. 2011. Systems thinking in innovation project management: A match that
works. International Journal of Project Management, 29(4): 396-407.
Kast, F. E., & Rosenzweig, J. E. 1985. Organization & Management: A Systems and
Contingency Approach (4th ed.). New York: McGraw-Hill.
Keller, R. T. 1994. Technology information-processing fit and the performance of R-and-D
project groups - A test of contingency theory. Academy of Management Journal,
37(1): 167-179.
Kerzner, P. D. 2003. Project Management; a Systems Approach to Planning, Scheduling
and Controlling London: John Wiley.
Kim, J. O. 1975. Multivariate analysis of ordinal variables. American Journal of Sociology,
81: 261-298.
234
References
Kloppenborg, T. J., & Opfer, W. A. 2002. The current state of project management
research: Trends, interpretations, and predictions. Project Management Journal,
33(2): 5-18.
Kolltveit, B. J., & Grnhaug, K. 2004. The importance of the early phase: the case of
construction and building projects. International Journal of Project Management,
22(7): 545-551.
Kolltveit, B. J., Karlsen, J. T., & Kjell, G. 2006. Perspectives on project management.
International Journal of Project Management, 25(1): 3-9.
Koppenjan, J., Veeneman, W., Van der Voort, H., Ten Heuvelhof, E., & Leijten, M. 2011.
Competing management approaches in large engineering projects: The Dutch
RandstadRail project. International Journal of Project Management, 29 (6): 740750.
Kutsch, E., & Hall, M. 2010. Deliberate ignorance in project risk management.
International Journal of Project Management, 28(3): 245-255.
Kwak, Y. H., & Anbari, F. T. 2009. Analyzing project management research: Perspectives
from top management journals. International Journal of Project Management,
27(5): 435-446.
Kwak, Y. H., & Ingall, L. 2007. Exploring Monte Carlo simulation applications for project
management. Risk Management, 9: 44-57.
Labovitz, S. 1967. Some observations on measurement and statistics. Social Forces, 46:
151-160.
Laslo, Z. 2010. Project portfolio management: An integrated method for research planning
and scheduling to minimize planning/scheduling-dependent expenses.
International Journal of Project Management, 28(6): 609-618.
Lawrence, P. R., & Lorsch, J. W. 1967. Organization and Environment. Cambridge MA:
Harvard Graduate School of Business Administration.
Lechler, T. 1998. When it comes to project management, it's the people that matter: an
empirical analysis of project management in Germany. In F. Hartman, G. Jergeas,
& J. Thomas (Eds.), IRNOP III: 205-215. Calgary: University of Calgary.
Lee, J., & Miller, D. 1996. Strategy, environment and performance in two technological
contexts: Contingency theory in Korea. Organization Studies, 17(5): 729-750.
Lehmann, V. 2010. Connecting changes to projects using a historical perspective: Towards
some new canvases for researchers. International Journal of Project Management,
28(4): 328-338.
Lewis, M. W., Welsh, M. A., & Dehler, G. E. 2002. Product development tensions:
Exploring contrasting styles of project management. Academy of Management
Journal, 45(3): 546-564.
Leybourne, S. A. 2007. The changing bias of project management research: a consideration
of the literatures and an application of extant theory. Project Managment Journal,
38(1): 61-73.
Lindahl, M., & Rehn, A. 2007. Towards a theory of project failure. International Journal of
Management Concepts and Philolosphy, 2(3): 246-254.
Lintsen, H. 1985. De ideologie van ingenieurs, Ingenieur van beroep. Historie, praktijk,
macht en opvattingen van ingenieurs in Nederland . Den Haag: Ingenieurspers.
Locke, E. A., & Latham, G. P. 2002. Building a practically useful theory of goal setting and
task motivation: A 35 year odyssey. American Psychologist, 57(9): 705-717.
Love, P. E. D., Holt, G. D., Shen, L. Y., Li, H., & Irani, Z. 2002. Using system dynamics to
better understand change and rework in construction project management systems.
International Journal of Project Management, 20(6): 425-436.
235
Lowy, A., & Hood, P. 2004. The Power of the 2x2 Matrix - Using 2x2 Thinking to Solve
Business Problems and Make Better Decisions. San Francisco: Jossey-Bass A
Wiley Imprint.
Luu, V. T., Kim, S., & Huynh, T. 2008. Improving project management performance of
large contractors using benchmarking approach. International Journal of Project
Management, 26(7): 758-769.
Mason, R. B. 2007. The external environment's effect on management and strategy - a
complexity theory approach. Management Decision, 45(1): 10-28.
Maurer, I. 2010. How to build trust in inter-organizational projects: The impact of project
staffing and project rewards on the formation of trust, knowledge acquisition and
product innovation. International Journal of Project Management, 28(7): 629-637.
Maylor, H. 2005. Project Management (3rd ed.). Essex: Pearson Education Limited.
Maylor, H., Brady, T., Cooke-Davies, T., & Hodgson, D. 2006. From projectification to
programmification. International Journal of Project Management, 24(8): 663-674.
Maylor, H., Vidgen, R., & Carver, S. 2008. Managerial complexity in project based
operations: a grounded model and its implications for practice. Project
Management Journal, 39(Supplement): S15-S26.
Maynard, D. C., & Hakel, M. D. 1997. Effects of objective and subjective task complexity
on performance. Human Performance, 10(4): 303-330.
Mc Kenna, M. G., Wilczynski, H., & van der Schee, D. 2006. Capital Project Execution in
the Oil and Gas Industry: Booz Allen Hamilton.
McGee, M. D., DeFoe, P. R., Robertson, D. I., & McConnell, J. D. 1999. Improving asset
performance through application of a structured decision process, SPE Annual
Technical Conference and Exhibition. Houston, Texas: Society of Petroleum
Engineers.
Menches, C. L., & Hanna, A. S. 2006. Quantitative measurement of successful performance
from the project manager's perspective. Journal of Construction Engineering and
Management, 132(10): 1284-1293.
Menches, C. L., Hanna, A. S., Nordheim, E. V., & Russell, J. S. 2008. Impact of preconstruction planning and project characteristics on performance in the US
electrical construction industry. Construction Management and Economics, 26(8):
855-869.
Meredith, J. R., & Mantel, S. J. 2006. Project Management: a Managerial Approach (6th
ed.). New York, USA: John Wiley & Sons, Inc.
Merrow, E. 2002. The elements of project system excellence. Paper presented at the
Government/Industry Forum.
Merrow, E. 2011. Industrial Megaprojects: Concepts, Strategies and Practices for Success
Hoboken, New Jersey: John Wiley & Sons.
Meskendahl, S. 2010. The influence of business strategy on project portfolio management
and its success - A conceptual framework. International Journal of Project
Management, 28(8): 807-817.
Miles, M. B., & Huberman, A. M. 1994. Qualitative Data Analysis: an Expanded
Sourcebook (2nd ed.). London: Sage Publications Ltd.
Miller, E. J. 1973. Technology, territory and time: the internal differentiation of complex
production systems. In F. Baker (Ed.), Organisational Systems. Illinois: R.D.
Irwin.
Mitchell, R. K., Agle, B. R., & Wood, D. J. 1997. Toward a theory of stakeholder
identification and salience: defining the principle of who and what really counts.
Academy of Management Review, 22(4): 853-886.
Morris, P. W. G. 1994. The Management of Projects. London: Thomas Telford.
236
References
Morris, P. W. G., Crawford, L., Hodgson, D., Shepherd, M. M., & Thomas, J. 2006a.
Exploring the role of formal bodies of knowledge in defining a profession - the
case of project management. International Journal of Project Management, 24(8):
710-721.
Morris, P. W. G., & Hough, G. H. 1987. The Anatomy of Major Projects: a Study of the
Reality of Project Management. Chichester: John Wiley.
Morris, P. W. G., Jamieson, A., & Stepherd, M. M. 2006b. Research updating the APM
Body of Knowledge 4th edition. International Journal of Project Management,
24(6): 416-573.
Mller, 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(5): 398-403.
Mller, R., & Turner, J. R. 2007. Matching the project manager's leadership style to project
type. International Journal of Project Management, 25(1): 21-32.
Murray, A. 2009. Managing Successful Projects with PRINCE2 (Office of Government
Commerce) (5th ed.). Norwich: The Stationery Office.
NAP. 2009. NAP network, www.napnetwerk.nl.
Neleman, J. 2006. Shell gaat diep. FEM Business, 9(4): 30-34.
Nicholas, J. M. 2004. Project Management for Business and Technology - Principles and
Practice (2nd ed.). Oxford: Elsevier Inc.
Nightingale, D. V., & Toulouse, J. M. 1977. Toward a multilevel congruence theory of
organization. Administrative Science Quarterly, 22(2): 264-280.
Olander, S., & Landin, A. 2005. Evaluation of stakholder influence in the implementation
of construction projects. International Journal of Project Management, 23(4):
321-328.
Oosterhuis, E. J., Pang, Y., Oostwegel, E., & de Kleijn, J. P. 2008. Front-End Loading
Strategy: a Strategy to Achieve 2x2 Goals. Nijkerk: NAP.
Ortt, J. R., & van der Duin, P. A. 2008. The evolution of innovation management towards
contextual innovation. European Journal of Innovation Management, 11(4): 522538.
Papke-Shields, K., Beise, C., & Quan, J. 2010. Do project managers practice what they
preach, and does it matter to project success? International Journal of Project
Management, 28(7): 650-662.
Parwani, R. R. 2002. Complexity: an Introduction. Singapore: National University of
Singapore.
Pellegrinelli, S. 2011. What's in a name: Project or programme? International Journal of
Project Management, 29(2): 232-240.
Pennings, J. M. 1987. Structural contingency theory - a multivariate test. Organization
Studies, 8(3): 223-240.
Pennings, J. M. 1992. Structural contingency theory - a reappraisal. Research in
Organizational Behavior, 14: 267-309.
Perminova, O., Gustafsson, M., & Wikstrm, K. 2008. Defining uncertainty in projects - a
new perspecive. International Journal of Project Management, 26(1): 73-79.
Perrow, C. 1986. Complex Organizations; a Critical Essay (3rd ed.). New York: Randon
House.
Peytchev, A. 2009. Survey breakoff. Public Opinion Quarterly, 73(1): 74-97.
Pfeffer, J., & Salancik, G. R. 1978. The External Control of Organizations: a Resource
Dependence Perspective. New York: Harper and Row.
Pich, M. T., Loch, C. H., & De Meyer, A. 2002. On uncertainty, ambiguity, and complexity
in project management. Management Science, 48(8): 1008-1023.
237
238
References
Shenhar, A. J., Dvir, D., Levy, O., & Maltz, A. 2001. Project success: a multidimensional
strategic concept. Long Range Planning, 34: 699-725.
Sidwell, T., & Kennedy, R. 2004a. Project Delivery for Exceptional Results in the
Construction Industry: Research Summary. Brisbane: Cooperative Research
Centre for Construction Innovation.
Sidwell, T., & Kennedy, R. 2004b. Value Alignment Process for Project Delivery: Final
Report. Brisbane: Cooperative Research Centre for Construction Innovation.
Simon, H. A. 1962. The architecture of complexity. Proceedings of the American
Philosophical Society, 106(6): 467-482.
Smyth, H. J., & Morris, P. W. G. 2007. An epistemological evaluation of research into
projects and their management: Methodological issues. International Journal of
Project Management, 25(4): 423-436.
Sderlund, J. 2004a. Building theories of project management: past research; questions for
the future. International Journal of Project Management, 22(3): 183-191.
Sderlund, J. 2004b. On the broadening scope of the research on projects: a review and a
model for analysis. International Journal of Project Management, 22(8): 655-667.
Sderlund, J. 2011. Pluralism in project management: Navigating the crossroads of
specialization and fragmentation. International Journal of Management Reviews,
13(2): 153-176.
Sommer, S. C., & Loch, C. H. 2004. Selectionism and learning in projects with complexity
and unforeseeable uncertainty. Management Science, 50(10): 1334-1347.
Stretton, A. 2006. Projects, programs, portfolios and strategic objectives, GAPPS Working
Session No 8. Singapore.
Stuiveling, S. J., & van Schoten, E. M. A. 2011. ICT bij de Politie (kst 29350-9). Den
Haag: Algemene Rekenkamer.
Taleb, N. N. 2007. The Black Swan: The Impact of the Highly Improbable. New York:
Randon House.
Tashakkori, A., & Teddlie, C. 1998. Mixed Methodology: Combining Qualitative and
Quantitative Approaches. London: Sage Publications.
Tatikonda, M. V. 1999. An empirical study of platform and derivative product development
projects. Journal of Product Innovation Management, 16(1): 3-26.
Tatikonda, M. V., & Rosenthal, S. R. 2000. Technology novelty, project complexity and
product development project execution success: a deeper look at task uncertainty
in product innovation. IEEE Transactions on Engineering Management, 47(1): 7487.
Thamhain, H. J., & Wilemon, D. L. 1975. Conflict management in project life cycles. Sloan
Management Review, 16(3): 31-50.
Thamhain, H. J., & Wilemon, D. L. 1986. Criteria for controlling projects according to
plan. Project Management Journal, 17(2): 75-81.
Thomas, J., & Mengel, T. 2008. Preparing the project manager to deal with complexity Advanced project management education. International Journal of Project
Management, 26(3): 304-315.
Thompson, J. D. 1967. Organization in Action. New York: McGraw-Hill.
Turner, J. R. 1999. The Handbook of Project-Based Management (2nd edition ed.).
Glasgow: McGraw Hill.
Turner, J. R. (Ed.). 2003. People in Project Management. Aldershot: Gower Publishing
Limited.
Turner, J. R. 2006. Towards a theory of project management: the functions of project
management. International Journal of Project Management, 24(3): 187-189.
239
Turner, J. R. 2008. The Handbook of Project-Based Management (3rd edition ed.). London:
McGraw-Hill.
Turner, J. R. 2010. Evolution of project management research as evidenced by papers
published in the International Journal of Project Management. International
Journal of Project Management, 28(1): 1-6.
Turner, J. R., & Cochrane, R. A. 1993. Goals-and-methods matrix: coping with projects
with ill defined goals and/or methods of achieving them. International Journal of
Project Management, 11(2): 93-102.
Turner, J. R., & Keegan, A. 2001. Mechanisms of governance in the project-based
organization: toles of the broker and the steward. European Management Journal,
19(3): 254-267.
Turner, J. R., Ledwith, A., & Kelly, J. 2010. Project management in small to medium-sized
enterprises: Matching processes to the nature of the firm. International Journal of
Project Management, 28(8): 744-755.
Turner, J. R., & Mueller, R. 2003. On the nature of the project as a temporary organization.
International Journal of Project Management, 21(1): 1-8.
Turner, J. R., & Simister, S. J. (Eds.). 2000. Gower Handbook of Project Management (3rd
edition ed.). Aldershot: Gower Publishing Limited.
Turner, R. J., & Mller, R. 2005. The project manager's leadership style as a success factor
on projects: a literature review. Project Managment Journal, 36(2): 49-61.
Ulrich, W. 1987. Critical heuristics of social systems design. European Journal of
Operational Research, 31(3): 276-283.
van der Lei, T. E., Kolfschoten, G. L., & Beers, P. J. 2010. Complexity in multi-actor
system research: towards a meta-analysis of recent studies. Journal of Design
Research, 8(4): 317-342.
van der Merwe, A. P. 2002. Project management and business development: integrating
strategy, structure, processes and projects. International Journal of Project
Management, 20(5): 401-411.
van der Velde, R. R., & van Donk, D. P. 2002. Understanding bi-project management:
engineering complex industrial construction projects. International Journal of
Project Management, 20(7): 525-533.
van der Weijde, G. 2008. Front-end loading in the oil and gas industry: Towards a fit
front-end development phase. Delft University of Technology, Delft.
Verschuren, P., & Doorewaard, H. 1999. Designing a Research Project. Utrecht: Lemma.
Vidal, L.-A., & Marle, F. 2008. Understanding project complexity: implications on project
management. Kybernetes, 37(8): 1094-1110.
Vonk Noordegraaf, A. 2011. How to Get the Right People on the Project? The Implications
of Project Complexity on Project Team Compilation. Delft University of
Technology, Delft.
Waldrop, M. M. 1992. Complexity: The Emerging Science at the Edge of Order and Chaos.
New York: Simon and Schuster.
Walkup, G. W., & Ligon, J. R. 2006. The good, bad and ugly of stage-gate project
management processes as applied in the oil and gas industry, SPE Annual
Technical Conference and Exhibition. San Antonio, Texas, USA: Society of
Petroleum Engineers.
Wallace, W. L. 1971. The Logic of Science in Sociology: Aldine De Gruyter
Weaver, W. 1948. Science and complexity. American Scientist, 35(10): 536-545.
Wentink, J. 2010. Project Complexities in Maintenance Projects. Delft University of
Technology, Delft.
240
References
Westerveld, E., & Walters, D. G. 2001. Het Verbeteren van Uw Projectorganisatie - Het
Project Excellence Model in de Praktijk. Deventer: Berenschot Fundatie / Kluwer.
Whitty, S. J., & Maylor, H. 2009. And then came Complex Project Management (revised).
International Journal of Project Management, 27(3): 304-310.
Williams, T. M. 1999. The need for new paradigms for complex projects. International
Journal of Project Management, 17(5): 269-273.
Williams, T. M. 2002. Modelling Complex Projects. London: John Wiley & Sons.
Williams, T. M. 2003. Learning from projects. Journal of Operational Research Society,
54(5): 443-451.
Williams, T. M. 2005. Assessing and moving on from the dominant project management
discourse in the light of project overruns. IEEE Transactions on Engineering
Management, 52(4): 497-508.
Winch, G. M. 2002. Managing Construction Projects. Oxford: Blackwell Science.
Winter, M., Smith, C., Cooke-Davies, T., & Cicmil, S. 2006a. The importance of 'process'
in Rethinking Project Management: The story of a UK Government-funded
research network. International Journal of Project Management, 24(8): 650-662.
Winter, M., Smith, C. D., Morris, P. W. G., & Cicmil, S. 2006b. Directions for future
research in project management: the main findings of a UK government-funded
research network. International Journal of Project Management, 24(8): 638-649.
Woodward. 1965. Industrial Organisation: Theory and Practice. Oxford, UK: Oxford
University Press.
Wright, K. B. 2005. Researching internet-based populations: advantages and disadvantages
of online survey research, online questionnair authoring software packages, and
web survey services. Journal of Computer-Mediated Communication, 10(3):
article 11.
Xia, W., & Lee, G. 2004. Grasping the complexity of IS development projects.
Communications of the ACM, 47(5): 69-74.
Xia, W., & Lee, G. 2005. Complexity of information systems development projects:
conceptualization and measurement development. Journal of Management
Information Systems, 22(1): 45-83.
Yang, J., Qiping Shen, G., Ho, M., Drew, D. S., & Xue, X. 2010. Stakeholder management
in construction: An empirical study to address research gasp in previous studies.
International
Journal
of
Project
Management,
in
press(doi:10.1016/j.ijproman.2010.07.013).
Yin, R. K. 2002. Case Study Research: Design and Methods (3rd ed.). London: Sage
Publications Inc.
Yin, R. K. 2003. Applications of Case Study Research (2nd ed.). London: Sage Publications
Inc.
241
242
APPENDICES
APPENDIX A: LIST OF INTERVIEW QUESTIONS EXPLORATIVE CASE
STUDIES (CHAPTER 3) ................................................................................................ 244
243
Details
participant
/project
(~10 min)
ID
a_100
a_101
a_102
a_101_1
a_101_2
a_101_3
a_101_4
a_101_5
a_103
a_104
a_105
a_106
a_107
a_108
a_109
a_110
a_111
a_112
a_113
a_114
a_115
b_100
b_101
b_102
Project
result
(~10 min)
b_103
b_104
b_105
b_106
b_107
b_108
b_109
b_110
b_111
b_112
b_113
b_114
b_115
b_116
244
Question
Which project
Name interviewee
Business card for contact details
Gender
Nationality
Engineering background?
Worked at which companies?
Other projects were you involved in / roles you had within Shell?
Years of project experience in total
Role in this project
Objective of the project
In which project phase were you involved in the project
(month/year)?
What was your role in estimation (cost, schedule)?
How was the co-operation with the business developer and asset
developer (operations manager) - integrated over the phases or
"sequential"?
Which parties were involved in the project (client, partners, main
contractors, government, ngo's etc)
In which phase(s) were the different parties involved?
What is (an indication of) the number of persons involved per party over
the different phases (ramp up / ramp down)?
How experienced were the project parties in their respective tasks?
Was there a lot of interaction between parties, which parties?
Was there a lot of interaction between tasks (sequential, pooled,
reciprocal), which tasks?
How was the project classified in terms of risk - consequences &
probability (Low/Mid/High)?
Do you consider this project (overall; FED&execution) as
successful? (yes /no)
In what way do you consider the project as successful?
Did you meet the 5 project promises (cost, schedule, scope, quality and
HSSE)?
How difficult was it to meet these promises?
Did the project introduce new technology or open a new market, how?
Were the parties involved satisfied with the project result?
Did any scope change play a role in the project execution?
If scope change occurred; when, why and how?
If scope change occurred; which parties played a role in the scope
change, how?
If scope change occurred: how did you manage the scope change?
If scope change occurred: what were the consequences of the scope
change?
Would you characterize the project as cost driven or schedule driven?
Were the cost estimates realistic, what did mainly drive the estimates?
Were the schedule estimates realistic, what did drive the estimates for
this project?
What was the role of governance in achieving the project result (steering
team, decision reviews, etc)?
Was there any rework necessary? Which project phase(s) and by
whom?
What particular difficulties or problems did you encounter during
the project that impacted the project result?
c_104
c_105
c_106
Project
complexity
(~30 minutes)
c_107
c_108
c_109
c_110
c_111
c_112
c_113
c_114
d_100
d_101
d_102
d_103
Front end
development
(~15 min)
d_104
d_105
d_106
d_107
d_108
d_109
d_110
e_100
Closure
(~5min)
e_101
e_102
e_103
245
246
247
248
249
250
251
252
253
254
255
Element name
Number of goals
Survey question
27. What was the business justification to undertake this project for your company (more
than one answer possible)
to obtain margin growth,
to maintain the current margin,
for operational necessity,
to comply to legislation,
to build a long term relationship with the customer,
to gather knowledge and/or experience in the field,
to get introduced in a new market,
other
elm_TG2
Goal alignment
elm_TG3
Clarity of goals
elm_TS1
Scope largeness
elm_TS2
Uncertainties
scope
elm_TS3
Quality
requirements
elm_TT1
Number of tasks
elm_TT2
Variety of tasks
elm_TT3
Dependencies
between tasks
28B. Which answer applies best to your project: (strongly disagree, disagree, neutral,
agree, strongly agree, do not know)
Project goals were aligned with each other
28A. Which answer applies best to your project: (strongly disagree, disagree, neutral,
agree, strongly agree, do not know)
Project goals were clear
32. Deliverables are often defined per work package of a project. What was the
approximate total number of official deliverables in the project?
29. At FID, the project scope can consist of a rough (functional) design or it can be fully
detailed. On a scale from 0% (rough design) to 100% (fully detailed design) please
indicate the level of detail of the scope at FID for this project.
33. What were the quality requirements regarding the deliverables in this project, with
reference to the standard in the discipline? (Extraordinary low, Lower than normal,
Normal, Higher than normal, Extraordinary high, Do not know)
30. On a low level, project activities are commonly structured in tasks. On a higher level,
these tasks are structured in work packages (WPs), with own deliverables and milestones.
Please indicate the approximate number of WPs involved in this project.
31A. The content of the WPs can be very similar (e.g. engineering part x, engineering part
y) or very different (marketing, education, etc) and may or may not rely on outcomes of
other WPs. To what extent were the WPs in this project: Varied, e.g. different types of
tasks involved? (Not, Little, Substantial, Do not know)
31B. The content of the WPs can be very similar (e.g. engineering part x, engineering part
y) or very different (marketing, education, etc) and may
or may not rely on outcomes of other WPs. To what extent were the WPs in this project:
Strongly depending on results of other WPs? (Not, Little, Substantial, Do not know)
46A. Please indicate the answer that applies best to this project. ( Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know)
There was uncertainty in the technical methods to be applied
34A. To what extent: Did technical processes in this project have interrelations with
existing processes? (Not, Little, Substantial, Do not know)
elm_TT4
elm_TT5
elm_TT6
elm_TE1
in
Uncertainty
in
methods
Interrelations
between technical
processes
Conflicting norms
and standards
Newness
of
technology
(world-wide)
elm_TE2
Experience
technology
elm_TR1
Technical risks
256
with
36. Different types of technical standards might apply on a project, such as design
standards and country specific norms. Did the project experience conflicting norms? (No,
Little, Yes, Do not know)
34B. To what extent: Did the project make use of new technology, e.g. nonproven
technology? (Not, Little, Substantial, Do not know)
46B. Please indicate the answer that applies best to this project. ( Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The parties involved had applied the technology involved in the project before in similar
situations
46P. Please indicate the answer that applies best to this project. ( Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
I considered the project being high risk (number, probability and/or impact of) in terms of
technical risks
Element name
Project duration
OS2
Compatibility of
different project
management
methods and tools
OS3
OS4
Size in CAPEX
Size in Engineering
hours
OS5
OS6
OS7
Number of
locations
ORE1
Project drive
ORE2
ORE3
Experience with
parties involved
ORE4
HSSE awareness
ORE5
Interfaces between
different disciplines
ORE6
Number of
financial resources
ORE7
Contract types
OP1
OP2
Number of different
nationalities
Number of different
languages
OP3
Co-operation JV
partner
OP4
Overlapping office
hours
OT1
Trust in project
team
OT2
Trust in contractor
OR1
Organisational risks
Survey question
17. Please indicate the planned duration of the project (all project phases) in months.
37. Different parties in a project might use different project management methodology
(PRINCE2, PMBoK, company standards, etc). Did you expect compatibility issues
regarding the project management methodology to be used in this project on beforehand? (No
compatibility issues, Little compatibility issues, Substantial compatibility issues, Do not know).
38. Different parties in a project might use different project management tools (MSProject,
Primavera, Palisade @risk, etc). Did you expect compatibility issues regarding the project
management tools to be used in this project on beforehand?
(No compatibility issues, Little compatibility issues, Substantial compatibility issues,
Do not know).
11. What was the estimated capital expenditure of this project?
12. What was the expected total amount of manhours in this project? (a rough estimate is
sufficient)
16. What was the approximate maximum number of people working simultaneously on the
project (including workers)?
23. What was the size of the area that the scope of the project had to deal with? (a rough
estimate is sufficient)
22. What was the total number of project sites (locations), including contractor locations, where
work for this project was performed? (All at 1 location, 2 to 4 locations, 5 to 9 locations, > 9
locations, Do not know)
10. Please indicate to what extent this project was driven by the following factors or
constraints: Cost, Schedule, Quality (Not at all, Little, Substantially, Completely,
Not applicable, Do not know)
26. All resources and required skills were available for this project in terms of:
Personnel (All available, Minor difficulties with availability, Major difficulties with
availability, Do not know)
Materials and equipment (All available, Minor difficulties with availability, Major
difficulties with availability, Do not know)
39. Prior to this project, my company had worked with this project's (all parties indicated in
question 7): (Never, Seldom, Sometimes, Often, Not applicable, Do not know)
40. The parties involved in the project had sufficient awareness of Health, Safety, Security and
Environment (all parties indicated in question 7): (Never, Seldom, Sometimes, Often, Not
applicable, Do not know)
35. In a project, a number of different disciplines might be involved such as mechanical,
electrical, chemical, civil, finance, legal, communication, accounting, etc. Were there interfaces
between the different disciplines that potentially could have lead to interface problems in this
project? (Only one discipline involved hence no interface problems expected, More disciplines
involved, no interface problems expected, More disciplines involved, little interface problems
expected, More disciplines involved, substantial interface problems expected, Do not know)
18. To what extent was the project financed from the following sources (0%, 120%, 2140%,
4160%, 6180%, 8199%, 100%, Do not know):
Client (other than own company) / Own company investment / Bank investment / JV partner /
Subsidies
19. Within a project, several contract types might play a role. Which of the following answers
captures best the situation in this project? (Only one contract involved,
All main contracts involved were of the same type, Two types of main contracts were involved,
More than two types of main contracts were involved, Do not know)
43. What was the number of different nationalities involved in the project team with a
substantial contribution to the project? (1, 2 to 5, 5 to 10, >10, Do not know)
44. How many different languages (written and spoken) were used in the project team for work
or work related communication? (1, 2, 3, 4, >4, Do not know)
7. Next to your company, what other parties were involved in the project?
(JV partner(s), Consortium partner(s), Project owner, Managing contractor, (Engineering)
Contractor(s), Subcontractor(s), Other, please specify)
24. How many overlapping hours did this project have because of different time-zones
involved? (7 or 8 overlapping office hours, 5 or 6 overlapping office hours, 3 or 4 overlapping
office hours, 1 or 2 overlapping office hours, No overlapping office hours, Do not know)
46J. Please indicate the answer that applies best to this project. (Strongly disagree, Disagree,
Neutral, Agree Strongly agree, Not Applicable, Do not know).
Before the project activities started there was a trusting relationship between the team members
in the project management team
42. Before the project activities started, my company had a trusting relationship with
(contractor if indicated in question 7): (Strongly disagree, Disagree, Neutral, Agree, Strongly
Agree, Not applicable, Do not Know)
46Q. Please indicate the answer that applies best to this project. (Strongly disagree, Disagree,
Neutral, Agree Strongly agree, Not Applicable, Do not know).
I considered the project being high risk (number, probability and/or impact of) in terms of
organizational risks
257
Element name
ES2
Number
stakeholders
Variety
stakeholders'
perspectives
ES3
Dependencies on
other stakeholders
ES4
Political influence
Company
support
internal
ES5
Required
content
local
ES6
Interference
existing site
with
EL1
EL2
Weather conditions
EL3
Remoteness
location
EL4
Experience in the
country
EM1
Internal strategic
pressure
EM2
Stability
project
environment
EM3
Level
competition
ER1
Risks
environment
ES1
258
of
of
of
of
from
Survey question
45. Counted in the number of groups around the table in the project (e.g. project team
counts for one, local government counts for one, each contractor counts for one, etc),
what was the total number of stakeholders for this project?
46C. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
Different stakeholders had different perspectives
46D. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
My company was very dependent on the other stakeholders
46E. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The political situation in the country did influence the project
46F. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
My company's business representatives and the senior management supported the
project throughout
25. In some countries, you can only win the project when you will involve local parties; the
socalled required local content of the project. To what extent of the project budget, local
content was obligatory in this project? (No local content required, Little local content
required, Substantial local content required, Not applicable, Do not know)
46G. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The project faced interference problems with previous use of the area or existing
products/projects
46K. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
We expected extreme weather conditions to influence the project progress
46L. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The project site location was in a remote area
41. The parties involved in the project had experience in the country where the project
was executed: (Strongly disagree, Disagree, Neutral, Agree, Strongly agree, Not
applicable, Do not Know)
46O. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
My company had sufficient experience in the country where the project was performed
46H. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
For this project, there was pressure from the business department in my company to
deliver cheaper
46I. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
For this project, there was pressure from the business department in my company to
deliver faster
46M. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The project had to deal with fluctuating environment (such as exchange rates, raw
material pricing, oil prices, etc).
46N. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
The project was to be run in a highly competitive market
46R. Please indicate the answer that applies best to this project. (Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
I considered the project being high risk (number, probability and/or impact of) in terms of
environmental risks
T- elements
O- elements
E- elements
T-elements
Page 260
O-elements
Page 261
Page 263
E-elements
Page 262
Page 265
Page 267
259
260
261
262
263
264
265
266
267
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
elm_TG2:
Sig. (2-tailed)
unaligned goals
N
Correlation Coefficient
elm_TG3:
Sig. (2-tailed)
unclear goals
N
Correlation Coefficient
elm_TS1:
Sig. (2-tailed)
scope largeness
N
Correlation Coefficient
elm_TS2:
Sig. (2-tailed)
uncertainties in scope
N
Correlation Coefficient
elm_TS3:
Sig. (2-tailed)
quality requirements
N
Correlation Coefficient
elm_TT1:
Sig. (2-tailed)
number of tasks
N
Correlation Coefficient
elm_TT2:
Sig. (2-tailed)
variety of tasks
N
Correlation Coefficient
elm_TT3:
Sig. (2-tailed)
dep. between tasks
N
Correlation Coefficient
elm_TT4:
Sig. (2-tailed)
uncertainty in methods
N
Correlation Coefficient
elm_TT5:
interrelations between
Sig. (2-tailed)
technical processes
N
Correlation Coefficient
elm_TT6:
conflicting norms and
Sig. (2-tailed)
standards
N
Correlation Coefficient
elm_TE1:
Sig. (2-tailed)
newness of technology
N
Correlation Coefficient
elm_TE2:
lack of exp with
Sig. (2-tailed)
technology
N
Correlation Coefficient
elm_TR1:
Sig. (2-tailed)
technical risks
N
** Correlation is significant at the 0.01 level (2-tailed)
* Correlation is significant at the 0.05 level (2-tailed)
Correlation is significant at the 0.1 level (2-tailed)
elm_TG1:
number of goals
268
Perceived
technical
complexity
.227
.065
67
.035
.783
66
-.070
.575
67
.026
.875
40
-.025
.847
61
.357****
.003
67
-.024
.875
47
-.166
.212
58
.219()
.102
57
.270*
.028
66
.073
.561
65
.124
.328
64
.240
.054
65
.131
.295
66
.534**
.000
66
Perceived
organizational
complexity
-.040
.747
67
.507**
.000
66
.212
.085
67
.124
.446
40
.211()
.102
61
.113
.364
67
.049
.745
47
.045
.739
58
.100
.457
57
.223
.071
66
-.142
.258
65
.304*
.015
64
.232
.063
65
.165
.184
66
.298*
.015
66
Perceived
environmental
complexity
.113
.366
66
.120
.342
65
.092
.464
66
.049
.768
39
.024
.855
60
.234
.059
66
-.139
.357
46
-.097
.472
57
.087
.522
56
.045
.720
65
-.150
.235
64
.089
.487
63
.017
.893
64
.008
.949
65
.076
.549
65
Sub-ordering
Goals
ID
TG1
Elements defined
Number of goals
Correlation result
T
Action proposed
Use data
The element number of goals (elm_TG1) shows a weak positive correlation with perceived
technical complexity, (rs=.227; p =.065). This element shows two counterintuitive
significant correlations with other TOE elements, suggesting a lower number of strategic
goals with larger projects (with elm_OS3: rs=-.268, p =.034; with elm_OS4: rs=-.331,
p=.02) and when more languages are involved (with elm_OP2: rs=-.273, p=.025). Since
none of these three elements do show significant correlations to perceived technical
complexity, these elements need deeper investigation (see specific discussion of these
elements). The gathered data for the element number of goals can be used in the current
analysis.
TOE
T
T
Sub-ordering
Goals
Goals
ID
TG2
TG3
Elements defined
Unaligned goals
Unclear goals
Correlation result
O**
O
Action proposed
Use data
Use data
TOE
Sub-ordering
ID
Elements defined
Correlation result
Scope
TS1
Scope largeness
Action proposed
Do not use data,
remove element
The element scope largeness (elm_TS1) does not correlate significantly to any perception
of complexity. Since it does moderately correlate to the element number of tasks (elm_TT1:
rs=.447, p=.006) it seems to measure what it was intended to measure. However, it doesnt
seem to contribute to complexity in view of the respondents. From scatter plot analysis it
was concluded that three cases are obscuring the data for this question (cases 2, 66, 85).
When excluding these cases, indeed correlation results between scope largeness and
perceived complexity do improve, but still they are non-significant. Since also 27 cases
269
have a missing value for this element, the survey question corresponding to this element
would need rephrasing. In the current question, the scope largeness is operationalised by
the number of official deliverables involved in the project. Apart from the fact that a
considerable amount of respondents could not answer this question, the number of
deliverables not necessarily has a clear relation with the scope largeness: this could
considerably differ per project / sector. A better measure for scope largeness is required,
but at this stage it seems that scope largeness is hard to operationalize other than CAPEX,
number of resources, number of different tasks, etc., which are all other elements in the
TOE framework. Therefore this element should be removed from the framework and the
obtained data for this element should not be used in the current analysis.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Scope
TS2
Uncertainties in scope
Action proposed
Use data, rephrase
survey question
The element uncertainties in scope (elm_TS2) shows a weak, hardly significant, positive
correlation to perceived organizational complexity (rs = .211, p=.102). It more significantly
correlates to elements such as unaligned goals, scope largeness, compatibility of different
PM methods and tools, number of locations, resource and skills scarcity, interfaces
between different disciplines, number of different nationalities and number of stakeholders.
These are all positive correlations; e.g. more uncertainties in scope coincide with more
unaligned goals, larger scope, compatibility problems of PM methods and tools, more
locations, problems with availability of resources and stakeholders, interface problems,
more nationalities involved and more stakeholders involved. These correlations are merely
with O-elements of the framework, explaining why the correlation with perceived
organizational complexity was found. The survey question corresponding to the element
uncertainties in scope asks for the level of detail of the design at the moment of FID
(financial investment decision). This formulation with the corresponding explanation tends
more to organizational complexity than the intended technical complexity. From the
responses it seems that the implications of uncertainties in scope can be found in
organizational complexity. Still, the cause of the complexity is to be found in the technical
area. The project type also potentially obscures the results: not in all project types a
design is involved (e.g. what is meant with the design in a consultancy project?). In the
current data set however this was not the case since merely pure design / engineering
projects and construction projects were involved (53 out of 67). For future use, the
formulation of the survey question should be adapted to make the link with technical
complexity more explicit, for example more focussed on the extent to which the project
specifications are known at the moment of FID.
Because of the relevant correlations to other TOE elements, the obtained data for this
element can in the current analysis. For future use, the survey question should be rephrased.
TOE
T
Sub-ordering
Scope
ID
TS3
Elements defined
Quality requirements
Correlation result
T**, E
Action proposed
Use data
awareness (rs = -.277, p=.028) are worth mentioning: high quality requirements coincide
with high technical risks and high quality requirements coincide with high HSSE awareness
in the projects under consideration. The fact that a significant correlation was found with
perceived environmental complexity suggests that environmental complexity was at least
partly interpreted as being related to environmental protection. Because of the stronger
correlation to perceived technical complexity, shifting this element to the environmental
category is not considered. The obtained data for this element can be used in the current
analysis.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Tasks
TT1
Number of tasks
Action proposed
Do not use data,
rephrase
survey
question
The element number of tasks (elm_TT1) does not correlate to any perception of complexity.
It does, however, significantly correlate to a number of size-related elements such as scope
largeness, size of the project team, number of locations, number of different nationalities
hence indicating it measures what it was intended to measure. However, it doesnt seem to
contribute to complexity in view of the respondents. The survey question corresponding to
this element asks for the number of work packages in the project as the measure for the
number of tasks. Although this measure sounds firm and clear (just count the number of
WPs in the project), it ignores scale differences of projects and, more importantly, the
specific company perception. Rather than further detailing this question, a more fuzzy
measure like the number of tasks of the project relative to a typical project for the company
could be used. Despite the significant elements correlations to size-related elements, a shift
of this element to the O-category is not considered. Rather, several size-related elements
will be shifted to the T-category as will be explained later. The obtained data for this
element should not be used in the current analysis.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Tasks
TT2
Variety of tasks
Action proposed
Do not use data,
rephrase
survey
question
The element variety of tasks (elm_TT2) scores also poorly: no significant relations with any
aspect of perceived complexity and no meaningful other correlations are found. This most
probably is related to the example given in the survey question. This example is confusing:
it talks about engineering part x, engineering part y as similar tasks, but even within
engineering tasks, variation may occur. Because of their merely engineering background,
some of the respondents might have had a different interpretation of this question. The
example should be rephrased. On top of that, the specific survey question included the
following answering options: not (9), little (17), substantial (32), which could be
insufficiently distinctive. The scale should be changed to a least a 5-point scale. The
obtained data should therefore not be used in the current analysis.
271
Sub-ordering
ID
Tasks
TT3
Elements defined
Dependencies
between tasks
Correlation result
T
Action proposed
Use data, rephrase
survey question
The element dependencies between tasks (elm_TT3) scores slightly better with a weak,
hardly significant, positive correlation to perceived technical complexity (rs = .219,
p=.102). No meaningful correlations with other elements are found. Probably this is related
to the corresponding survey question, that only distinguished no, little or substantial
dependency with the vast majority (38) of the answers being substantial (little: 14, none: 5,
missing: 10). The scale of the survey question should be extended to a five-point scale for
future use. The obtained data for elm_TT3, however, can be used in the current analysis.
TOE
T
Sub-ordering
Tasks
ID
TT4
Elements defined
Uncertainty in methods
Correlation result
T*
Action proposed
Use data
TOE
Sub-ordering
ID
Elements defined
Correlation
result
Tasks
TT5
Interrelations between
technical processes
Action proposed
Do not use data, rephrase
survey
question
The element interrelations between technical processes (elm_TT5) does not correlate to
any perception of complexity. It shows unexpected significant negative correlations to
organizational risks (rs=-.388, p=.002) and dependencies on other stakeholders (rs=-.331,
p=.009). More interrelation between technical processes coincides with lower
organizational risks and less dependencies on other stakeholders; which both make no
sense. The survey question asked to what extent the technical processes in the project have
interrelations with existing processes, but, apart from the somewhat vague formulation of
this question (technical processes in the project: what is meant with a technical process?),
the answering options were chosen rather narrow (none, little, substantial). In the current
data set, almost all projects (60 of 67) scored little (20 projects) or substantial (40 projects).
This question should be adapted towards at least a 5-point (Likert) scale. The obtained data
for this element should not be used in the current analysis.
272
Sub-ordering
ID
Tasks
TT6
Elements defined
Conflicting norms
and standards
Correlation result
Action proposed
O*
Use data
The element conflicting norms and standards (elm_TT6) shows a weak positive correlation
to perceived organizational complexity (rs=.404, p=.015), rather than the expected
perceived technical complexity. This element shows weak positive correlations to elements
such as unaligned goals, unclear goals, interfaces between different disciplines,
organizational risks and interference with existing site. The occurrence of conflicting
norms and standards coincides with more unaligned goals, unclear goals, interface
problems with different disciplines, higher organizational risks and more interference with
the existing site. This already indicates why a correlation with perceived organizational
complexity is found: despite the intended technical character of this element, its
implications are more in the organizational area. However, the cause of the complexity is
still in the technical area and therefore should not be shifted to the O-category. Because of
its relevant correlations with other TOE elements, the obtained data can be used in the
current analysis.
TOE
Sub-ordering
ID
Experience
TE1
Elements defined
Newness
of
technology (worldwide)
Correlation result
Action proposed
T, O
Use data
TOE
Sub-ordering
ID
Experience
TE2
Elements defined
Lack of experience
with technology
Correlation result
-
Action proposed
Use data, rephrase
survey question
The element lack of experience with technology (elm_TE2) does not correlate to any
perception of complexity, but largely overlaps with the element newness of technology
(world-wide) in the correlations with other elements. One reason for not finding significant
correlations with perceived complexity might be related to the fact that the respondents
were rather positive in answering the survey question corresponding to element elm_TE2 (1
missing value): none strongly disagreed, 10 respondents disagreed with the statement that
273
the parties involved had applied the technology involved in the project before, 11
respondents were neutral and the other 45 agreed (29) or strongly agreed (16). Their
relative positivism on the experience could not be explained by their own work experience
or their role in the project. Despite the overlap with elm_TE1 in a number of relevant
correlations, combination of these elements is not suggested. Rather, it is suggested to
rephrase the survey question related to this element to more specifically (per party
involved!) address the issue of experience, of course limited to certain main parties like for
example the main contractor, the project owner and the main subcontractor. The obtained,
merely positive, data for elm_TE2 can still be used in the current analysis.
TOE
T
Sub-ordering
Risk
ID
TR1
Elements defined
Technical risks
Correlation result
T**, O*
Action proposed
Use data
The element technical risks (elm_TR1) shows a moderate positive correlation with
perceived technical complexity (rs=.534, p=.000) and a weak positive correlation with
perceived organizational complexity (rs=.298, p=.015). Also, this element shows weak to
moderate positive correlations to quality requirements, uncertainties in methods, newness
of technology, lack of experience with technology, interfaces between different disciplines,
organizational risk and interference with existing site. Higher technical risks coincide with
higher quality requirements, more uncertainties in methods, application of new technology,
lack of experience with technology, interface problems, higher organizational risks and
occurrence of interference with the existing site. These correlations all make sense and the
obtained data for element elm_TR1 can be used in the current analysis. No move of this
element to the O-category is considered because of the stronger correlation with the
(expected) perceived technical complexity. The correlation results for this element actually
confirm the cross-correlation between perceived technical complexity and perceived
organizational complexity.
D.2: Correlation of O-elements and perceived complexity
All correlations results between the O-elements of the TOE framework and perceived
complexity are shown in Table D.2. Next, for all O-elements a summary of the findings is
given, followed by the interpretation of the results.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Size
OS1
Project duration
Action proposed
Use data, move to Tcategory
The element project duration (elm_OS1) shows a very weak and hardly significant positive
correlation with perceived technical complexity (rs = .205, p=.097). E.g. perceived
technically complex projects coincide with longer project durations, which intuitively does
make sense, but is not necessarily the case. No relation, however, with perceived
organizational complexity was found, whereas was expected that longer projects would
coincide with perceived organizational complexity. As could be expected, weak to
moderate correlations were found with other size related elements (size in capex, size in
engineering hours, number of stakeholders) as well as with contract types and required
local content. A project with a longer duration coincides with higher capital expenditure,
more engineering hours, more stakeholders, more contract types and more required local
content. A notable correlation was found with lack of company internal support, indicating
274
that projects with a longer duration coincide with higher scores for company internal
support. Why project duration is not associated with perceived organizational complexity
might be related to the current project sample: half of the projects (33 out of 67 projects)
had a planned duration between 12 and 24 months. Another explanation could be that
project duration does not have a linear relation with project complexity: both very short
projects and very long projects might be complex, for different reasons. This latter
explanation, however, could not be supported with the current data.
This element project duration is one of the various size elements in the current TOE
framework and, in general, reduction of the amount of size elements should be considered.
Also, a shift of all relevant size related elements to the T-category is proposed, because the
T-category contains those elements that can be associated with the project content, or
project scope. Inherently, size aspects should also be considered in that scope part, e.g.
move to the T-category. Hence the element project duration should be moved to the Tcategory and the obtained data can be used in the current analysis.
TOE
Sub-ordering
ID
Size
OS2
Elements defined
Compatibility of different
project
management
methods and tools
Correlation result
Action
proposed
O**, E*
Use data
The element compatibility of different project management methods and tools (elm_OS2)
shows a moderate positive correlation with perceived organizational complexity (rs=.478,
p=.000) and a much weaker positive correlation with perceived environmental complexity
(rs =.262, p=.035). Several correlations with other T- and O- elements were found, mostly
with elements related to uncertainties (unaligned goals, uncertainties in scope,
uncertainties in methods, newness of technology, project drive, resource and skills scarcity,
interfaces between different disciplines and organizational risks). No correlations of
elm_OS2 with any E-elements in the framework were found and the weak correlation with
perceived environmental complexity is therefore not well understood other than just
coincidental. The moderate correlation with perceived organizational complexity, however,
shows this element should stay in the O-category and the obtained data can be used in the
current analysis.
275
elm_OS1:
project duration
elm_OS2:
compatibility PM methods
and tools
elm_OS3:
size in CAPEX
elm_OS4:
size in eng. hours
elm_OS5:
size of project team
elm_OS6:
size of site area
elm_OS7:
number of locations
elm_ORE1:
project drive
elm_ORE2:
resource and skills
scarcity
elm_ORE3:
lack of exp with parties
involved
elm_ORE4:
lack of HSSE awareness
elm_ORE5: interfaces
between diff disciplines
elm_ORE6:
number of financial
resources
elm_ORE7:
contract types
elm_OP1:
number of different
nationalities
elm_OP2:
number of diff languages
elm_OP3:
co-operation JV partner
elm_OP4: overlapping
office hours
elm_OT1:
lack of trust in project
team
elm_OT2:
lack of trust in contractor
elm_OR1: organizational
risks
276
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Perceived
technical
complexity
.205
.097
67
.187
.132
66
.013
.921
63
.036
.808
48
.092
.505
55
-.148
.233
67
.031
.804
67
.055
.659
67
.004
.975
67
.080
.525
65
-.120
.351
63
.240
.050
67
.052
.682
64
.123
.346
61
.117
.346
67
.005
.965
67
.133
.283
67
.114
.365
65
.057
.648
66
-.010
.942
52
.075
.550
66
Perceived
organizational
complexity
-.004
.975
67
.478**
.000
66
.117
.361
63
.022
.880
48
.301*
.026
55
.138
.267
67
.207
.092
67
.226
.066
67
.447**
.000
67
.161
.201
65
.224
.078
63
.534**
.000
67
.057
.657
64
.090
.492
61
.189
.126
67
.255*
.038
67
.144
.243
67
-.008
.948
65
.043
.734
66
.066
.642
52
.634**
.000
66
Perceived
environmental
complexity
.145
.245
66
.262*
.035
65
.051
.693
63
-.123
.409
47
.103
.455
55
.051
.686
66
-.001
.992
66
.270*
.028
66
.136
.275
66
.037
.770
64
-.015
.906
62
.130
.299
66
-.036
.782
63
-.103
.433
60
-.087
.490
66
-.170
.172
66
.228
.065
66
.029
.823
64
-.024
.846
65
.082
.569
51
.146
.247
65
Sub-ordering
ID
Elements defined
Correlation result
Size
OS3
Size in CAPEX
Action proposed
Use data, move to
T-category
The element size in capex (elm_OS3) does not correlate to any perception of complexity,
but does correlate to other size related elements such as size in engineering hours, size of
site area and number of different nationalities. The negative correlation with the number of
strategic goals was already discussed above: apparently bigger projects tend to focus on a
lesser amount of goals. Also a weak positive correlation with organizational risks was
found: a higher CAPEX coincides with more organizational risks.
No explanation for the absence of a clear correlation between size in capex and perceived
complexity could be found by calculating partial correlations between size in CAPEX and
perceived complexity while controlling for the company turnover in 2008. For the
company turnover, respondents could indicate whether their company had a turnover less
than 10 million Euro, between 10 and 100 million Euro, between 100 million and 1 billion
Euro or over 1 billion Euro. When controlling for the company turnover, weak
correlations were found with perceived technical complexity (r =.236, p=.069) as well as
with perceived organizational complexity (r = .247, p=.057). However, partial correlations
with SPSS are using Pearsons correlation techniques and Pearsons zero-order correlation
results already indicate a weak, significant correlation of size in capex with perceived
organizational complexity (r =.262, p=.041). Hence controlling for turnover does only
improve the correlation with perceived technical complexity and (slightly) worsens the
correlation with perceived organizational complexity. Since Pearsons correlation technique
is known to be sensitive for outliers (Altman, 1991), it is more likely that the measure of
size as such is not directly associated with project complexity; see also the considerations
after the discussion of all separate size elements. Still, the obtained data for this element can
be used in the current analysis. Since the element CAPEX is scope related, this element is
moved to the T-category.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Size
OS4
Size
in
Engineering hours
Action proposed
Do not use data,
remove
from
framework
The element size in engineering hours (elm_OS4) does not correlate significantly to any
perception of complexity either, but it correlates weak to moderate to various other
elements related to project size. From scatter plot analysis some outliers were identified
(cases 17, 61, 66, 99), but removing these cases from the data did not result in significant
correlations between elm_OS4 and any form of perceived complexity. One reason for the
absence of any correlation with perceived complexity might be the difficulty of (some?)
respondents to correctly estimate the man-hours involved in the project. This is supported
by the results of calculating partial correlations between elm_OS4 and perceptions of
complexity, controlling for the role of the respondent in the project. In that case, a very
weak correlation is found between elm_OS4 and perceived technical complexity (r =.278,
p=.062), indicating an increasing number of engineering hours coincides with a higher
perception of technical complexity. Because of the uncertainties related to estimating the
rough amount of man-hours, removal of this element from the TOE framework should be
considered. The obtained data should not be included in the current analysis.
277
Sub-ordering
Size
ID
OS5
Elements defined
Size of project team
Correlation result
O*
Action proposed
Use data
The element size of the project team (elm_OS5) shows a weak positive correlation to
perceived organizational complexity (rs = .301, p=.026). The size of the project team was
the total number of persons working simultaneously on the project, including workers. Also
several weak to moderate, significant correlations with other size related elements were
found. The obtained data for this element can be used in the current analysis.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Size
OS6
Action proposed
Do not use data,
remove
from
framework
The element size of site area (elm_OS6) does not significantly correlate to any perception
of complexity. This element shows various weak to moderate, significant correlations with
other size related elements. The absence of a significant correlation with any perception of
complexity might be related to the difficulty of estimating the size of the site area (similar
to the difficulties of estimating elm_OS4) for all respondents and the fact that this measure
cannot be applied for all project types. To support the first explanation: when removing the
data entries with zero area and controlling for the role of the respondent in the project by
calculating partial correlations, a very weak correlation was found between elm_OS6 and
perceived organizational complexity (r = .253, p=.079). Hence for a limited group of
respondents a relation could be found between site area and organizational complexity,
indeed suggesting that not all respondents could well estimate the site area. Another issue
with this element is that both a very small (crowded) site area and a very large site area
could be considered as contributing to complexity. Because of the uncertainties related to
estimating the rough size of the site area, removal of this element from the TOE framework
might be considered. The obtained data should not be included in the current analysis.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Size
OS7
Number of locations
Action proposed
Use data, move to
T-category
The element number of locations (elm_OS7) shows a weak, hardly significant, correlation
to perceived organizational complexity (rs = .207, p=.092). Also weak correlations are
found with elements like uncertainties in scope, number of tasks, size of the project team,
size of the site area, resource and skills scarcity, number of stakeholders and level of
competition. E.g. an increased number of project locations coincide with more uncertainties
in scope, a higher number of tasks, a larger project team, a larger site area, more problems
with availability of resources and skills, more stakeholders involved and a higher level of
competition. Since the number of locations can also be seen as a scope related complexity
elements, this element should be moved to the T-category. The obtained data for this
element can be used in the current analysis.
Concluding the discussion of this list of size elements, it is noted we expected more and
stronger significant correlations of these element with perceived organizational complexity.
Particularly, because in literature, project size, although distinguished from complexity and
278
TOE
Sub-ordering
ID
Elements defined
Correlation result
Resources
ORE1
Project drive
O, E*
Action proposed
Use
data
for
schedule
drive,
rephrase question
The element project drive (elm_ORE1) shows a weak positive correlation to the perceived
environmental complexity (rs = .270, p=.028) and a weak, hardly significant, correlation to
the perceived organizational complexity (rs = .226, p=.066). This element was measured
combining the scores for the drive in cost, schedule, quality and other (indicated by
respondent), thereby cancelling out the obtained results. A more detailed analysis into these
separate measures showed that from these separate measures, only the schedule drive has
weak, hardly significant, positive correlation to the perceived organizational complexity
(rs=.222, p=.071). For elm_ORE1, weak positive correlations were found with compatibility
of different project management methods and tools (more project drive coincides with more
compatibility-issues in PM tools and methods) and lack of experience in the country (more
project drive coincides with less experience in the country). A narrower definition of
project drive (i.e. only related to schedule) should be considered. With such a narrower
definition, this element could stay in the organizational category. The obtained data for this
element with respect to schedule drive can be used in the current analysis.
TOE
Sub-ordering
ID
Resources
ORE2
Elements defined
Resource and skills
scarcity
Correlation result
Action
proposed
O**
Use data
The element resource and skills scarcity (elm_ORE2) shows a moderate positive
correlation to perceived organizational complexity (rs=.447, p=.000). Moderate positive
correlations were also found with the elements compatibility of project management
methods and tools and interfaces between different disciplines: less available resources and
skills coincides with compatibility and interface problems. Multiple other weak positive
correlations were found. The obtained data for this element can be used in the current
analysis.
279
TOE
Sub-ordering
ID
Resources
ORE3
Elements defined
Lack of experience
with
parties
involved
Correlation
result
Action proposed
The element lack of experience with the parties involved (elm_ORE3) does not correlate to
any perception of complexity, neither to any other experience related elements. It shows a
moderate positive correlation to the element lack of trust in contractor (rs=.448, p=.001),
indicating more experience with the parties involved (including contractors) coincides with
an increase in trust in the contractor. The survey question related to this element asked to
indicate whether, prior to this project, the respondents company had worked with the
project party (options: never, seldom, sometimes, often), for all parties involved in the
project. If there were more parties with similar roles in the project (e.g. more than one
subcontractor, contractor, etc), the question had to be answered for the party with the most
substantial contribution to the project. In hindsight, this formulation was rather complex
and should be simplified for future application.
Overall, in only 17 cases, the company never or seldom had worked with the other project
parties, prior to this project. Hence in the vast majority of the cases (48, two missing
values) the project parties knew each other from previous projects. Note that the mean
value of the experience scores for all parties involved was used to come to an average
experience score for all involved parties, thereby potentially cancelling out the obtained
results. However, neither the separate scores for the different parties involved resulted in
significant correlations with perceived complexity.
Despite the absence of a significant correlation with any form of perceived complexity, it is
felt that this element is relevant for the complexity framework although the corresponding
survey question needs rephrasing. Because of the relevant correlation with the element lack
of trust in the contractor the data for experience with the parties involved can be used in the
current analysis.
TOE
Sub-ordering
ID
Resources
ORE4
Elements defined
Lack of HSSE
awareness
Correlation result
Action proposed
Use data
The element lack of HSSE awareness (elm_ORE4) shows a very weak positive correlation
to perceived organizational complexity (rs=.224, p=.078). The element shows two very
weak negative correlations to the elements quality requirements (discussed above,
elm_TS3) and variety of tasks (discussed above, elm_TT2 needs redefinition). Weak
positive correlations are found with the elements size of site area (lack of HSSE awareness
coincides with larger site), lack of experience with the parties involved (more experience
with the parties involved coincides with more HSSE awareness), and political influence
(lower HSSE awareness coincides with higher political influence). The obtained data for
this element can be used in the current analysis.
280
TOE
Sub-ordering
ID
Resources
ORE5
Elements defined
Interfaces
between
different disciplines
Correlation result
Action
proposed
O**, T*
Use data
TOE
Sub-ordering
ID
Correlation result
Action proposed
ORE6
Elements defined
Number of financial
resources
Resources
ORE7
Contract types
Use data
Use
data,
rephrase survey
question
Resources
The elements number of financial resources (elm_ORE6) and contract types (elm_ORE7)
both do not correlate to any perception of complexity and hardly to any other elements than
to each other (rs =.338, p=.009). The absence of significant correlations to perceived
complexity for elm_ORE6 is related to the fact that 50 of the 67 projects under
investigation had one single financial resource. The current project sample is therefore not
suited to measure the relation between the number of financial resources and perceived
complexity. This could also be the cause of the absence of significant correlations between
elm_ORE7 and perceived complexity, but here the survey question might also need
reformulation. The survey question contained the following answering options for the
question about the contract types (6 times do not know): only one contract involved (14),
all main contracts involved were of the same type (12), two types of main contracts were
involved (11), more than two types of main contracts were involved (24). The scale mixes
both number and type of contracts, whereas the focus should be clearer on the number
contracts to be managed, regardless of contract type. Whereas the element elm_ORE6 can
remain unchanged in the TOE framework, elm_ORE7 and particular the corresponding
survey question need reformulation. The obtained data for both elements can be used in the
current analysis.
281
Project team
OP1
Elements defined
Number of different
nationalities
Correlation result
-
Action proposed
Use data, rephrase
survey question
The element number of different nationalities (elm_OP1) does not correlate to any
perception of complexity. This absence is caused by the fact that, in the current project
sample, one very dominant answer was given to the related survey question. One
nationality was involved in 8 projects, two to five in 42 projects, five to ten in 8 projects
and more than ten in 9 projects. Several weak positive correlations are found with size
related elements such as scope largeness, number of tasks, size in capex, size in engineering
hours, size of project team. A moderate positive correlation is found with lack of experience
in the country, indicating that more different nationalities in the project team coincide with
less experience in the country. The answering scale of the related survey question needs
adjustment (e.g. could be changed to open question asking for the number of nationalities
involved). Because of the meaningful correlations to other TOE elements, the obtained data
for this element could be used in the current analysis.
TOE
Sub-ordering
ID
Project team
OP2
Elements defined
Number of different
languages
Correlation result
Action proposed
O*
Use data
The element number of different languages (elm_OP2) shows a weak positive correlation to
perceived organizational complexity (rs = .255, p=.038). This element shows weak negative
correlations with the elements number of goals and environmental risks, i.e. having more
languages in the project team coincides with less environmental risks (to illustrate: think of
environmental risks with a local cause, which could be better treated when speaking the
local language) and a lower number of strategic goals. The latter is not logical, but this
result might be related to a sample issue: more than half of the respondents (37) indicated
there were 2 languages used in the project. Because of the weak correlation found with
organizational complexity, the obtained data for elm_OP2 can be used in the current
analysis.
TOE
Sub-ordering
ID
Project team
OP3
Elements defined
Co-operation
JV
partner
Correlation result
Action proposed
Use data
The element co-operation with JV partner (elm_OP3) shows a weak, hardly significant,
correlation to perceived environmental complexity (rs=.228, p=.065); e.g. when there is a
JV partner in the project, the perceived environmental complexity is higher. We expected a
significant correlation with the organizational complexity instead. The absence of this
expected correlation is related to the current sample, in which only in 6 cases a JV partner
was cooperating. In the other 61 cases no JV partner was involved. Despite these sample
limitations, the element OP3 shows weak correlations to quality requirements, conflicting
norms and standards, and political influence, e.g. the presence of a JV partner coincides
with high quality requirements, the occurrence of conflicting norms and standards and
higher political influence. Because of the sample limitations, there is no reason to move the
element to the E-category, despite the weak correlation to perceived environmental
complexity. The obtained data for this element could be used in the current analysis.
282
TOE
Sub-ordering
ID
Project team
OP4
The element overlapping office hours (elm_OP4) does not correlate to any perception of
complexity and needs redefinition. The question related to elm_OP4 seems to be
misinterpreted: the term overlapping confused (the majority of?) the respondents here. In
total 5 respondents indicated there were 7 to 8 overlapping office hours, 2 indicated there
were 5 or 6 overlapping office hours, 8 indicated there were 3 or 4 overlapping office
hours, 7 indicated there were 1 or 2 overlapping office hours and 43 indicated there were no
overlapping office hours (2 missing values). The latter was meant to indicate that the
project would run in completely different time-zones, but is probably interpreted (also) as
no issues with overlapping office hours. Therefore the corresponding survey question
needs adjustment, e.g. were there different time-zones involved, with answering options:
only one time-zone involved, two time-zones involved with negligible time difference (1 or
2 hours), two time-zones involved with considerable time difference (3 to 6 hours), two
time-zones involved with severe time difference (more than 6 hours), three time-zones
involved with considerable or severe time differences. The obtained data for this element
should not be used in the current analysis, but the element should stay in the complexity
framework.
TOE
Sub-ordering
ID
Trust
OT1
Trust
OT2
Elements defined
Lack of trust in
project team
Lack of trust in
contractor
Correlation result
-
Action proposed
Use data, rephrase
survey question
Use data, rephrase
survey question
The elements lack of trust in project team (elm_OT1) and lack of trust in contractor
(elm_OT2) do not correlate at all to any perception of complexity. The survey question
related to lack of trust in project team was a statement to be scored on a Likert scale:
before the project activities started there was a trusting relationship between the team
members in the project management team. The results indicate that often a trusting
relationship is present: 11 strongly agree, 32 agree, 14 neutral, 7 disagree, 2 strongly
disagree and one missing value. This predominantly positive answer might explain why no
correlations are found between lack of trust in the project team and any perception of
project complexity. The survey question related to lack of trust in the contractor consists of
several aspects (trust in managing contractor, trust in engineering contractor, trust in
subcontractor) of which the applicable mean value was used for analysis. Detailed analysis
in the separate aspects did not result in significant correlations either. Similar to the
elm_OT1 analysis, predominantly positive answers are found, indicating high trust
relationships with the contractors involved in the current project sample. A moderate
positive correlation was found between lack of trust in the contractor and lack of
experience with the parties involved (rs = .448, p=.001): more trust coincides with more
experience with the parties involved (elm_ORE3). Both trust elements show a weak
positive correlation to the element political influence: lower trust coincides with higher
political influence, which seems reasonable.
The absence of a correlation between trust (in either project team or contractor) and
perceived organizational complexity might also be explained by the fact that the majority of
283
the companies had experience with the involved parties and it is likely that they will not
start working again with parties (persons) which they do not trust. In other words, at the
beginning of a project, trust is not an issue, which might however change during the
project. The survey did not cover this, but a link between the trust elements and perceived
complexity maybe would have been found if the question was not focussed on before the
project started. This explanation is supported by the weak correlation found in Table 6.4
between trust as a factor endangering the project outcome and perceived organizational
complexity.
For further use of the framework (not only at the beginning of a project, but also during the
project) the survey question needs reformulation. Despite the merely positive answers and
hence limited contribution to complexity, the obtained data for these elements can be used
in the current analysis.
TOE
O
Sub-ordering
Risk
ID
OR1
Elements defined
Organizational risks
Correlation result
O**
Action proposed
Use data
284
elm_ES1:
number of stakeholders
elm_ES2:
variety of stakeholders
perspectives
elm_ES3: dependencies on
other stakeholders
elm_ES4:
political influence
elm_ES5:
lack of company internal
support
elm_ES6:
required local content
elm_EL1:
interference with existing
site
elm_EL2:
weather conditions
elm_EL3:
remoteness of location
elm_EL4:
lack of experience in the
country
elm_EM1:
internal strategic pressure
elm_EM2:
instability project
environment
elm_EM3:
level of competition
elm_ER1:
risks from environment
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Correlation Coefficient
Sig. (2-tailed)
N
Perceived
technical
complexity
Perceived
organizational
complexity
Perceived
environmental
complexity
.019
.886
57
-.007
.955
64
.256*
.045
62
-.253*
.045
63
-.053
.670
66
.047
.750
48
.176
.161
65
.077
.543
64
-.122
.330
66
.022
.858
67
-.112
.375
65
.040
.749
66
-.025
.844
66
-.098
.433
66
.238
.074
57
.393**
.001
64
.446**
.000
62
.196
.123
63
.145
.245
66
-.019
.897
48
.212
.090
65
.154
.224
64
.077
.539
66
.219
.076
67
.018
.889
65
.227
.066
66
.147
.240
66
-.071
.571
66
.088
.516
57
.029
.819
64
.135
.295
62
.097
.452
62
.020
.872
65
.005
.972
47
.092
.471
64
-.033
.798
63
.133
.291
65
.086
.494
66
-.147
.245
64
.211
.091
65
.160
.202
65
.367**
.003
65
285
Note that only a few correlations with perceived environmental complexity are found. On
the one hand, this might be related to a different interpretation of environmental
complexity, i.e. in terms of protection of the environment / global warming issues /
environmental activists and not in terms of external, surrounding etc. This suggestion is
supported by the findings in Table 6.4 where issues related to two of the four Esubcategories are not correlating at all to perceived environmental complexity (stakeholder
issues and project location issues). On the other hand, project managers in general might
have less feeling for environmental aspects: the technical part they were educated in, the
organizational part is the part they are facing during their management tasks and the
environmental aspects are further away from their daily experience. Finally, also the project
sample might play a role, as will become clear in the detailed discussion of all the Eelements.
None of the stakeholder elements (elm_ES1 to elm_ES6) show a significant correlation to
perceived environmental complexity. Some of the individual elements do show correlations
to perceived technical and / or organizational complexity. In defining the TOE framework,
the stakeholder elements were deliberately considered as environmental aspects, whereas
environment refers to the surrounding of the project; external factors that influence the
project; i.e. external stakeholders.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Stakeholders
ES1
Number of stakeholders
Action
proposed
Use
data,
rephrase
survey
question
TOE
Sub-ordering
ID
Stakeholders
ES2
Elements defined
Variety
of
stakeholders'
perspectives
Correlation result
Action proposed
O**
stakeholders, lack of company internal support and interference with existing site. Varied
stakeholders perspectives coincide with more unaligned goals, unclarity of goals, more
uncertainties in methods, unavailability of resources and skills, more organizational risks,
more dependencies on other stakeholders, lower company internal support and more
interference with the existing site. Again, respondents feel the implications of this type of
complexity in the organizational area. Because of the intended focus on external
stakeholders, this element should stay in the E-category but the survey question should be
rephrased. The obtained data can be used in the current analysis.
TOE
Sub-ordering
ID
Stakeholders
ES3
Elements defined
Dependencies
on
other stakeholders
Correlation result
T*, O**
Action proposed
Use data, rephrase
survey question
TOE
E
Sub-ordering
Stakeholders
ID
ES4
Elements defined
Political influence
Correlation result
T* (neg)
Action proposed
Use data
The element political influence (elm_ES4) shows a weak negative correlation to perceived
technical complexity (rs = -.253, p=.045). Hence more influence of politics coincides with
lower technical complexity, which is a strange relation, unless, under pressure of politics,
the content of a project changes to lower technical complexity. The unexpected correlation
with perceived technical complexity and the absence of the expected correlation with
perceived environmental complexity can be explained looking at the answers to the
corresponding survey question. To measure political influence, the respondents had to
indicate which answer applied best to the situation in the project for the statement: the
political situation in the country did influence the project. About one third of the
respondents strongly disagreed (22 responses), another third disagreed (23 responses), 5
respondents were neutral, 7 agreed and 6 strongly agreed (4 missing values). Since political
287
influence did only play a role in 13 of the 67 projects, limitations in the current project
sample are thought to explain the absence of the expected relations.
The element political influence shows weak positive correlations to elements such as HSSE
awareness, lack of trust in project team, lack of trust in contractor, organizational risks
and lack of experience in the country. E.g. higher political influence coincides with lower
HSSE awareness, lower trust in the project team, lower trust in the contractor, higher
organizational risks and lower experience in the country. A moderate positive correlation is
found with remoteness of location (rs = .404, p=.001): more political influence coincides
with a more remote location, possibly referring to stringent political regimes in certain
remote areas. Because of the meaningful correlations with other E-elements, the element
should stay in the E-category and not move to the T-category. The obtained results for this
element can be used in the current analysis.
TOE
Sub-ordering
ID
Stakeholders
ES5
Elements defined
Lack of company
internal support
Correlation result
Action proposed
Use data
The element lack of company internal support (elm_ES5) does not correlate to any
perception of complexity. The main reason for the absence of the(se) correlation(s) is
related to the massively dominant positive answers of the respondents: 29 respondents
agree and 28 respondents fully agree that my companys business representatives and the
senior management supported the project throughout (2 disagreed, 7 neutral, 1 missing
value). The lack of company internal support shows weak positive correlations to unaligned
goals, unclear goals, resource and skills scarcity, variety of stakeholder perspectives,
interference with existing site, weather conditions and lack of experience in the country.
E.g. more company internal support coincides with better goal alignment, more clarity of
goals, better availability of resources and skills, less varied stakeholder perspectives, less
interference with existing site, less problems due to weather conditions and more
experience in the country. The weak negative correlation with project duration (rs = -.264, p
= .032) indicates that a longer project duration coincides with more company internal
support. Because of the reasonable correlations with other elements of the TOE framework
and despite the absence of a correlation with perceived environmental complexity, the
obtained data for this element can be used in the current analysis.
TOE
E
Sub-ordering
Stakeholders
ID
ES6
Elements defined
Required local content
Correlation result
-
Action proposed
Use data
The element required local content (elm_ES6) does not correlate to any perception of
complexity. Again this is related to a sample limitation. Not for all projects in our sample
this question was applicable (16 responses), some respondents did not know (3), the
majority of the respondents indicated that no local content was required (34), some
indicated that little local content was required (8) and some indicated that substantial
local content was required (6). The element required local content still shows a weak
positive correlation to remoteness of location (more required local content coincides to a
more remote location, which might refer to particular type of (large) projects) and a
moderate positive correlation to project duration (more required local content coincides to
longer projects). Therefore, despite the absence of a correlation with perceived
288
environmental complexity, the obtained data for this element can be used in the current
analysis.
None of the location related elements (elm_EL1 to elm_EL4) does clearly correlate to
perceived environmental complexity. The absence of correlations with perceived
environmental complexity might be caused by problems in defining perceived
environmental complexity, see also Table 6.4 where no correlation was found between
project location issues and perceived environmental complexity. A detailed look at the
element scores clarifies the current results.
TOE
Sub-ordering
ID
Location
EL1
Elements defined
Interference
with
existing site
Correlation result
Action proposed
Use data
The element interference with existing site (elm_EL1) shows a weak, hardly significant,
correlation to perceived organizational complexity (rs = .212, p=.090). It shows weak
positive correlations to technical risks, variety of stakeholders perspectives, lack of
company internal support and weather conditions. E.g. the occurrence of interference with
the existing site coincides with increased technical risks, more varied stakeholders
perspectives, lower company internal support and more problems due to weather
conditions. Apart from the latter, these correlations make sense. The organizational
implications of interference with the existing site seem to be recognized by the respondents,
rather than the fact they stem from the environment and hence could be considered
environmentally complex. Because of the meaningful correlation with other elements, the
obtained data for this element can be used in the current analysis. No move to the Ocategory is considered, because of the before mentioned, suggested problem in the
definition of perceived environmental complexity.
TOE
E
Sub-ordering
Location
ID
EL2
Elements defined
Weather conditions
Correlation result
-
Action proposed
Use data
The element weather conditions (elm_EL2) does not correlate to any perception of
complexity. It shows a few weak positive correlations (with conflicting norms and
standards, lack of company internal support, interference with existing site and lack of
experience in the country) and one positive moderate correlation to remoteness of location
(rs = .479, p=.000). The absence of correlations with any perception of project complexity
is related to the answers given to the corresponding survey question. The question, in the
form of the statement we expected extreme weather conditions to influence the project
progress, was answered predominantly negative, e.g. 16 respondents strongly disagreed,
29 disagreed, 15 were neutral, 4 agreed and there were 3 missing values. Despite the
moderate correlation to remoteness of location, combination with elm_EL3 is not
considered: weather conditions might also influence the project in a non-remote area. The
obtained data for this element can be used in the current analysis.
289
Elements defined
Remoteness of location
Correlation result
-
Action proposed
Use data
The element remoteness of location (elm_EL3) does not correlate to any perception of
complexity. It shows a few weak positive correlations (with required local content, lack of
experience in the country and instability of the project environment) and two moderate
positive correlations with political influence (rs = .404, p=.001) and weather conditions (rs
= .479, p=.000). E.g. a more remote project location coincides with more required local
content, less experience in the country, a less stable project environment, higher political
influence and problems with extreme weather conditions). The survey results show
limitations of our project sample: only 9 projects were in a remote area, 50 projects were
not and for 7 projects the answer was neutral (1 missing value). Still meaningful
correlations with other E-elements were found. Therefore, despite the absence of significant
correlations with any form of perceived complexity, the data obtained for this element can
be used in the current analysis.
TOE
Sub-ordering
ID
Location
EL4
Elements defined
Lack of experience
in the country
Correlation result
Action
proposed
Use data
The element lack of experience in the country (elm_EL4) shows a weak, hardly significant,
correlation to organizational complexity (rs = .219, p=.076). It shows a moderate positive
correlation to the number of different nationalities (rs = .449, p=.000), indicating that more
nationalities in the project team coincide with a lack of experience in the country. This is
counter-intuitive: with more nationalities in the project team one could expect (more chance
on) sufficient experience in the country. An explanation might be related to the fact that the
respondents predominantly agreed (26) or strongly agreed (31) with the statement my
company had sufficient experience in the country where the project was performed. Their
positivism might be explained by the project sample that probably consists of projects
predominantly performed in one single country, which was however not included in the
survey questions. For elm_EL4, some weak positive correlations are found with elements
such as project drive, political influence, lack of company internal support, weather
conditions, remoteness of location and instability of the project environment. E.g. a lack of
experience in the country coincides with a stronger project drive, higher political influence,
higher lack of company internal support, more remote location and a more instable project
environment. These correlations, primarily with E-elements, indicate that the
operationalization of the E-elements in general make sense. The absence of a correlation
with perceived complexity might be more related to misinterpretation of environmental.
The obtained data for this element can be used in the current analysis and no move of this
element to the O-category is considered.
TOE
Sub-ordering
ID
Elements defined
Correlation result
Market conditions
EM1
Internal strategic
pressure
Action proposed
Do not use data,
rephrase survey
question
The element internal strategic pressure (elm_EM1) does not correlate to any perception of
complexity. The survey question related to this element is built up from two parts: there
290
was pressure from the business department in my company to deliver cheaper and there
was pressure from the business department in my company to deliver faster (five points
scale: strongly disagree to strongly agree). These two separate statements do not show
correlations to any perception of complexity either. The answers showed a normal
distribution and detailed analysis of the answers could not explain the absence of
correlations with perceived complexity, other than that it can be related to the interpretation
of perceived environmental complexity or the interpretation of the survey question. Only
one significant correlation with the other TOE elements was found: the weak negative
correlation to the element dependencies between tasks (rs = -.290, p=.03). This indicates
that an increase in strategic pressure coincides with lower dependencies between tasks,
which are rather strange. Redefinition of this element should therefore be considered and
the obtained element data should not be used in the current analysis.
TOE
E
Sub-ordering
Market
conditions
ID
EM2
Elements defined
Instability project
environment
Correlation result
Action proposed
O, E
Use data
The element instability of the project environment (elm_EM2) shows very weak positive
correlations to both perceived organizational complexity (rs = .227, p=.066) and perceived
environmental complexity (rs = .211, p = .091). The corresponding survey question was
stated as a proposition: the project had to deal with fluctuating environment (such as
exchange rates, raw material pricing, oil prices, etc) which was answered well balanced:
strongly disagreed (8 responses), disagreed (22 responses), neutral (17 responses), agreed
(15 responses), strongly agreed (4 responses), 1 missing value. Several weak positive
correlations are found with the largeness of scope, weather conditions, remoteness of
location and the level of competition. A less stable project environment coincides with
larger project scope, expected problems with weather conditions, a more remote location
and more competition. These are all meaningful, merely related to E-elements and therefore
this element should stay in the environmental category. The obtained data can be used in
the current analysis.
TOE
Sub-ordering
Market conditions
ID
EM
3
Elements defined
Level
of
competition
Correlation result
Action proposed
Use data
The element level of competition (elm_EM3) does not correlate to any perception of project
complexity. It shows weak positive correlations to number of locations, interfaces between
different disciplines, number of stakeholders and the instability of the project environment;
e.g. more competition coincides with more locations, more interfaces, more stakeholders
and a less stable project environment. The answers on the corresponding survey question
(please indicate which answer applies best to the project: the project was to be run in a
highly competitive market) were dominantly neutral (24) or agreeing (34, of which 12
strongly agree), hence indicating sample limitations. The correlations with the other TOE
elements seem meaningful and therefore, the obtained data can be used in the current
analysis, despite the fact that there was no correlation with any perception of complexity.
291
Risk
ER1
Elements defined
Risks
from
environment
Correlation result
Action proposed
Use data, rephrase
survey question
E**
The element environmental risks (elm_ER1) shows a weak positive correlation to perceived
environmental complexity (rs = .367, p=.003). This element only shows one significant
correlation to another element from the TOE framework, which is a weak negative
correlation to the number of different languages in the project team (e.g. more languages in
the project team correspond to lower environmental risks, rs = -.250, p=.043). Looking at
the answers to the corresponding survey question, the respondents dominantly disagreed
with the statement I considered the project being high risk (number, probability and/or
impact) in terms of environmental risks. In total 7 respondents strongly disagreed, 34
respondents disagreed, 15 respondents were neutral, 9 respondents agreed and 1 respondent
strongly agreed (1 missing value). Hence the absence of more correlations could be related
to sample limitations. Also, the lack of significant correlations with other TOE elements
might indicate there is a problem with the interpretation of the word environment. For the
elements technical risk and organizational risk, multiple correlations with other TOE
elements were found and this was also expected for the element environmental risk. In case
people misunderstood environment, a relation can be found between environmental risk
and perceived environmental complexity (which was the case), but not with the other Eelements. The current element potentially measures only a subset of our intended
environmental complexity (namely the part related to protection of the environment).
Still the obtained data can be used in the current analysis.
Subordering
ID
Corr.
Result
TOE
T
T
T
Goals
Goals
Goals
TG1
TG2
TG3
Number of goals
Unaligned goals
Unclear goals
T
O**
O
Scope
TS1
Scope largeness
T
T
Scope
Scope
TS2
TS3
Uncertainties in scope
Quality requirements
O
T**, E
Tasks
TT1
Number of tasks
T
T
T
Tasks
Tasks
Tasks
TT2
TT3
TT4
T
T*
Tasks
TT5
Tasks
TT6
Experience
TE1
T
T
Experience
Risk
TE2
TR1
Variety of tasks
Dependencies between tasks
Uncertainty in methods
Interrelations between
technical processes
Conflicting norms and
standards
Newness of technology
(world-wide)
Lack of experience with
technology
Technical risks
Action proposed
Use data
Use data
Use data
Do not use data, remove
element
Use data,( rephrase question
for future use)
Use data
Do not use data, rephrase
question
Do not use data, rephrase
question
Use data, rephrase question
Use data
Do not use data, rephrase
question
O*
Use data
T, O
Use data
T**, O*
** Correlation is significant at the 0.01 level (2-tailed), * Correlation is significant at the 0.05 level
(2-tailed), Correlation is significant at the 0.10 level (2-tailed)
292
Subordering
ID
Size
OS1
Size
Corr.
Result
TOE
Action proposed
Use data, move to Tcategory
OS2
Project duration
Incompatibility of different
project management methods and
tools
O**,
E*
Size
OS3
Size in CAPEX
O
O
Size
Size
OS4
OS5
O*
Size
OS6
Size
OS7
Number of locations
O
O
Resources
Resources
ORE1
ORE2
O, E*
O**
O
O
Resources
Resources
ORE3
ORE4
O
O
O
O
O
O
Resources
Resources
Resources
Project team
Project team
Project team
ORE5
ORE6
ORE7
OP1
OP2
OP3
Project drive
Resource & Skills scarcity
Lack of experience with parties
involved
Lack of HSSE awareness
Interfaces between different
disciplines
Number of financial resources
Contract types
Number of different nationalities
Number of different languages
Presence of JV partner
O
O**,
T*
O*
E
O
O
O
O
Project team
Trust
Trust
Risk
OP4
OT1
OT2
OR1
O**
Use data
Use data
Use data, rephrase question
Use data, rephrase question
Use data
Use data
Do not use data, rephrase
question
Use data, rephrase question
Use data, rephrase question
Use data
Stakeholders
ES1
Stakeholders
ES2
Stakeholders
ES3
E
E
E
E
E
E
E
Stakeholders
Stakeholders
Stakeholders
Location
Location
Location
Location
Market
conditions
Market
conditions
Market
conditions
Risk
ES4
ES5
ES6
EL1
EL2
EL3
EL4
Political influence
Lack of company internal support
Required local content
Interference with existing site
Weather conditions
Remoteness of location
Lack of experience in the country
O**
T*,
O**
T*
(neg)
O
O
Number of stakeholders
Variety of stakeholders'
perspectives
Dependencies on other
stakeholders
EM1
Use data
Use data
Use data
Use data
Use data
Use data
Use data
Do not use data, rephrase
question
EM2
O, E
Use data
EM3
ER1
Level of competition
Risks from environment
E**
Use data
Use data, rephrase question
E
E
E
E
Use data
Use data, move to Tcategory
Do not use data, remove
from framework
Use data
Do not use data, remove
from framework
Use data, move to Tcategory
Use schedule drive data,
rephrase question
Use data
Use data, rephrase question
Use data
** Correlation is significant at the 0.01 level (2-tailed), * Correlation is significant at the 0.05 level
(2-tailed), Correlation is significant at the 0.10 level (2-tailed)
293
294
295
296
297
298
299
300
301
302
303
304
20%
40%
60%
80%
Appendices
20%
40%
60%
80%
305
306
Summary
Project failure in terms of cost overrun and time delays is still common practice, also for
large engineering projects. Literature suggests that one of the reasons for such project
failure would be the increasing complexity of projects or an underestimation of the project
complexity. Literature also suggests the particular importance of the early project phases
(the front-end phases) for improving project performance. A third observation from
literature is a trend towards context specific project management, which calls for applying a
contingency approach to project management.
The objective of this study was threefold. The first objective was to investigate what project
complexity actually comprises and how it influences project performance. The second
objective was to investigate how front-end activities could be adapted to the projects
complexity and how this influences project performance. The third objective was to
investigate the relations between these variables (project complexity, front-end activities
and project performance), amongst others by using a contingency approach. The research
was focused on technologically complex engineering projects in the process industry,
undertaken in dynamic environments with multiple stakeholders, with a budget between
approximately 1 to 500 million Euro. The research was performed within the NAP network,
which brings together companies from the entire value chain in the Dutch process industry,
including engineering agencies and the academic community. The NAP network consists of
about 100 member organizations. For the different stages of the research, different
selections of companies were included. The interest of the NAP network in (improving) the
front-end phase of projects was evident from their previous publications, which made them
well-suited for participation in our research.
The basic underlying conceptual model of this research consisted of three building blocks:
project complexity and front-end development activities as the independent variables and
project performance as the dependent variables. The fact that the starting point of this PhD
research was a model might suggest that this research was at the deductive side of the
deductive/inductive spectrum, but the model was a high level one and these main variables
first needed further operationalization. This operationalization was considered further
exploration of the field, which is at the inductive side of the spectrum. The research started
with an exploratory character and progressed towards more evaluative phases. The total
study comprised exploratory case studies (Phase I Chapters 3 and 4); a quantitative
survey (Phase II Chapters 5, 6 and 7); explanatory case studies (Phase III Chapter 8);
and an evaluative survey (Phase IV Chapter 9). By combining qualitative and quantitative
work, our study is an example of applying mixed methods.
The main research question to be answered was: How could the front-end phase be adapted
to the projects complexity in order to improve project performance? To answer this
question, first of all the available literature was explored to find the real starting points for
the research (Chapter 2).
In Phase I of the research, case studies explored what aspects contribute to project
complexity in view of project professionals and what front-end activities are particularly
relevant to better deal with project complexity (Chapter 3). The exploratory case studies
were performed in one company, an active member of the NAP network, with a very
structured project management approach. By choosing different projects from one company
307
-all projects were performed using the same project management standards- variations in
the standard front-end activities applied in a project were limited. A multiple-cases
embedded design was used, in which each case represented a completed project. The
embedded design referred to the different dimensions to be analyzed within one case:
project complexity, the activities in the front-end development phase and the project
performance. The multiplicity referred to the inclusion of a number of projects (6) opposed
to inclusion of a single project. Per case, semi-structured interviews were held with three
persons involved in the project. Next to the project manager, also a team member and a line
representative who was involved in the project (development) were asked to participate.
From the exploratory case studies (Chapter 3), it was concluded that in view of the
interviewees, organizational complexity prevailed over external complexity and technical
complexity. Working with a JV partner considerably contributed to organizational
complexity. The aspects of technical, organizational and external complexity were very
differently scored per project by the vast majority of the interviewees, hence indicating the
importance and usefulness of using a project complexity measure consisting of multiple
categories. Project complexity was shown to be a subjective concept and highly dynamic.
Both findings have consequences: discussion amongst the relevant stakeholders is required
when assessing project complexity and evolution of the complexity of a project should be
regularly reviewed. From the exploratory case studies it was concluded that often project
complexity was not recognized in the front-end phase and hence not treated (well). A lack
of thorough front-end development was shown to increase the complexity of the project, in
view of the interviewees. Analyzing the interview findings showed the relevance of several
front-end activities related to project team building, goals/scope setting, risk management,
governance, contract strategy and contractor interaction. To overcome interface
complexities, team integration was shown to be crucial.
Using the results of the exploratory case studies and literature, a framework was developed
to characterize project complexity (Chapter 4). Comparing literature findings and case
study findings, numerous and various elements were found that would contribute to project
complexity. Based on the literature, potential causes for project complexity were clustered
in three dimensions: technical complexity (content/scope related), organizational
complexity (project team, trust, resource related) and external complexity (organizational
complexity from external factors: stakeholders, market conditions etc.). The term external
complexity was replacing the initially used term environmental because environmental
seemed (mistakenly) associated with its ecological meaning. Because of the important link
between risk and complexity, amongst the elements in the TOE framework there were three
elements specifically dedicated to risk; one in each of the three categories (technical risk,
organizational risk, external risk).
In Phase II of the research a quantitative survey study was performed in the NAP
network(Chapter 5) to further evaluate the developed complexity framework (Chapter 6)
and the relations between project complexity, front-end activities and project performance
were investigated (Chapter 7).
The survey contained questions about the (perceived) complexity of the project in the three
different dimensions (technical, organizational, external), front-end activities and project
performance (delivering scope with sufficient quality, within agreed time and budget) and
front-end activities. Front-end activities were operationalized in two parts: first by relevant
front-end activities concluded from the Chapter 3 case studies and second by the twelve
value improving practices. In total 67 responses were received from more than 25
308
Summary
companies in the NAP network, which resulted in a lot of valuable information to analyze,
also given the high number of survey questions. Our respondents predominantly had a
background in engineering or science. The projects in the sample varied largely in budget
and planned duration. Except two projects, they were all design / engineering / construction
projects of companies in the Dutch process industry. The success rate of these projects
(delivered with sufficient quality, within 10% of cost and schedule estimates), was 37%.
From Chapter 6 it was concluded that indeed project complexity negatively influenced
project performance, distinguishing the technical, organizational and external dimension of
project complexity. The strongest correlations between project complexity elements and
project performance were found in the areas of goals / scope, uncertainty in methods,
incompatibility of PM methods / tools, resources and skills scarcity, interfaces between
different disciplines and a lack of company internal support. Several significant relations
were found between the complexity elements and respondents perceptions of technical,
organizational and external complexity. The perceptions of the respondents were often
implications or consequences of project complexity, and not the causes we were looking
for. The respondents largely agreed with the intentions for use of the TOE complexity
framework: to support project management, to create awareness amongst the involved
stakeholders and to be used repeatedly throughout the project, starting in front-end. Finally,
Chapter 6 delivered evidence that project complexity indeed is a construct that contains
several and various components, which seem worth to distinguish.
Chapter 7 investigated the relations between project complexity, front-end activities and
project performance and how the different respondents roles influenced their opinions on
project complexity and front-end activities. It was concluded, that using multi-level analysis
techniques, insight was obtained in those relations. The high level 2x2 matrix set up
showed that applying front-end activities was beneficial to project performance. To resolve
which activities particularly were beneficial, detailed analysis was performed which
showed the importance of:
- Goal alignment between business and project team
- Applying operations implementation planning
- Applying external benchmarking
- Adequate contract type in co-operation with (sub)contractors
These activities were shown to be important regardless of complexity type. Some other
front-end activities also showed a relation with (dimensions of) project complexity, next to
a relation with project performance:
- Active goal monitoring (technical complexity)
- Goal setting and alignment (technical and organizational complexity)
- Timely involvement of parties in the project (technical and organizational
complexity)
- Applying teambuilding (organizational and external complexity)
By applying contingency theory, one moderated relationship was found: risk management
was influencing project performance, moderated by technical and external complexity. The
significant relations between project complexity, front-end activities and project
performance were summarized in Figure 7.3.
Chapter 7 also investigated whether and how the role of the respondent (in team role and
company role) influenced their perspectives. Some important different opinions between
project managers, team members and business representatives were found in the field of
goal setting and alignment, team cohesion and selection of the project manager. Between
309
contractors and owners, the most important difference found was in the value improving
practice operations implementation planning. This VIP was perceived to be more
beneficial and more sufficiently applied in view of the project owners, which seems
inherently related to their different roles.
After the exploration of several relations between project complexity, front-end activities
and project performance in Phase II, Phase III of the research investigated in what way
certain front-end activities contributed to project performance, by means of an in-depth case
study (Chapter 8). Four cases were selected from the survey sample of the second phase. To
explore the different perspectives of owners and contractors, an additional owner project
was added as a fifth case (also from a NAP company). Again it was chosen to follow a
multiple cases embedded design. Based on the quantitative outcomes of the second phase,
this case study investigated more deeply in what way specific front-end activities
contributed to the project performance. Phase III had an explanatory character and was
qualitatively oriented: 11 interviews were held with project managers and team members,
across the 5 projects.
From Chapter 8, it was concluded that how one applies (and with whom) certain value
improving practices (team design, goals setting / alignment and monitoring, risk
management, external benchmarking and operations implementation planning) is relevant.
Here the role of integrated teams was shown to be a crucial one: integration in terms of
involving all relevant parties in the team (owner and contractor, but also different
departments within a company) and also integration in terms of resource continuity
throughout the different project phases (researchers as well as operations people). Spending
joint effort in the application of value improving practices was shown to be beneficial for
the project. Integrated teams had short communication lines, which enabled efficient
decision making and prevented major late scope changes.
Finally, Phase IV of the research presented a validation survey in which it was investigated
to what extent the different aspects of complexity indeed contribute to project complexity
and how the newly developed framework to grasp project complexity (phase I en II) could
help in improving project performance in future projects (Chapter 9). The questions in this
survey were not project specific but sector specific to better enable generalization of the
results outside the specific companies involved. The survey was sent to two owner
companies and two contractor companies, all of which were participating in the NAP
network. In total 64 completed responses were received. The research in this concluding
phase was partly quantitative and partly qualitative. Quantitative, as to what extent each of
the elements of the complexity framework indeed would contribute to project complexity
and qualitative in how the framework could help in improving project performance.
Based on the survey results in Chapter 9, the final version of the TOE framework was
prepared (see Figure 9.8; 17 elements contributing to technical complexity, 17 elements
contributing to organizational complexity and 13 elements contributing to external
complexity). Significantly different perceptions were found between contractor respondents
and project owner respondents on the importance of the complexity elements unclarity of
project goals and variety of stakeholders perspectives. Since these elements were amongst
the elements that would most contribute to project complexity in view of all respondents,
this would need further attention. Note that elements, experienced as most contributing to
project complexity (goals / scope related, lack of resource availability and a lack of
company internal support) were also most influential to good project performance (Chapter
6), which stresses the need to treat these. Overall looking at how the respondents would
310
Summary
deal with project complexity, it seemed that the value improving practices goal setting &
alignment, stakeholder management, risk management and project team building would be
most widely applied. The owner respondents would, more often than the contractor
respondents, apply stakeholder management. This was supporting the Chapter 7 results,
which already showed that owners applied more stakeholder management than the
(sub)contractors. The contractor respondents would, more often than the owner
respondents, apply project team building to treat aspects of project complexity. This again
links to the importance of integrated teams, as concluded from Chapter 8.
All findings together provided the answer to the overall research question: How could the
front-end phase be adapted to the projects complexity in order to improve project
performance? In the front-end phase, the newly developed TOE framework to grasp project
complexity could serve as a complexity checklist. By means of the TOE framework,
those areas are identified in which complexities are expected to arise in a particular project.
Based on these identified complexity area(s), measures can be taken by spending additional
effort in certain value improving practices. From our empirical data, we conclude some
particularly important front-end activities. Team integration (between different parties
involved and across different project phases) in the process of applying these front-end
activities is considered crucial to enable optimum information exchange.
Our findings throughout confirmed the broadening trend of project management beyond the
old control perspective. Amongst the front-end activities significantly contributing to
project performance, dominantly process oriented activities were found, aiming at for
example alignment amongst different stakeholders, increasing shared understanding and
team integration. Also in the application of the TOE framework, we foresee a broad
approach: rather than aiming to fully predict and control the complexities that will arise, the
aim is to prepare the project team for what complexities might arise.
How could the results of this study then be applied? A framework to grasp project
complexity, as developed and validated in this study, could be used in early project phases
to identify the areas in which complexity is expected to arise. Practitioners were positive on
the foreseen usefulness and potential of the TOE framework. Based on the complexity
footprint, distinguishing technical complexity, organizational complexity and external
complexity (or even at element level), measures could be taken like spending more effort in
certain value improving practices, to better manage project complexity and hence improve
project performance. We strongly promote an adaptive approach in this: adapting the effort
in front-end activities to the specifically expected complexities.
By applying mixed-methods in our study, a rich set of results has been gathered.
Nevertheless there were limitations: thorough investigation of the high number of variables
would ask for data from more projects than currently available. Another important
limitation was that we mainly focused on a set of value improving practices, under the
assumption that a sound project management process was in place in the projects under
study: subsequent research might have a broader character. Also future research is
recommended in particularly the following areas: investigating the dynamics of project
complexity, gathering more data from other industry sectors, focusing on project execution
and further operationalizing the establishment of integrated teams (with a link to trust and
contracting).
311
312
Samenvatting
Het managen van projectcomplexiteit: een studie naar het aanpassen van de vroege
projectfase om projectprestaties van grote engineering projecten te verbeteren.
Nog steeds worden technische projecten te laat en/of met grote kostenoverschrijdingen
opgeleverd: projectprestaties stellen vaak teleur. Literatuur laat zien dat de toenemende
complexiteit van projecten en onderschatting van deze projectcomplexiteit hiervoor een
belangrijke oorzaak is. Ook laat literatuur het belang zien van de vroege projectfase (de
zogeheten front-end fase) voor het verbeteren van projectprestaties. Een derde observatie
uit de literatuur is de trend van context-specifiek projectmanagement, waarin wordt gepleit
voor een contingentiebenadering in projectmanagement: niet alle projecten vragen om
eenzelfde aanpak. Deze drie observaties hebben geleid tot dit onderzoek.
Het doel van deze studie is drieledig. De eerste doelstelling is om te onderzoeken wat nu
precies verstaan moet worden onder projectcomplexiteit en hoe projectcomplexiteit de
projectprestaties benvloedt. De tweede doelstelling is om te onderzoeken hoe de front-end
activiteiten kunnen worden aangepast aan de projectcomplexiteit en hoe dit de
projectprestaties benvloedt. De derde doelstelling is om de relaties tussen
projectcomplexiteit, front-end activiteiten en projectprestaties verder te onderzoeken, onder
andere met behulp van een contingentiebenadering. Het onderzoek is gericht op
technologisch complexe engineering projecten in de procesindustrie, uitgevoerd in
dynamische omgevingen met meerdere stakeholders, met een budget tussen circa 1 miljoen
en 500 miljoen euro. Het onderzoek is uitgevoerd binnen het NAP-netwerk, waarin
bedrijven uit de gehele waardeketen in de Nederlandse procesindustrie (waaronder ook
ingenieursbureaus en universiteiten) zijn verenigd. Bij het NAP-netwerk zijn ongeveer 100
bedrijven aangesloten. Voor de verschillende fasen van het onderzoek zijn verschillende
selecties van de bedrijven gebruikt. De interesse van het NAP-netwerk in het verbeteren
van de front-end fase van de projecten blijkt uit eerdere NAP-publicaties op dit gebied en
dit maakt het NAP-netwerk zeer geschikt voor deelname aan dit onderzoek.
Het onderliggende conceptuele model van dit onderzoek bestaat uit drie bouwstenen:
projectcomplexiteit en front-end activiteiten als de onafhankelijke variabelen en
projectprestatie als de afhankelijke variabele. Het onderzoek begint explorerend en
verandert in de loop van het onderzoek van karakter richting evaluerend. Meer specifiek
omvat de totale studie verkennende casestudies (fase I - hoofdstukken 3 en 4), een
kwantitatieve enqute (fase II - hoofdstukken 5, 6 en 7); verklarende casestudies (fase III hoofdstuk 8) en een toetsende enqute (fase IV - hoofdstuk 9). Het onderzoek illustreert het
succesvol gecombineerd toepassen van kwalitatieve en kwantitatieve onderzoeksmethoden.
De hoofdvraag van het onderzoek is: Hoe kan de front-end fase van een project worden
aangepast aan de projectcomplexiteit om te komen tot betere projectprestaties?
In fase I van het onderzoek is door middel van casestudies onderzocht welke aspecten
bijdragen aan projectcomplexiteit volgens project professionals en welke front-end
activiteiten relevant zijn om beter om te gaan met projectcomplexiteit (hoofdstuk 3). De
verkennende casestudies zijn uitgevoerd binnen n bedrijf, een actief lid van het NAPnetwerk met een zeer gestructureerde projectmanagementaanpak. Door te kiezen voor
verschillende projecten binnen n bedrijf bleef variatie in uitgevoerde standaard front-end
313
Samenvatting
315
Samenvatting
bijdragen aan projectcomplexiteit en kwalitatief voor wat betreft hoe het raamwerk zou
kunnen bijdragen aan het verbeteren van de projectprestaties.
Op basis van de resultaten in hoofdstuk 9 is de definitieve versie van het TOE
complexiteitsraamwerk opgesteld (zie Figuur 9.8 met 17 elementen die bijdragen aan
technische complexiteit, 17 elementen die bijdragen aan organisatorische complexiteit en
13 elementen die bijdragen aan externe complexiteit). Significante verschillen van mening
zijn gevonden tussen de respondenten van de aannemersbedrijven en eigenaarsbedrijven,
vooral wat betreft de mate waarin onduidelijkheid van projectdoelstellingen en
verscheidenheid in stakeholders meningen bijdragen aan de totale projectcomplexiteit.
Omdat volgens alle respondenten juist dze elementen behoren tot de meest bepalende voor
projectcomplexiteit, behoeft dit extra aandacht in de praktijk. De elementen die volgens de
respondenten het meest bijdroegen aan projectcomplexiteit (doelstelling en scope
gerelateerd, gebrek aan beschikbaarheid van resources, gebrek aan interne ondersteuning)
bleken in hoofdstuk 6 al een sterke invloed op projectprestaties te hebben, wat de noodzaak
benadrukt om hier in het project meer aandacht aan te schenken. Om beter om te gaan met
projectcomplexiteit zouden de respondenten de volgende VIPs extra gaan toepassen: het
definiren en afstemmen van projectdoelstellingen, stakeholder management,
risicomanagement en teambuilding. Respondenten van de eigenaarsbedrijven zouden vaker
dan respondenten van de aannemersbedrijven stakeholdermanagement toepassen. Deze
bevinding ondersteunt de bevindingen in hoofdstuk 7, waar al bleek dat projecteigenaren
meer stakeholdermanagement toepasten dan (onder)aannemers. De respondenten van de
aannemersbedrijven zouden vaker teambuilding toepassen om beter om te gaan met
projectcomplexiteit. Hier is een parallel te leggen naar de resultaten van hoofdstuk 8,
waarin het belang van gentegreerde teams al werd benadrukt.
De resultaten van de fasen I, II, III en IV samen leveren het antwoord op de
hoofdonderzoeksvraag: Hoe kan de front-end fase van een project worden aangepast aan
de projectcomplexiteit om te komen tot betere projectprestaties? In de front-end fase van
een project zou het nieuw ontwikkelde TOE complexiteitsraamwerk kunnen dienen als een
complexiteitschecklist. Op deze wijze worden de gebieden waar complexiteit te
verwachten is in een specifiek project zichtbaar gemaakt in een complexiteitsvoetafdruk.
Op basis van die gedentificeerde projectcomplexiteit kunnen maatregelen worden
genomen, zoals extra aandacht schenken aan het uitvoeren van bepaalde VIPs. Uit onze
empirische data hebben we geconcludeerd dat bepaalde front-end activiteiten bijzonder
belangrijk zijn voor het verbeteren van projectprestaties. Bij het toepassen van front-end
activiteiten bleken gentegreerde teams een cruciale rol te spelen, bijvoorbeeld voor het
bewerkstelligen van optimale informatie-uitwisseling.
De bevindingen van ons onderzoek bevestigen de trend van het breder worden van
projectmanagement, breder dan het oude control perspectief. Onder de front-end
activiteiten die significant bijdroegen aan projectprestaties waren vooral procesgerichte
activiteiten, bijvoorbeeld gericht op betere afstemming tussen verschillende
belanghebbenden, het vergroten van onderling begrip en het bewerkstelligen van
gentegreerde teams. Ook voor het TOE complexiteitsraamwerk voorzien we een brede en
procesgerichte toepassing, niet zozeer gericht op het volledig voorspelbaar maken of
reduceren van projectcomplexiteit, maar meer op het voorbereiden van het projectteam om
beter om te gaan met projectcomplexiteit.
317
Hoe kunnen de resultaten van deze studie worden toegepast? Het TOE raamwerk om
projectcomplexiteit in kaart te brengen, ontwikkeld en gevalideerd in dit onderzoek, kan
aan het begin van het project worden gebruikt om (mogelijke) projectcomplexiteit uit
verschillende hoeken te identificeren. Op basis van de complexiteitsvoetafdruk waarin
technische complexiteit (17 elementen), organisatorische complexiteit (17 elementen) en
externe complexiteit (13 elementen) worden onderscheiden, kunnen maatregelen worden
genomen zoals het meer aandacht schenken aan toepassing van bepaalde VIPs in de frontend fase, om beter met de gedentificeerde elementen van projectcomplexiteit om te gaan
en zodoende de projectprestaties te verbeteren. Wij zijn voorstander van een adaptieve
aanpak, waarbij de vroege projectfase wordt aangepast op basis van de te verwachten
projectcomplexiteit.
Het toepassen van verschillende methodes, kwalitatief en kwantitatief, heeft een rijke set
aan resultaten opgeleverd. Toch zijn er ook beperkingen in deze studie, bijvoorbeeld in het
grote aantal variabelen dat is onderzocht: meer projectdata zou kunnen bijdragen aan
sterkere onderbouwing van de conclusies. Een andere beperking is dat we ons vooral
hebben gericht op een beperkt aantal VIPs, in de veronderstelling dat er een goed
onderliggend projectmanagementproces aanwezig was in de onderzochte projecten:
toekomstig onderzoek zou een breder karakter kunnen hebben. Toekomstig onderzoek is
verder aan te bevelen voor de volgende gebieden: onderzoek naar de dynamiek van
projectcomplexiteit, het verzamelen van gegevens over projectcomplexiteit en
projectprestaties in andere industrile sectoren, uitbreiding van de focus van de front-end
fase naar de projectuitvoeringsfase en verdere operationalisering van het gebruik van
gentegreerde teams.
318
Curriculum Vitae
Marian Bosch-Rekveldt was born on March 22nd, 1976, in Kampen, The
Netherlands. After she graduated at the Almere College in Kampen in
1994, she studied Mechanical Engineering at the University of Twente,
The Netherlands. She received her masters degree in Mechanical
Engineering (with honours) in November 1999 in the Section Biomedical
Mechanics, with her thesis on Finite Element Modeling of
Aponeurotomy. For her Masters thesis she received the KIVI-Oost/UTaward in 2000.
She was working at TNO-Automotive from April 2000 till October 2006. She started as
simulation engineer in the field of biomechanics, but soon she developed into a project
leader of various internal and external research projects, including EC projects. The
combination of social relevance (improving crash safety), innovative technical content (new
simulation techniques) and the involvement of multiple parties (needed to make steps
forward in improving crash safety in Europe: but how to align them?) perfectly suited her.
Actually, this is where her interest in professionalizing project management was born.
When TNO moved from Delft to Helmond in 2006, she made a career switch, back to
(another) technical university and she found a new challenge at the new Delft Centre for
Project Management in November 2006. Since then, she has been employed at Delft
University of Technology (Faculty of Technology, Policy and Management) where she is
involved in teaching and research in the field of Project Management. Her research interests
include, but are not limited to, project complexity, front-end development, value improving
practices and people factors, similar to her dissertation themes. Linking research outcomes
to practice is one of her main drivers. She coordinates the minor in Project Management
and is teacher in several project management courses (BSc and MSc). In addition, she
developed and regularly conducts in-company training in project management.
She can be contacted via m.g.c.bosch-rekveldt@tudelft.nl.
319
320