Final Dissertation Bosch-Rekveldt

Managing project complexity
A study into adapting early project phases to improve project

performance in large engineering projects
Marian Bosch-Rekveldt
Managing project complexity
A study into adapting early project phases to improve project

performance in large engineering projects
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
Dit proefschrift is goedgekeurd door de promotoren:
Prof. dr. ir. A. Verbraeck
Prof. dr. H.L.M. Bakker
Copromotor: Dr. ir. H.G. Mooi
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
©2011 M.G.C. Bosch-Rekveldt, The Hague, the Netherlands.
Cover design by Marian Bosch-Rekveldt, using tagxedo.com for the word cloud.
Printed by Ipskamp Drukkers BV.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval
system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying,
recording, or otherwise, without the prior consent of the author.
ISBN 978-94-91005-00-8
Delft Centre for Project Management

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 enquêterespondenten (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 betrokken-
heid 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 collega’s 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 TBM-
kelderkoor 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 Nathan…enorm bedankt! Lieve Lieke, Lieve Nathan: ja, ik heb nu weer meer tijd voor
poppen, DUPLO® en auto’s: mama’s 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 WHY DO CAPITAL PROJECTS STILL FAIL, WHAT CAN WE DO ABOUT IT? ....................... 2
1.2 RESEARCH OBJECTIVE, RESEARCH QUESTIONS AND SCOPE ......................................... 3
1.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 WHAT IS A PROJECT? ................................................................................................ 13
2.2 THE DEVELOPMENT OF PROJECT MANAGEMENT ....................................................... 14
2.3 TRENDS IN PROJECT MANAGEMENT RESEARCH ......................................................... 18
2.4 HOW TO ASSESS PROJECT PERFORMANCE? ................................................................ 20
2.4.1 Project success dimensions .......................................................................... 21
2.4.2 Operationalization of project success .......................................................... 21
2.4.3 Critical success factors ................................................................................ 23
2.5 A CLOSER LOOK INTO PROJECT FRONT-END DEVELOPMENT ...................................... 24
2.6 CONTINGENCY THEORY ............................................................................................ 28
2.6.1 History ......................................................................................................... 28
2.6.2 Structural contingency research paradigm .................................................. 29
2.6.3 Developments and criticisms to structural contingency theory ................... 30
2.6.4 Towards a contingency approach to project management .......................... 30
2.7 PROJECT COMPLEXITY .............................................................................................. 34
2.7.1 Defining project complexity ......................................................................... 34
2.7.2 Concepts of project complexity .................................................................... 35
2.7.3 Uncertainty, project risk and project complexity ......................................... 37
2.7.4 Classification of projects based on their complexity ................................... 39
2.8 PROJECT RELATED STAKEHOLDERS – EXTERNAL & INTERNAL ................................. 41
2.9 STUDIES ON ADAPTING PROJECT MANAGEMENT TO PROJECT CHARACTERISTICS ...... 42
2.10 SUMMARIZING THE STARTING POINTS FOR THE RESEARCH ....................................... 45
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.4 CASE 3: DESIGN AND CONSTRUCT OF CHEMICAL PLANT (MARGINAL PROJECT
PERFORMANCE) .................................................................................................................... 58
3.5 CASE 4: MODIFICATION OF CURRENT FACILITY (POOR PROJECT PERFORMANCE) ...... 62
3.6 CASE 5: DEVELOPMENT OF NEW OFFSHORE ENERGY FACILITY (GOOD PROJECT
PERFORMANCE) .................................................................................................................... 65
3.7 CASE 6: CONSTRUCTION OF NEW FACILITY (MARGINAL PROJECT PERFORMANCE).... 69
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 RESEARCH APPROACH .............................................................................................. 80
4.2 PROJECT COMPLEXITY ELEMENTS FROM LITERATURE............................................... 80
4.2.1 Gathering elements from literature.............................................................. 80
4.2.2 Elaborating on the proposed structure for the framework........................... 81
4.3 PROJECT COMPLEXITY ELEMENTS FROM CASE STUDIES ............................................ 84
4.4 THE TOE FRAMEWORK FOR PROJECT COMPLEXITY IN LARGE ENGINEERING PROJECTS
…………………………………………………………………………………….. 87
4.5 DISCUSSING THE FRAMEWORK ................................................................................. 91
4.6 USE AND FURTHER DEVELOPMENT OF THE TOE FRAMEWORK .................................. 92
4.7 CONCLUSION & RECOMMENDATIONS ....................................................................... 93
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 project’s 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
CHAPTER 6 ..................................................................................................................... 109

EVALUATING PROJECT COMPLEXITY ................................................................ 109
6.1 ANALYSIS OF SURVEY DATA ................................................................................... 110
6.2 CORRELATIONS BETWEEN PROJECT COMPLEXITY AND PROJECT PERFORMANCE ..... 110
6.3 CORRELATIONS BETWEEN ELEMENT SCORES AND PERCEIVED COMPLEXITY ........... 112
6.3.1 Correlation of T-elements and perceived complexity ................................ 117
6.3.2 Correlation of O-elements and perceived complexity ................................ 119
6.3.3 Correlation of E-elements and perceived complexity ................................ 122
6.3.4 Summary of element evaluation & proposal for adaptations to the TOE
framework .................................................................................................................. 124
6.4 COMPLETENESS OF THE TOE FRAMEWORK ............................................................ 127
6.4.1 Most complex element(s) in the project ..................................................... 127
6.4.1 What is lacking in the TOE framework? .................................................... 130
6.5 APPLYING A TOE-LIKE FRAMEWORK ..................................................................... 131
iv
6.6 AGGREGATED SCORES FOR T, O AND E COMPLEXITY ............................................. 133
6.7 DISCUSSION ............................................................................................................ 135
CHAPTER 7 ..................................................................................................................... 137

EVALUATING FRONT-END ACTIVITIES ............................................................... 137
7.1 HIGH LEVEL RELATIONS BETWEEN COMPLEXITY, FRONT-END ACTIVITIES AND
PROJECT PERFORMANCE ..................................................................................................... 138
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 Respondent’s role in the project ................................................................ 161
7.6.2 Role of the respondent’s 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
CHAPTER 8 ..................................................................................................................... 171

HOW DO VALUE IMPROVING PRACTICES CONTRIBUTE TO PROJECT
PERFORMANCE? .......................................................................................................... 171
8.1 METHODS ............................................................................................................... 172
8.1.1 Case study design....................................................................................... 172
8.1.2 Case selection ............................................................................................ 172
8.1.3 Case protocol, validity and analysis set up ................................................ 174
8.2 THE 5 CASES AT FIRST GLANCE ............................................................................... 175
8.2.1 Case A: A construction project by an owner organization (good project
performance) ............................................................................................................. 175
8.2.2 Case B: A turnaround project by a contractor (good project
performance)………………………………………………………………………………… 176
8.2.3 Case C: A public civil engineering and construction project by a contractor
(very poor project performance)................................................................................ 177
8.2.4 Case D: A plant modification project by a contractor (poor project
performance) ............................................................................................................. 179
8.2.5 Case E: A Greenfield design and construction project by an owner (good
project performance) ................................................................................................. 180
v
8.3 CROSS CASE ANALYSIS ........................................................................................... 181
8.3.1 Findings on team design ............................................................................ 182
8.3.2 Findings on goal setting............................................................................. 183
8.3.3 Findings on monitoring project goals ........................................................ 183
8.3.4 Findings on risk management .................................................................... 184
8.3.5 Findings on external benchmarking .......................................................... 185
8.3.6 Findings on operations implementation planning ..................................... 185
8.3.7 Comparing the 5 cases ............................................................................... 186
8.4 TEAM INTEGRATION PAYS OFF ................................................................................ 186
8.5 CONCLUSION AND RECOMMENDATIONS ................................................................. 187
CHAPTER 9 ..................................................................................................................... 189

VALIDATING THE TOE FRAMEWORK FOR POTENTIAL USE........................ 189
9.1 FINAL TOE FRAMEWORK ....................................................................................... 190
9.2 SURVEY DESIGN...................................................................................................... 190
9.3 DATA TREATMENT .................................................................................................. 192
9.3.1 Data collection ........................................................................................... 192
9.3.2 Data analysis ............................................................................................. 194
9.4 SURVEY RESULTS ................................................................................................... 194
9.4.1 Respondents work experience .................................................................... 194
9.4.2 Evaluation of the TOE framework ............................................................. 195
9.4.3 How to deal with complexity? .................................................................... 200
9.4.4 Application of the TOE framework ............................................................ 205
9.4.5 Added value of the TOE complexity framework ......................................... 208
9.4.6 Further development of the TOE complexity framework ........................... 210
9.5 DISCUSSION AND CONCLUSIONS ............................................................................. 211
9.5.1 The TOE complexity framework ................................................................ 212
9.5.2 Treating project complexity ....................................................................... 213
9.5.3 An owner’s perspective versus a contractor’s perspective? ...................... 214
9.5.4 Foreseen use of the framework .................................................................. 214
9.5.5 Further development of the TOE framework ............................................. 215
CHAPTER 10 ................................................................................................................... 217

DISCUSSION, CONCLUSIONS AND RECOMMENDATIONS............................... 217
10.1 DISCUSSION ............................................................................................................ 217
10.1.1 Validity of the current research ................................................................. 217
10.1.2 Scientific contribution ................................................................................ 219
10.1.3 Limitations of the research ........................................................................ 220
10.2 CONCLUSIONS ........................................................................................................ 221
10.2.1 Answers to the research questions ............................................................. 221
10.2.2 Overall conclusions ................................................................................... 224
10.3 RECOMMENDATIONS .............................................................................................. 226
10.3.1 Recommendations for use of the results in project practice ...................... 226
10.3.2 Research recommendations ....................................................................... 227
REFERENCES ................................................................................................................ 229
vi
APPENDICES .................................................................................................................. 243
APPENDIX A: LIST OF INTERVIEW QUESTIONS EXPLORATIVE CASE STUDIES (CHAPTER 3)
………………………………………………………………………………………….. .. 244
APPENDIX B: INTERNET SURVEY PHASE II (CHAPTER 5) ............................................... 247
APPENDIX C: TRANSLATION TABLE: TOE ELEMENTS & SURVEY QUESTIONS (CHAPTER 5)
………….. ......................................................................................................................... 256
APPENDIX D: CORRELATION RESULTS TOE ELEMENTS & DETAILED ANALYSIS (CHAPTER
6) …………. ...................................................................................................................... 259
D.1: Correlation of T-elements and perceived complexity ........................................ 268
D.2: Correlation of O-elements and perceived complexity........................................ 274
D.3: Correlation of E-elements and perceived complexity ........................................ 285
D.4: Summary of element evaluations ....................................................................... 292
APPENDIX E: REQUIRED ELEMENT TRANSFORMATIONS (CHAPTER 6) ............................. 294
APPENDIX F: INTERVIEW QUESTIONS PHASE III (CHAPTER 8) ....................................... 296
APPENDIX G: INTERNET SURVEY PHASE IV (CHAPTER 9) ............................................. 299
APPENDIX H: ELEMENTS MOST/LEAST CONTRIBUTING TO PROJECT COMPLEXITY PHASE
IV (CHAPTER 9).................................................................................................................. 304
SUMMARY ...................................................................................................................... 307
SAMENVATTING .......................................................................................................... 313
CURRICULUM VITAE ................................................................................................. 319
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.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
x
List of abbreviations
ACAT Acquisition Categorisation Framework

ADM Asset Development Manager
APM Association of Project Management
ANOVA Analysis of Variance
BDP Basic Design Package
CAPEX Capital Expenditure
CIFTER Crawford-Ishikura Factor Table for Evaluating Roles
CII Construction Industry Institute
CO Change Order
CoPS Complex Products and Systems
CPM Critical Path Method
CRC Cooperative Research Centre
CRI Construction Research Innovation
DCP Delft Centre for Project Management
DMO Defence Materiel Organisation
ENAA Engineering Advancement Association of Japan
EPC Engineering Procurement Construction
EPCC Engineering Procurement Construction Commissioning
EPCM Engineering Procurement Construction Management
FED Front-End Development
FEL Front-End Loading
FID Final Investment Decision
FPO Future Plant Owner
GAPPS Global Alliance for Project Performance Standards
HS(S)E Health, Safety, Security, Environment
JV Joint Venture
IBC Industry Benchmarking Consortium
ICB IPMA Competency Baseline
IPA Independent Project Analysis
IPMA International Project Management Association
NAP Nederlands Apparatenbouw en Procesindustrie
NCTP Novelty, Complexity, Technology, Pace
OIP Operations Implementation Planning
PERT Program Evaluation Review Technique
PM Project Manager / Project Management
PMI Project Management Institute
UCP Uncertainty, Complexity, Pace
USAF US Air Force
SHE Safety, Health, Environment
TOE Technical, Organizational, External
VIP Value Improving Practice
WP Work Package
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 don’t 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 so-
called 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
Managing Project Complexity
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 today’s projects?
Nowadays, projects are performed in highly dynamic environments, involving multiple
stakeholders with different perspectives and encountering technological challenges. Hence
2
Chapter 1: Introduction
projects are characterized by uncertainties, whereas “the traditional, formal approach to

project management is based on a predictable, fixed, relatively simple, and certain model”
(Shenhar & Dvir, 2007b), p. 9. Similarly, most mainstream textbooks still “promote this
normative view of the field” (Hodgson & Cicmil, 2006), p.2.
Where to look then for improvement in the field of project management? The good thing of
a poor track record in current project performance is the potential room for improvement.
The poor track record, however, also illustrates the difficulty to improve (…if the solution
would have been easy, it probably already had been implemented…). Nevertheless,
literature provides suggestions where to look for improvement in the field of project
management in order to improve project performance.
Prominently, the importance of the front-end development (FED) phase for improving
project performance is suggested (Artto, Lehtonen, & Saranen, 2001; Flyvbjerg et al., 2003;
Morris, 1994; Morris, Crawford, Hodgson, Shepherd, & Thomas, 2006a; Thamhain &
Wilemon, 1975). Particularly in early project phases (front-end phases), effort needs to be
thoroughly spent in, amongst others, defining project goals, building the project team,
assessing project risks and aligning stakeholders. Although the importance of thorough
front-end development has been stressed for years now, the fact that projects still fail could
be related to spending insufficient (and/or inadequate) effort in particular the early project
phases (Kolltveit & Grønhaug, 2004).
Another prominent theme in literature is the fact that all projects require a specific, tailored
management approach (Shenhar & Dvir, 2007a): project management could (should?) be
made contingent upon the project’s context or environment (Engwall, 2003; Howell,
Windahl, & Seidel, 2010; Sauser et al., 2009; Shenhar, 2001; Smyth & Morris, 2007;
Williams, 2005). This basically means that based on certain project characteristics, the
project management approach is to be adapted.
1.2 Research objective, research questions and scope

Given the need to improve project performance (Mc Kenna et al., 2006) , the increasing
project complexity as one of the contributors to project failure in terms of overspent budget
and late delivery (Williams, 2002, 2005), the importance of the front-end phase (Artto et
al., 2001; Flyvbjerg et al., 2003; Morris, 1994; Morris et al., 2006a), and the potential of
applying a contingency approach to project management (Engwall, 2003; Howell et al.,
2010; Sauser et al., 2009; Shenhar, 2001; Smyth & Morris, 2007; Williams, 2005), we
come to the threefold objective of this PhD research.
The first objective is to investigate what project complexity actually comprises and how it
influences project performance. The second objective is to investigate how front-end
activities could be adapted to the project’s complexity and how this influences project
performance. The third objective is to investigate the relations between these variables
(project complexity, front-end activities and project performance), amongst others by using
a contingency approach. The aim is to come to an effective and sufficient front-end
development phase, fitted to the project’s complexity. In this context effective means that
the activities in the front-end phase will enable a good project performance in terms of
meeting the technical specifications within cost and schedule estimates. Sufficient is
referring to the fact that not too little, but also not too much effort should be spent in the
front-end phase.
3
The main research question to be answered is:
How could the front-end phase be adapted to the project’s complexity in order to improve
project performance?
In order to answer this main research question; the following sub-questions are addressed:
1. What is project complexity as experienced by project professionals?
2. How can we characterize project complexity in large engineering projects?
3. How does project complexity influence project performance?
4. What are the relevant front-end activities to deal with project complexity?
5. How do front-end activities contribute to better project performance?
6. How can contingency theory be used to fit the front-end phase to the complexity of
a project?
7. How could a framework to grasp project complexity be used to improve project
performance?
To tackle a complex problem like this, it is wise to limit the scope. Therefore in this
dissertation we focus on the process industry in the Netherlands. How can current projects
in the process industry be characterized in very general terms? Such projects typically have
a technological component, leading to technological as well as commercial risks. They have
certain impact on the environment, either because it is a greenfield location (new facility,
not so common) or because it is a brownfield location (extension or modification of
existing facility, very common). A lot of parties are involved, including (sub)contractors,
(local) communities and non-governmental organizations. Projects differ largely in size and
content, ranging for example from several thousand Euro (small maintenance project) to
over 1 billion Euro (major unique investment project). And last but not least, projects are
performed by multidisciplinary project teams. These very diverse project characteristics,
together with the earlier mentioned poor track record that also holds for this sector (IPA,
2011), suggests an interesting playing field for research into managing project complexity.
Moreover, projects in the process industry can be characterized as projects that aim to
deliver CoPS (Hobday et al., 2000): highly customized products with the involvement of
multiple disciplines and parties.
More specifically, this research is 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 selected budget range was
chosen because the projects under consideration should have some serious “content” (hence
the lower range value was set to 1 million Euro), but not be overly unique (hence upper
range value was set to 500 million Euro). The owner’s perspective is taken as a starting
point, but in later stages of the research also the contractor’s perspective is included.
The research is 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 (NAP, 2009). It consists of about 100 member organizations. For the
different stages of the research, different selections of companies are included. The interest
of the NAP network in (improving) the front-end phase of projects is evident from their
publications on the 2x2 principle: delivering projects twice as cost effective and twice as
fast (de Groen, Dhillon, Kerkhoven, Janssen, & Bout, 2003) and subsequently a front-end
loading strategy to achieve the 2x2 goals (Oosterhuis, Pang, Oostwegel, & de Kleijn, 2008).
4
This proven interest in front-end activities makes the NAP network very well-suited for
participation in our research.
1.3 Research approach

To answer the research questions, a research approach is developed. First some background
information is provided on research approaches in social science and particularly in project
management research. Subsequently, the methods applied in this dissertation are presented.
1.3.1 Research in social science

Research in the field of project management often has a positivist character (Smyth &
Morris, 2007; Williams, 2005), e.g. it is assumed that there is one reality that can be
described by laws with causal relationships, observed by an objective observer (Braster,
2000). Positivism attempts to control the context by isolating the phenomenon under study.
Also the systemic view on project management has a positivist character. However,
particularly the interaction of the project (management) with its environment is important
since we aim to study adapting the project management to the project complexity.
Therefore a pure positivist approach is not sufficient in the current research: inclusion of
the environment would ask for a more constructivist approach (Pellegrinelli, 2011).
In constructivism (or interpretivism), there can be more views of reality, without underlying
causal relationships and the context is inseparably connected with the phenomenon under
study (Braster, 2000). Whereas in positivism events are explained based on linear thinking
in one reality (Smyth & Morris, 2007), in constructivism understanding by in-depth
analysis of the different realities prevails. An example of a constructivist approach is found
in the equifinality view expressed in the contingency theory (Donaldson, 2001). An
equifinality view means there is no unique solution but there are more ways in which
improvement can be achieved and contingency theory by definition includes the
environment in some way.
To investigate the management of complex projects, a pure positivist research approach

would limit the directions for resolving the complex management problem beforehand. On
the other hand: a positivist approach might also provide a starting point to handle complex
problems; for example by providing a model, method or a tool. This then should not be
considered as the end-point, but the starting point for solving the complex problem at hand
by including more constructivist principles. Such “mixed” approaches are suggested more
often (Blaikie, 2009; Tashakkori & Teddlie, 1998). Hence the current research aims to use a
constructivist approach in which positivist aspects are embedded.
In a research approach, two main methods of logic can be distinguished: deductive and
inductive reasoning. These are described in the well-known “Wheel of Science” (Wallace,
1971), see Figure 1.1. In a deductive approach the starting point is a theoretical basis. From
the theory, the hypotheses are derived that are checked by observations. This can lead to
confirmation or non-confirmation of the original or new theories. In an inductive approach,
the starting point is the observation. From specific observations, patterns are searched for
and preliminary hypotheses are formulated, leading to the development of new theory.
Eisenhardt, for example, successfully shows how an inductive approach can lead to new
theory building (Eisenhardt, 1989). She indicates that theory resulting from such an
inductive approach “is often novel, testable and empirically valid” (p.532), despite original
skepticism about qualitative inquiry that is often associated with inductive research (Miles
& Huberman, 1994).
5
Deduction
Theory
Empirical Hypotheses
generalizations
Observations
Induction
Figure 1.1: The Wheel of Science (Wallace, 1971)
In the Wheel of Science, phases of inductive and deductive research are naturally following
each other. For example, when there is no theory available, one starts with observations,
which via empirical generalizations can lead to new theory (induction). From this newly
developed theory, hypotheses are formulated which are then tested by, again, observations
(deduction). Although there is no single, unified theory on project management, different
disciplines in project management do have a firm theoretical basis from which hypotheses
can be formulated. Subsequently, these hypotheses are tested based on observations, which
is at the deductive side of the deductive/inductive spectrum. Often, positivism and
deductive reasoning are associated with the hard paradigm of project management and
interpretivism and inductive reasoning with the soft paradigm of project management
(Pollack, 2007). The Wheel of Science nicely connects these paradigms.
Pollack distinguishes practices based on the hard and soft paradigm in project management
as follows (Pollack, 2007). In the hard paradigm, practices “tend to emphasize efficient,
expert-led delivery, control against predetermined goals and an interest in underlying
structure”, p.267. In the soft paradigm, practices “emphasize learning, participation, the
facilitated exploration of projects, and typically demonstrate an interest in underlying
social process”, p.267.
Dependent on the research approach, multiple research instruments can be used within one
research project, such as experiments, surveys and/or case studies (Braster, 2000). In
project management research, an experiment could have the form of a simulation or a
game. Professionals could be asked to participate in such a simulation or a game to study
how they would behave in a simulated project environment. Surveys could provide global
information on large numbers of projects, whereas in-depth information, post-project or
even longitudinally, could be obtained by case studies. Different types of case studies can
be distinguished, such as exploratory, descriptive and explanatory (Yin, 2003). In an
exploratory case study, the focus is on exploration, whereas this is on description and
explanation (causality) in case of a descriptive or explanatory case study, respectively.
Explorative case studies are often done in initial phases of the research in a certain area,
having the most inductive character of the different types of case studies. Case studies
would be useful in both deductive and inductive approaches, as “the case study is useful for
both generating and testing of hypotheses but is not limited to these research activities
alone” (Flyvbjerg, 2011), p.306.
6
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.
Figure 1.2: Model project complexity / front-end activities / project performance
Where do the arrows in Figure 1.2 stem from? In this high level conceptual model, we
assume that performing front-end activities positively contributes to project performance
(…that’s what you do project management for...). Putting significant effort in the front-end
development phase is often recommended as a vital part of project management, with a
high influence on the final project result (Bakker, 2008; de Groen et al., 2003; Flyvbjerg et
al., 2003; Morris, 1994; Morris et al., 2006a; Oosterhuis et al., 2008; van der Weijde,
2008). Therefore we assume that front-end activities have this (direct) relationship with
project performance. Project performance is hypothesized to be negatively influenced by
project complexity (Flyvbjerg et al., 2003; Hall, 1981; Morris & Hough, 1987; Neleman,
2006; Williams, 2002, 2005). Hence, we assume that project complexity has a (direct) -
negative- relationship with project performance. Next to these two direct relations; a third
moderated relation is hypothesized: the front-end development phase of a project should be
adapted or fitted to the specific project complexity and a fit between these would positively
contribute to project performance. This is based on literature that suggests the application
of contingency theory to project management (Engwall, 2003; Shenhar & Dvir, 1996;
Smyth & Morris, 2007). Here project complexity acts as the moderator: based on the
project complexity, the front-end activities should be adapted.
The fact that the starting point of this PhD research is a model suggests that this research is
at the deductive side of the deductive/inductive spectrum (see also Figure 1.1). The model,
7
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 front-
end 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 NAP’s 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
8
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.
9
Figure 1.3: Overview of the empirical part of the research
To conclude this section, Figure 1.4 summarizes how the data is collected from the
different companies in the NAP network, across the four project phases. Phase I is focused
on projects from one company in the NAP network (a key player) whereas Phase II aims to
include projects from as many as possible NAP companies. In Phase III some cases from
the Phase II sample are studied in-depth and hence a few of the Phase II companies are
involved. Finally, Phase IV is focused on cases from a few key companies.
Figure 1.4: Data collection within the NAP network – company involvement
10
1.4 Scientific and social relevance

The underlying problem of this research is the continuing existence of cost and time
overruns in (increasingly complex) projects. This dissertation therefore focuses on an
understanding of project complexity. Different dimensions of project complexity are
investigated, as well as different perspectives on project complexity including the dynamic
character of project complexity. Because of the assumed importance of the early project
phases in project management literature, we focus on the so-called front-end development
phase of projects. Moreover, it is investigated how a contingency approach could be used to
fit the activities in the front-end development phase of a project to the project complexity in
order to reduce cost and time overruns in projects. With the new model to grasp project
complexity in engineering projects, recommendations for use of this model and
recommendations on the most relevant front-end activities for projects with specific types
of complexity, this study aims to contribute to a better understanding of how to improve
project performance. Due to a lack of large scale empirical research on project management
in business environments (Hodgson & Cicmil, 2006; Kloppenborg & Opfer, 2002;
Söderlund, 2004a), sound scientific evidence for either of the above suggestions is lacking
up to now.
In terms of scientific relevance; this research explores the use of a contingency approach to
project management. The use of a contingency approach is sometimes suggested in
literature as the way to go to improve project management, but at this stage mainly
conceptual papers in this area are available (Howell et al., 2010). This PhD research
investigates the application of a contingency approach to project management. By gathering
new empirical data and combining qualitative and quantitative techniques, this research
contributes to the further development of project management research. This study aims to
contribute to the development of project management theory based on business practice, by
applying and combining qualitative as well as quantitative research methods.
In terms of social relevance, this research could contribute to improving business practice
by improving the understanding and implications of project complexity. Also the
possibilities of adapting, or fitting, the front-end development phase of a project to the
project complexity is an expected result of this study: what can project managers do in the
early project phases to improve their projects? Improved understanding of the early project
phases is expected to result in improved project performance in terms of effectiveness and
efficiency, hence providing financial benefit for organizations delivering projects.
1.5 Dissertation outline

Figure 1.5 links the different chapters of this dissertation with the previously identified
research phases. It all starts with the literature survey on project management research in
Chapter 2. Subsequently, the exploratory case studies are presented in Chapter 3. The
findings of Chapter 2 and Chapter 3 come together in Chapter 4, in which a framework is
developed based on the literature and the case study results. Chapters 3 and 4 together
comprise the first phase of the research.
In Chapter 5 we describe how quantitative data is gathered by means of a survey study

within the NAP network. Results of this survey are presented in Chapter 6 (evaluation of
project complexity) and in Chapter 7 (evaluation of the relations between project
complexity, front-end development and project performance). These chapters together
comprise the second phase of the research.
11
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.
Figure 1.5: Overview of the dissertation
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.
2.1 What is a project?

The second edition of the handbook of project-based management provides a rather generic
definition of a project (Turner, 1999):
“A project is an endeavor in which human, financial and material resources are

organized in a novel way to undertake a unique scope of work, of given
specification, within constraints of cost and time, so as to achieve beneficial
change defined by quantitative and qualitative objectives” (p. 3).
In the third edition of this handbook, he limits the definition of a project to the key features
(Turner, 2008):
“A project is a temporary organization to which resources are assigned to do

work to deliver beneficial change” (p.2).
PRINCE2, a well-known, structured project management method, gives a similar definition

of a project (Murray, 2009):
“A project is a temporary organization that is created for the purpose of

delivering one or more business products according to an agreed Business Case.”
(p. 3).
All definitions indicate that a project is characterized by its temporary character, in which
a (unique) scope of work is undertaken, within certain constraints and for a particular
reason.
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 today’s project management (Hillson & Simon, 2007).
2.2 The development of project management

Where did project management come from? Project management evolved from “craft”, into
a profession, into a (semi-) discipline, but still theory development in project management
is in its early years (Shenhar, 2001). Because of the multidisciplinary nature of project
management, there is no unified theoretical basis (Smyth & Morris, 2007). Instead, one
could speak of “pluralism” in project management theory (Söderlund, 2011). The historical
development of project management can be summarized in three major stages (Maylor,
2005):
- Pre-1950s: no generally accepted or defined methods,
- 1950s: “One best way” approach, based on numerical methods established in the USA
for managing large scale projects,
- 1990s: A contingent approach based on strategy.
Before the 1950s, project management as such was not recognized. In the 1950s, tools and
techniques were developed to support the management of complex projects, mainly based
on a systems approach, treating the project as a mechanical activity. The timing (1950s) is
closely related to the rise of the computer, the development of systems engineering and
14
Chapter 2: Literature review
developments in management science. The traditional project management, concerned with

topics such as scheduling, cost control and work breakdown structures, started here. Most
of the development of tools and techniques such as the critical path method (CPM), the
program evaluation review technique (PERT) started in defense and aerospace engineering
and were then expanded towards other industries, for example construction (Morris, 1994).
Also a formal division of projects into several phases was introduced in this stage, initiated
by the US Air Force (USAF). In short, the following phases were distinguished:
- concept formulation,
- system definition,
- acquisition (detailed design),
- operation.
The division into phases enabled an integrated approach towards project development and
control. More generally, it provided a framework in which USAF could more
systematically manage the technical projects (clear definition of requirements,
configurations etc.). The finalization and close-out phase (compare Turner in Section 2.1)
was not yet specifically addressed.
The third stage, from 1990s onwards, is heavily dominated by the changing context in
which projects take place. There are increasingly complex and large projects, incorporated
in programs, with an important role for communication technology and knowledge
management. The project manager should act as a project integrator with attention for all
processes taking place around and in projects, giving a strategic role to projects, rather than
limit the attention to the single project. More and more it is realized that a project
management approach should be contingent upon its context (Shenhar, 2001). However,
despite this literature pointing in the direction of a contextual approach, nowadays project
management often still seems to ignore the influence of the environment (Artto &
Wikström, 2005; Koppenjan et al., 2011).
In the development of project management over time, briefly described above, a shift is
observed from focus on sole project management towards the broader management of
projects (Bryde, 2003; Fangel, 1993; Morris, 1994). At the end of the 1980s, project
management was extended towards project initiation and project finalization, leading to the
current focus on the wider context in which projects are undertaken (Laslo, 2010; Stretton,
2006), including portfolio and programme management and strategic aspects.
Pryke and Smyth summarize the development of conceptual approaches in project

management as follows (Pryke & Smyth, 2006):
1. Traditional project management approach,
2. Functional management approach,
3. Information processing approach,
4. Relationship approach.
In their view, these four approaches should be seen as complementary rather than
conflicting. The traditional project management approach includes the techniques and tools
for application, as described above. The functional management approach includes strategic
aspects such as management of front-end development, supply chain management,
partnering and programme and project strategies. The information processing approach is
based on an input-output model of management of projects (Winch, 2002), where the
management of the information flows is essential. Finally, the relationship approach
focuses on the social management of relationships between people, between people and
firms and between firms as project actors. The relationship approach tends towards a
15
process approach. These approaches illustrate the broadening perspective on project

management.
The UK research network “Rethinking project management” (Winter, Smith, Cooke-

Davies, & Cicmil, 2006a; Winter et al., 2006b) divides the current thinking in project
management into:
1. Based on rational, universal, deterministic models, emphasizing planning and
control dimensions of project management,
2. Based on models from organizational theories, emphasizing the organizational
structure as a means of achieving integration and task completion, for example
considering projects as temporary organizations,
3. Based on a broader view on projects, looking at major projects, developed into a
holistic “management of projects”.
Besides these three main streams of thinking, the following perspectives were also
recognized:
1. Interaction between projects and the strategic direction of the business enterprise
2. Projects as information-processing systems
3. Projects and project management from a critical management perspective.
Here the importance of strategic aspects seems more emphasized. Also the trend from
focusing on sole projects towards broader perspectives is recognized, as well as the
emphasis on process management, rather than project management.
Some argue that nowadays, a pure project management approach is not working well (de
Bruijn & ten Heuvelhof, 2007; de Bruijn, ten Heuvelhof, & in 't Veld, 2002). This would be
because of the continuous changes to incorporate in the project, as a result of the dynamic
environment. Therefore, instead of applying a pure “command and control” approach,
rather a process management approach of “prepare and commit” is advocated, or
combinations of these (Koppenjan et al., 2011).
In the development of project management, handbooks and bodies of knowledge are

playing an important role. There are several project management handbooks, all aiming to
be a reference guide for the fundamental concepts and techniques of project management.
The most widely known, not all embracing, include the Project Management Handbook
(Cleland & King, 1983), the PMI Project Management Handbook (Pinto, 1988), Turner’s
Handbook of Project Based Management (Turner, 2008), Meredith and Mantel’s
Managerial Approach on Project Management (Meredith & Mantel, 2006) and many others
such as (Kerzner, 2003; Pinto, 2004; Turner & Simister, 2000). In general, the handbooks
are strongly based on a traditional systems perspective. In fact, the concept of having a
handbook on project management, aiming to prescribe standard procedures, seems
contradictory to the unique character of a project. Selective application of these procedures
(“scaling not skipping”) might solve this intrinsic tension (Murray, 2009); the project team
is responsible for what to apply when (PMI, 2004; Williams, 2005). Based on certain
project characteristics or even company characteristics, the project management approach
could (…should…) be tailored (Turner, Ledwith, & Kelly, 2010), hence achieving a fit for
purpose scaled project management approach, starting from the front-end phase of projects.
Next to numerous project management handbooks, there are several formal institutions, all
maintaining their “body of knowledge” on project management:
1. PMBoK, by the US based Project Management Institute (PMI),
2. APMBOK, by the UK based Association for Project Management (APM),
16
3. P2M by the Japanese Engineering Advancement Association of Japan and the

Japanese Project Management Forum (ENAA).
The PMBoK is probably the most widely known, covering nine knowledge areas: project
integration management, project cost management, project communication management,
project scope management, project quality management, project risk management, project
time management, project human resource management and project procurement
management and five process groups: initiating, planning, executing, monitoring and
controlling, and closing (PMI, 2004). Whereas the PMBoK is mainly focused on project
planning, execution and control, the APMBOK and the P2M cover a broader scope; more
focused on the management of projects than on project management, i.e. including more
aspects of management through the project life-cycle (Morris et al., 2006a; Smyth &
Morris, 2007). In both APMBOK and P2M, there is explicit attention for more strategic
aspects. In the PMBoK, there is a strong orientation on internal processes and hardly any
attention for the project design. Although in the first chapter of the PMBoK it is stated that
“the project team should consider the project in its cultural, social, international, political,
and physical environmental contexts” the project management processes rarely mention the
project context, let alone how to act, react or interact in such a context.
In the IPMA Competency Baseline (Caupin et al., 2006) from the International Project
Management Association (IPMA) attention is paid to technical, behavioral and contextual
competence elements of project management. Explicit attention is paid towards contextual
aspects, which they however limit to “(…) the interaction of the project team within the
context of the project and with the permanent organization.” (p.6).
Williams argues that the various bodies of knowledge are based on three underlying
assumptions (Williams, 2005):
1. “Project management is rational and normative” (p. 500).
2. “Project management is based on positivism” (p.500): there is one reality,
determined by causal relationships and the observer should be independent of the
object under observation. Facts of the situation can be observed.
3. “Project management is particularly concerned with managing scope” (p.500), by
using models of work breakdown structures and project networks. The focus is on
analyzing by decomposition, rather than on integrating.
These underlying assumptions explain the emphasis of the bodies of knowledge on project
planning, project control and the decoupling of the project from its environment. Despite
the existence of project management handbooks and project management bodies of
knowledge, project failures are still common practice, suggesting we might have to broaden
our view towards a more contextual approach (Shenhar & Dvir, 2007b).
As stated earlier, in project management literature a distinction is made between project

management and the broader management of projects. Project management in its small
definition is seen as the “traditional” project management that focuses on project execution
(project controls!), whereas a broader definition of project management is captured by
“management of projects”, which contains everything related to project definition,
development and realization in order to deliver a successful project (Morris, 1994; Pryke &
Smyth, 2006; Smyth & Morris, 2007), including aspects of portfolio management.
Following the argumentation in this section, in the current PhD research we will also apply
project management in a broad definition, with a particular focus on the front-end
development phase of projects.
17
2.3 Trends in project management research

Not only project management is developing, also research in and about project management
is developing (Kwak & Anbari, 2009; Söderlund, 2011; Turner, 2010). Project management
research started from a practitioner’s perspective; lacking rigor, lacking citations, more
aimed at giving guidance to practitioners than at theory building. Turner described the
“evolution of project management research”: the quality and rigor of project management
research has been substantially improved over the past 20 years (Turner, 2010). In his view,
this was evidenced by the increasing number of relevant citations, the increasing number of
links with fields related to project management and the use of multiple methods within one
study. Next to case studies, also more quantitative approaches were applied in recent years.
Like the development of project management, the trends in current project management
research can be summarized by its emerging and broadening character (Crawford, Pollack,
& England, 2006; Kloppenborg & Opfer, 2002; Kolltveit, Karlsen, & Kjell, 2006; Shenhar
& Dvir, 1996; Söderlund, 2004a, b; Winter et al., 2006b). Project based research is moving
from the tools and techniques of project management towards more behavioral aspects
(Leybourne, 2007). Still a lack of empirical studies is observed, including the need for in-
depth case studies and studies in real time to further develop the theories of project
management.
Kloppenborg and Opfer provide a detailed overview of project management research

(Kloppenborg & Opfer, 2002). Starting with a focus on planning and scheduling during the
1960s, the research evolved from the development of automated software for cost and
scheduling (1970s) towards life-cycle costing and risk management in the 1980s. In the
1980s, research towards leadership and teambuilding was published, leading to even more
focus on human resources, teams and leadership in the 1990s. Shenhar and Dvir continue
the list with the 2000s, characterized by research on project typologies and contingencies,
strategic project management and globalization of projects (Shenhar & Dvir, 2007a). Their
suggestions for further development of the theoretical basis of project management are
given in Table 2.1. They suggest that different parts of the project management problem
could be tackled with developments in the different theoretical bases, hence emphasizing
the multidisciplinary character of project management.
Table 2.1: Directions for solving project management problems from different
perspectives (Shenhar & Dvir, 2007a)
Project management problem Theoretical perspective
Scheduling and resource allocation Operations research, network theory
Time overruns, escalating resources Theory of constraints - critical chain
Simultaneous management, knowledge and time
Uncertainty and risk management
perspectives
Contingency theory – a typological theory of
Adapting project management to project
project management, distinction between hard
differences
and soft aspects of projects
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”
(Söderlund, 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 decision-
making 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, Söderlund 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?
2.4 How to assess project performance?

What is project performance? When delivering a project, one speaks about the project
outcome, or the project result. Whether this project result is considered successful cannot be
stated unambiguously. Different parties involved in the project may (and will) have a
different view on the project and its success. For example, groups involved in project
definition & development, project implementation & execution and commissioning, start-
up & operations will have their own perspectives on the project (Morris, 1994). Therefore,
by definition the concept of project success has a subjective character (Bryde, 2008). Let’s
zoom in on the concept of project success.
20
2.4.1 Project success dimensions

Already in the late eighties, Morris and Hough distinguished three dimensions of project
success (Morris & Hough, 1987):
1. Project functionality: to what extent does the project perform financially and or
technically in the way expected by the project’s sponsors?
2. Project management: implementation of the project to budget, schedule and
technical specification?
3. Contractor’s commercial performance: did the contractors have a commercial
benefit in either short or long term?
These three dimensions express different perspectives on the project; the client, the project
team and the contractors, respectively. More recently, Shenhar et al. expanded this into four
dimensions of project success (Shenhar, Dvir, Levy, & Maltz, 2001):
1. Project efficiency: meeting time and budget,
2. Impact on the customer: meeting requirements and customer satisfaction,
3. Business and direct success: impact of the project on an organization,
4. Preparing for the future: organizational and technological infrastructure.
How do these views compare? The first dimension of Shenhar et al., “project efficiency”,
corresponds with the second dimension of Morris and Hough, except for meeting the
technical specifications or requirements, which is grouped into the second dimension,
“impact on the customer”. The second dimension corresponds to the first dimension of
Morris and Hough. The third dimension, “business and direct success”, corresponds to the
third dimension of Morris and Hough, although Shenhar’s view is not limited to the
contractor’s performance. The fourth dimension “preparing for the future” is additional
compared to Morris and Hough, although some long term implications are included in their
third dimension. Shenhar et al. state that with the increasing success dimensions, the
character of the project success becomes more long-term. Further, the relative importance
of the different project success dimensions varies for different types of projects. The
relative contribution of particularly the first and the fourth dimension would change with
increasing technological uncertainty. Note however that it is about the relative importance
of success dimensions to project success; a failure in the project efficiency dimension could
have disastrous consequences for a firm.
When assessing a project’s performance, a clear choice has to be made as to what definition
of project success is used. To facilitate such a choice, the concept of project success is
operationalized subsequently.
2.4.2 Operationalization of project success

Success measures following the success dimensions distinguished by Shenhar et al. are
given in Table 2.2 (Shenhar et al., 2001). Dependent on the focus of a specific study, often
only a few of these measures are included. Dvir et al. for example include meeting the
planning goals, end-user benefits and contractor benefits, with the latter covering
dimensions 3 and 4 (Dvir, Raz, & Shenhar, 2003).
21
Table 2.2: Success measures (Shenhar et al., 2001)

Success dimensions Success measures
Meeting schedule goal
1. Project efficiency
Meeting budget goal
Meeting functional performance
Meeting technical specifications
Fulfilling customer needs
2. Impact on the customer
Solving a customer’s problem
The customer is using the product
Customer satisfaction
Commercial success
3. Business and direct success
Creating a large market share
Creating a new market
4. Preparing for the future Creating a new product line
Developing a new technology
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
project’s 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 project’s
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) (Pinto, 1988) (Morris & Hough, 1987) (Cleland & King, 1983)
1. Goal commitment of
1. Risk management 1. Project mission 1. Attitudes
project team
2. Top management 2. Accurate initial cost
2. SHE compliance 2. Project definition
support estimates
3. Project schedule 3. Adequate project team
3. Trust 3. External factors
and plans capability
4. Client 4. Adequate funding to
4. Cost management 4. Finance
consultation completion
5. Adequate planning and
5. Value focused 5. Personnel 5. Schedule
control techniques
6. Minimal start-up
6. Team composition 6. Technical tasks 6. Implementation
difficulties
7. Organization and 7. Task (vs social)
7. Client acceptance
contract strategy orientation
8. Monitoring and 8. Communication and 8. Absence of
feedback controls bureaucracy
9. On-site project
9. Communication 9. Human qualities
manager
10. Clearly established
10. Troubleshooting 10.Resource management
success criteria.
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 & Müller, 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.
2.5 A closer look into project front-end development

During front-end development (FED) of a project, the why, what, when, how, where, and
who questions about a project are answered (IPA, 2009b). The Construction Industry
Institute defines FED as ”the process of developing sufficient strategic information with
which owners can address risk and decide to commit resources to maximize the chance for
a successful project” (Gibson et al., 2006). Also Turner identifies the need to determine the
strategy for the project’s management during FED (Turner, 2008).
These different sources point in the same direction: the main goal of FED is to provide the
owner representatives with a sufficiently complete image of the project to enable them to
24
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).
Figure 2.1: The influence of front-end development (Phase 1, 2, 3) on the value of a

project (Hutchinson & Wabeke, 2006)
What could be the value of front-end development (FED) is shown in Figure 2.1. This
figure indicates that good project definition, by definition (!), adds more value to the project
than poor project execution could subtract. Although, in our view, disastrous project
execution could devalue the project more than suggested in the figure (e.g. B could end up
with lower value than C), the general value of good project definition (hence FED) is clear.
What then comprises this front-end development (FED)? Typically, front-end development
is divided into a number of phases, through which the project is defined more precisely. A
formal stage-gated project management process with a number of phases within the FED of
a project is recommended (McGee, DeFoe, Robertson, & McConnell, 1999; Turner, 2008).
Turner explains this as follows: “We cannot go straight from a germ of an idea to doing
work. We need to effectively pull the project up by its boot straps, gathering data and
proving viability at one stage in order to commit resources to the next” (p. 9). By applying
a structured stage-gated project management process it is ensured that steps in the process
of generating the information that is required at the final investment decision (FID) are
taken in the right order. If some aspects are not well developed, this issue can be resolved
before expenses have been made in areas that build upon this aspect. The stage-gated
project management process facilitates a logical sequence of activities, which results in the
availability of information at the right moment. Furthermore, projects that do not meet the
capital investment requirements or do not have a fit with the desired portfolio can be
filtered out at the gates. Each of the FED phases prepares for the next stage-gate. The
typical front-end development phases (FED1, FED2, FED3) are named differently in
literature, see Table 2.4.
25
Table 2.4: Names for typical FED phases

Source FED1 FED2 FED3
(Turner, 2008) Concept Feasibility Design
(Morris & Hough, 1987) Pre-feasibility Feasibility Design
(de Groen et al., 2003; Define Do conceptual Do basis
Oosterhuis et al., 2008) business case design engineering
(IPA, 2009b) Appraise Select Define
(Hutchinson & Wabeke, Identify and
Select Define
2006) assess
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 IPA’s 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
Translate business objectives into required Project objectives
project performance Requirements on project premises
Preliminary cost and revenue assessment FEL strategy
Prepare level 1 schedule Cost estimate (+/- 40%)
Analyse safety issues WBS level 1 schedule
Risk identification and management Initial Hazard and Operability study (HAZOP)
Determine contract strategy Risk register
Feedback to and from stakeholders Contracting strategy
Plan the FED phases Technology review
Set up the FED organization Project execution plan (incl human factors,
alliances, benchmarking, innovation)
FED2
Define the scope
Evaluation report stage gate previous phase
Select the site
Basis of design (BOD)
Select technology
Process design basis
Define main equipment
Cost estimate (+/- 20%)
Identify critical unit operations
WBS level 2 schedule
Cost and revenue assessment
Update HAZOP
Prepare level 2 schedule
Update risk register
Analyse safety issues
Project execution plan (incl human factors,
Risk identification and management
alliances, benchmarking, innovation)
Compose the project team
FED3
Basic engineering
Evaluation report stage gate previous phase
Cost and revenue assessment
Basic design engineering package (BDEP)
Prepare level 3 schedule
Cost estimate (+/- 10%)
Analyse safety issues
WBS level 3 schedule
Risk identification and management
Update HAZOP
Define project funding strategy
Update risk register
Prepare the contracting plan
Project implementation plan
Define project strategic interfaces
Execution schedule
Team building
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
Table 2.6: Value improving practices as identified by IPA and CII

IPA VIP’s (IPA, 2009a) CII Best practices (CII, 2009)
Technology selection Alignment
Process simplification Zero accidents Techniques
Classes of facility quality Team building
Waste minimization Benchmarking and metrics
Constructability review Constructability
Process reliability modeling Change management
Customizing standards and specifications Dispute prevention and resolution
Predictive maintenance Implementation of CII research
Design-to-capacity Lessons learned
Energy optimization Materials management
3-D CAD Partnering
Value engineering Planning for start-up
Pre-project planning
Quality management
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.
2.6 Contingency theory

This section further explores contingency theory and its application on project
management.
2.6.1 History
Contingency theory originates from organizations studies (Dessler, 1976), with a number of
well-known pioneers (Burns, Stalker, & Woodward, 1961; Galbraith, 1973; Lawrence &
Lorsch, 1967; Thompson, 1967; Woodward, 1965). Decades later, Donaldson played an
important role in the revival of the contingency theory (Donaldson, 1996, 2001).
Burns and Stalker distinguished a mechanistic organization structure and an organic

organization structure (Burns et al., 1961). In a mechanistic structure, the organizational
roles are tightly defined by superiors who have the monopoly on organizational knowledge,
and in an organic structure, the organizational roles are loosely defined and decided upon
by mutual discussion between employees, with knowledge being dispersed among the
employees with their specific expertise (Donaldson, 1996). Burns and Stalker stated that a
mechanistic structure is effective when the organization faces a stable environment, and an
organic structure is required when the organization faces a high level of technological and
market change. In fact, they considered rate of change (of the environment, goals and
technology) as a contingency factor for organization structure. Woodward concluded that
complexity of technology is associated with either a mechanistic or organic organization
structure and organizations with a fit between structure and technology would perform
superiorly compared to organizations with a misfit between organization structure and
technology (Woodward, 1965). She determined complexity of technology as a contingency
factor.
Parallel to the work of Burns, Stalker and Woodward, Lawrence and Lorsch investigated
how the rate of environmental change affected the differentiation and integration of the
28
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 America’s 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 action-
level 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 Child’s 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
when applying a contingency approach to project management, first congruence between

the contingency factor(s) and the project management variables should be tested.
The “contingency school” in project management, see also Section 2.3, investigates how
“different environments require alternative approaches to project management, project
control and project planning” (Söderlund, 2011), p.160. Contingency factors have been
subject of investigation in several earlier studies into organizations theory, product
development and project management. Therefore this section further explores contingency
factors identified in literature, to investigate whether project complexity could be
considered as (one of) the contingency factor(s) for project management. As was stated
before, general contingency factors are strategy, rate of change, size, task uncertainty and
technology, as well as environmental hostility and product life-cycle (Donaldson, 1985).
An overview of the categorized contingency factors is given in Table 2.7.
To enable an overview, the contingency factors have been categorized into the following
six “meta”-categories (inspired by the contingency factors listed in Section 2.6.1): strategy
related, technology related, uncertainty related, complexity related, market related and
others. As the overview shows, the contingency factors differ a lot across the different
studies in terms of nature and level of abstraction.
The work of Shenhar and Dvir probably is the most prominent example of an application of
contingency theory in project management research (Shenhar & Dvir, 1996), distinguishing
“technological uncertainty, system scope (complexity), project pace and market
uncertainty, see also Section 2.9. Almost half of the studies summarized in Table 2.7
explicitly mention project complexity as a contingency factor. Besides, project complexity
could also be assumed to be influenced by several of the other contingency factors listed in
Table 2.7. Uncertainty seems even more present as a contingency factor than complexity
(explicitly mentioned in 9 of the 15 studies). Howell et al. published a contingency
framework including both complexity and uncertainty as contingency factors (Howell et al.,
2010). Their conceptual framework is based on uncertainty and its consequences, to be used
in project management. In their study, they distinguish 5 possible contingency factors in
project management: uncertainty, complexity, urgency, team empowerment and criticality.
In developing their framework, they assume that both complexity and urgency relate to
uncertainty, and team empowerment and criticality relate to consequences. The resulting
UC (uncertainty, consequences) framework could then be used to fit project management
process models to it, such as “plan driven models” (the traditional project management
approach), “problem structuring models” (more process oriented) and “emergent models”
(like agile methods from the IT sector). Their paper, however, just presents a conceptual
framework and is rather general at this stage in both the description of contingency factors
and the management models. Their planned further research on actually testing the
framework should also prove that taking together contingency factors, as they propose, is a
valid approach.
All studies listed in Table 2.7, included multiple contingency factors. Other related
research, not included in the table, suggests that project management strategy should be
based on both project complexity and technological uncertainty (Pich, Loch, & De Meyer,
2002; Sommer & Loch, 2004). However, in our definition of project complexity (next
section), uncertainty is one of the factors that determine project complexity.
31
32
Table 2.7: Overview of contingency factors found in literature, divided into 5 main categories and a sixth category “others”
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.
2.7 Project complexity

This section introduces and details current concepts of project complexity from literature.
First, project complexity definitions are explored. Next, concepts on project complexity are
presented followed by a discussion on the link between uncertainty, project complexity and
risk. This section concludes with a discussion on classification of projects based on their
complexity.
2.7.1 Defining project complexity

Van de Lei et al. provide an overview of complexity in multi-actor systems research (van
der Lei, Kolfschoten, & Beers, 2010). In their research, they distinguish the concept of
complexity in the context dimension and the concept of complexity in the actor dimension.
This distinction was based on systems theory (Waldrop, 1992), which says that complex
systems consist of many actors that continuously interact with a physical/technical
environment with an emergent character. Earlier, complex systems were already defined as
systems that consist of a large number of components that heavily interact with each other
(Simon, 1962). Following these definitions of a complex system, a project can be
considered, and often is considered a complex system (Whitty & Maylor, 2009).
However, in line with the work of Geraldi, no clear, unambiguous definition of complexity
of projects, or projects in a complex environment, was found in literature at this stage
(Geraldi, 2008c). Although the complexity of projects and their environment obviously
influences important decisions on and in project management, complexity as such is often
taken intuitively or from previous experiences. Or (Parwani, 2002): “(…) complexity refers
to the study of complex systems, of which there is no uniformly accepted definition because,
well, they are complex” (p.1). Despite the inherent difficulty of defining complexity and the
different views on complexity (Flood, 1990), a high level definition of project complexity
should include structural, dynamic and interaction elements (Whitty & Maylor, 2009).
Describing projects as complex adaptive systems or socially constructed entities (Cicmil,
Williams, Thomas, & Hodgson, 2006), complexity in projects could then be considered to
be related to such structural elements, dynamic elements and interaction of these; broader
than the technical or technological domain.
In the context of complex products and systems (CoPS) research (Barlow, 2000; Hobday,
1998; Hobday et al., 2000), critical product dimensions such as the degree of customization,
the degree of technological novelty, the quantity of sub-systems and components, variety of
knowledge and skills required and intensity of user involvement determine product
complexity. Obviously, product complexity will contribute to project complexity.
The College of Complex Project Managers and Defence Materiel Organisation (DMO) of
Australia briefly described characteristics of complex projects. Complex projects can be
distinguished from traditional projects in the following aspects (DMO, 2006a):
34
1. “Complex projects are characterized by a degree of disorder, instability,

uncertainty, irregularity and randomness;
2. There is dynamic complexity where the parts in the system can react / interact with
each other in different ways
3. There is high uncertainty about what the objectives are, and / or high uncertainty
in how to implement the objectives
4. There is a highly pluralist environment across the stakeholders where multiple and
divergent views exist
5. The strategy is outcome based, emergent and requiring constant renegotiation;
and
6. Complex projects are not just ‘complex adaptive systems’ but rather they are
‘complex evolving systems’ dominated by double loop learning – they change the
rules of their development as they evolve over time. They do not simply adapt to
their environment, but evolve with them.” (p.8-9)
This description of complex projects well illustrates the dynamic character of complex
projects. A distinction however should be made between complex projects and project
complexity, also referred to as the complexity of a project; the first is a specific class of
projects (namely the complex ones) and the latter focuses on what aspects make a project
complex.
2.7.2 Concepts of project complexity

The leading theoretical concept of project complexity found in literature is built upon the
concepts of uncertainty in goals and methods, structural complexity by differentiation and
interdependency and interactions between the different aspects (Baccarini, 1996; Turner,
2008; Turner & Cochrane, 1993; Williams, 1999; Williams, 2002).
The goals and methods concept (Turner & Cochrane, 1993) classifies projects according to
whether the goals of the project are well defined or uncertain and whether the methods to
achieve these goals are well defined or uncertain.
Baccarini published a review on the concept of project complexity in the construction

industry (Baccarini, 1996), proposing the following objective measure of project
complexity: “Project complexity consists of many varied interrelated parts and can be
operationalized in terms of differentiation and interdependency” (p. 202). Complexity as a
project characteristic is distinguished from other project characteristics such as size and
uncertainty. Both organizational and technological complexities are further elaborated by
differentiation and interdependencies as follows (Baccarini, 1996), as summarized by
(Williams, 1999):
(i) “In terms of organizational complexity, “differentiation” would mean the
number of hierarchical levels, number of formal organizational units, division
of tasks, number of specializations etc.; “interdependency” would be the
degree of operational interdependencies between organizational elements.
(ii) In terms of technological complexity, “differentiation” would mean the
number and diversity of inputs, outputs, tasks or specialities;
“interdependency” would be the interdependencies between tasks, teams,
technologies or inputs.” (p. 269)
Williams further operationalized the concepts of Baccarini and Turner (Williams, 1999). To
investigate aspects of project structural complexity, measures for product complexity which
influence project complexity are described. Project complexity is influenced differently by
35
different types of interdependency, such as pooled, sequential and reciprocal. It is suggested

that concurrent engineering is causing more reciprocal interdependency, adding to a
project’s complexity. Further dimensions of structural complexity include multi-objectivity
and multiplicity of stake-holders. Williams assumes that uncertainty adds to the complexity
of a project and therefore can be considered as a dimension of project complexity. Adding
the concept of Turner and Cochrane (uncertainty in goals’ and methods’ definition) to
Baccarini’s concept of project complexity, as well as adding interactions between
complexity and uncertainty, leads to the model given in Figure 2.2 (Williams, 2002). Note
the similarity of structural complexity and the definition of a complex system as provided
by Simon (Section 2.7.1) almost half a century ago (Simon, 1962).
Figure 2.2: Overview of dimensions of project complexity (Williams, 2002)
In the field of product innovation, complexity was characterized by the number of functions
and the interrelations between these functions (Halman, 1994), in fact again focusing on
structural complexity, the upper part of Williams definition in Figure 2.2.
Xia and Lee measured the complexity of information systems (IS) development projects
along two dimensions: organizational / technical and structural / dynamic (Xia & Lee,
2004). They concluded amongst others that complexity in IS development projects has a
multidimensional nature; hence supporting the idea of developing a broad framework to
grasp project complexity.
Whereas the authors mentioned above focused on “structural complexity” and

“uncertainty”, also softer aspects and influences from the environment are assumed to
influence project complexity (de Bruijn, de Jong, Korsten, & van Zanten, 1996; Geraldi &
Adlbrecht, 2007; Jaafari, 2003). Geraldi further developed the Williams concept earlier
described and distinguished the complexity of fact and the complexity of faith (Geraldi &
Adlbrecht, 2007) as well as the complexity of interaction. The complexity of interaction,
taking place at the interfaces between people and organizations, includes aspects like
politics, ambiguity and empathy (Geraldi, 2009), which are considered the softer aspects
that contribute to the overall project complexity.
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, & Wikström, 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 project’s 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 Perminova’s 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
2.7.4 Classification of projects based on their complexity

A large variety of project categorization methods is presented in literature in which project
complexity is used or which are based on project complexity. For example, Dvir et al. use
project complexity in categorizing projects following the novelty, complexity, technology
and pace (NCTP) framework (Dvir, Sadeh, & Malach-Pines, 2006), based on their earlier
work to categorize engineering projects based on uncertainty and system scope (Shenhar &
Dvir, 1996). Also others presented categorization or classification methods for projects
(Crawford, Hobbs, & Turner, 2005; Gidado, 1996; Santana, 1990; Stretton, 2006;
Westerveld & Walters, 2001). Well-known institutions in the field of project management
also have developed and are using project categorization methods which relate to project
complexity: CRI-project profile, DMO-ACAT, GAPPS-CIFTER and IPMA. The methods
developed by the latter category were included in a comparative study (Bosch-Rekveldt &
Mooi, 2008).
CRI: Project profile

The Cooperative Research Centre (CRC) for Construction Research Innovation (CRI)
developed a decision support tool to determine project profiles of projects in construction of
public infrastructure, both civil and building projects (Sidwell & Kennedy, 2004a, b). The
project profile is based on size, complexity, risk and objectives and is created from answers
on 25 questions about the project. The result is a unique fingerprint of a project in four
dimensions (size, complexity, risk identification and objectives), all scored on a 3 point
scale (easy – normal – difficult). The profile of the project can then be compared with
projects already stored in the database (best practices).
DMO-ACAT: Policy for categorisation of projects

The Defence Materiel Organisation in Australia (DMO) developed the methodology of the
Acquisition Categorisation (ACAT) Framework to categorize projects. The projects are
categorized based on six attributes (DMO, 2006a). All attributes are scored as Level 1 (very
high), Level 2 (high), Level 3 (moderate) or Level 4 (low). The outcome is submitted in the
ACAT score calculator that contains built-in algorithms with weighting factors and then
returns the ACAT level I to IV (most complex to least complex). The method is used in
DMO practice, to assign the projects depending on their phase in the project life cycle to a
sufficiently skilled project manager. Since the complexity of a project will change due to
the dynamic and changing environment, several reviews on the ACAT level are done
during the project.
GAPPS: CIFTER
The Global Alliance for Project Performance Standards (GAPPS) published a framework
for performance based competency standards for Global Level 1 and 2 project managers
(GAPPS, 2006). Aiming for a match between the management complexity of a project and
the skill of a project manager, GAPPS uses a tool to categorize projects based on their
management complexity, called the Crawford-Ishikura Factor Table for Evaluating Roles
(CIFTER). Seven CIFTER factors identify the characteristics of project management
complexity, rather than project complexity. Each of the factors is rated 1 to 4 and the
summed total is an indication for the overall project management complexity (the higher
the total, the higher the complexity). Duncan discussed the subjective nature of the
assessment (Duncan, 2006) but concluded still it enables to distinguish between
managerially less and more complex projects, using a consistent assessment.
39
IPMA: evaluation table project management complexity

IPMA developed a four level certification system for project management. A distinction is
made between project management associate (level D), project manager (level C), senior
project manager (level B) and project director (level A). To assess the project management
complexity in a project for IPMA level B certification, an evaluation table was drafted,
distinguishing ten criteria groups (IPMA, 2007). Within each criteria group, 4 or 5 aspects
are to be scored. Per criteria group rates are given from 1 (limited complexity) to 4
(significant complexity) and then summed, resulting in an expected complexity of the
project management in a project.
Comparison of the four methods

The IPMA project complexity classification table is the most extensive of the methods
under consideration. It is very descriptive and attempts to distinguish the projects that can
follow standard approaches from less common ones that go beyond all standards. It has a
strong focus on the organizational and technical project management aspects, whereas the
GAPPS-CIFTER method focuses more on the interaction between project and business
environment (political, economic, social, legal, environmental, strategic), even broader than
the IPMA method. GAPPS-CIFTER takes into account some technical project management
aspects as well.
The ACAT method covers within the aspect “project management complexity” quite some
technical project management aspects of the IPMA method, but in a more implicit way.
ACAT seems to be on a more general (less operational) level, compared to IPMA. The
IPMA aspect on “leadership, teamwork and decisions” is lacking with ACAT, but ACAT
explicitly includes commercial aspects, under which for example subcontracting issues
could be covered, not so obviously present in the IPMA categories. ACAT and GAPPS-
CIFTER seem to be on a similar level of abstraction.
The CRI-project profile method seems the simplest method, or uses the most general
terminology when reduced to its four main aspects, although it is based on 25 indicators.
The CRI-project profile method does not address technical project management aspects
when determining the project profile neither does the method address more than the aspects
in the IPMA method. As opposed to and considered beneficial over the other methods, the
CRI-project profile method results in a profile, rather than a single factor.
The majority of these methods score project complexity on several aspects and then sum
the individual scores (sometimes including weight factors) to come to “the” single project
complexity. We believe that this simple, one dimensional, systemic project complexity
score does not appreciate the variety of aspects that are suggested to determine project
complexity, such as technical, organizational and environmental aspects. Also literature
indicates that often, mono-criterion approaches in decision making contexts “lead to
wrongly neglecting certain aspects of realism” (Roy, 2005), p.6. Therefore the current
research focuses on a multi-dimensional concept of project complexity. Such a multi-
dimensional approach is supported by recent literature findings (Dombkins, 2008; Geraldi,
2008b; Hass, 2007; Maylor et al., 2008).
Regardless of how project complexity is characterized, the subjective character of the

concept is a source of concern: different actors involved in a project may have a different
view on the complexity of a project. Which project stakeholders can typically be
distinguished based on project management literature?
40
2.8 Project related stakeholders – external & internal

Achterkamp and Vos provided an overview of the stakeholder notion in project
management literature (Achterkamp & Vos, 2008). In their view, most often it is well
understood that to make a project a success, attention should be paid to the interest of
relevant stakeholders. In order to answer who these stakeholders could be, Mitchell, Agle
and Wood introduced the stakeholder identification and salience model, distinguishing the
attributes of power, legitimacy and urgency (Mitchell, Agle, & Wood, 1997). These three
attributes should be considered dynamic (as opposed to static) and as socially constructed
(as opposed to an objective reality). Figure 2.3 summarizes their model, distinguishing 8
types of stakeholders. The more attributes are present in a certain group of stakeholders, the
higher the stakeholder salience, i.e. the more the managers give priority to those
stakeholder claims.
POWER
1
Dormant
Stakeholder LEGITIMACY
4
Dominant
Stakeholder
2
5 7
Discretionary
Dangerous Definitive
Stakeholder
Stakeholder 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 starting-
point to distinguish stakeholders within a project (Achterkamp & Vos, 2008). Their
classification model is based on Ulrich’s 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 organization’s
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 Turner’s roles,
Achterkamp’s 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 project’s complexity and how to adapt
the FED phase to the particular complexities.
2.9 Studies on adapting project management to project

characteristics
To conclude this chapter, project management literature was searched for relevant studies
on adapting project management to certain project characteristics. Whereas the focus in this
dissertation is on three main blocks: project complexity (considering project complexity as
a project characteristic), project front-end activities and project performance, most of the
studies only involved two of these three variable blocks.
Relationships between the application of project management techniques and project

characteristics were already investigated by Bu-Bushait more than twenty years ago (Bu-
Bushait, 1988). The study included 46 projects varying from construction projects, research
and development projects to maintenance and administrative projects. Project
characteristics included in the research were project size, managerial complexity and level
of uncertainty. Project management techniques were grouped into planning/scheduling and
controlling techniques, so limited to some basic “hard” management aspects. No
statistically significant relations between project management techniques applied and
project uncertainty or managerial complexity were found; only project size was shown to
have a significant statistical relation with the application of project management techniques.
However, only two complexity levels were distinguished (simple and complex), only basic
(hard) project management techniques were included and the size of the projects involved
was not released.
Shenhar and Dvir tried to classify engineering projects and project management styles
(Shenhar, 1998; Shenhar & Dvir, 1996). A link to critical success factors was made in
42
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
manager’s 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

Hyväri using both case studies and surveys (Hyväri, 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, pre-
construction 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.
2.10 Summarizing the starting points for the research

This chapter aimed to sketch the scene for the research undertaken and finding relevant
gaps in current literature. This concluding section lists the starting points that were distilled
during the literature review.
Project management was shown to shift from a traditional “one size fits all” and “command
& control” approach towards a more adaptive project management style, taking into
account the environment and including a “prepare and commit” approach (de Bruijn et al.,
2003; Shenhar & Dvir, 2007b). Such a more adaptive project management style could be
based on a contingency approach, as suggested by several researchers (amongst others
(Engwall, 2003; Shenhar, 2001; Smyth & Morris, 2007; Williams, 2005), but at this stage,
no broad application of contingency theory in project management was found. Applying
contingency theory on project management could mean that the early project phases, called
the front-end development phase (FED) of which the importance was shown in this chapter
(Flyvbjerg et al., 2003; Morris, 1994; Morris et al., 2006a), should be made contingent
upon a certain project characteristic. One of the characteristics of a contingency approach is
the existence of equifinality: there is not one single optimum solution but there are several.
Moreover, contingency theory by definition included the context or environment, thereby
applying a constructivist approach by default.
45
The certain project characteristic to be used as contingency factor could be the project’s
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 project’s 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):

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 project’s 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
Chapter 3: Exploratory case studies
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 in-
company 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 project’s 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 front-
end 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
3.1.3 Case selection

Based on Yin a replication logic was used for case selection (Yin, 2002). This information
oriented strategy was chosen in order to “maximize the utility of information from small
samples and single cases” (Flyvbjerg, 2006), p.230. The cases together, summarized in
Figure 3.1, covered both successful and less successful projects in terms of meeting budget
and schedule estimates and delivering according to technical specifications (project
performance: poor – good). A range of project types in existing or new markets was
included, such as innovative projects, construction of facilities and new businesses
(market/business: existing - new). Technology involved in the projects ranged from
old/proven technology to new/unproven technology (technology: old- new). The capital
expenditure (Capex: 0 – 600 $Million) of these projects ranged between US$ 20 Million
and 600 Million. Different geographical areas were covered (Europe, Asia and Middle-
America) and the project location varied between industrialized and remote areas (location:
industrialized - remote). The projects differed in project ownership; e.g. from 100% owned
to JV partnerships with partial ownership (project owner type: single owner - JV). Figure
3.1 shows the broad variety in project characteristics for the projects included in the case
studies.
The selected cases also had to fulfill the following conditions:

- Completed projects, as opposed to current projects. For completed projects,
considerably more project information is available, for example crucial information
regarding project performance.
- Recent projects, hence project close-out in 2002 or later (at most 5 years before the
case study was initiated). An even longer time span might have colored the views of
the participants and memories might have become vague.
- Sufficient availability of the foreseen interviewees (traceable contact persons).
Figure 3.1: Summary of selected cases, case 1 to 6
3.1.4 Data analysis

Qualitative analysis of the cases was done per case as well as across the different cases,
focusing on the different perspectives of the interviewees on the project’s complexity and
the front-end activities. All data was gathered in one database, combining the answers of
50
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 project’s 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 project’s 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 project’s 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 front-
end 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
Table 3.1: Interviewees and their involvement in the project

Work Involved
Involved in Involved in
Project
experience in front
Role in the project earliest phase project
in 2008 end phase
of project execution
(years) project
1 Project manager 35 No Yes Yes

1 Project controls manager 35 Yes Yes Yes
1 Future site owner 29 No Yes Yes
2 Project manager 30 No No Yes
2 Engineering manager 12 No Partial Yes
2 Project owner 15 No Yes Yes
3 Process design / ADM 31 Yes Yes Yes
3 Future plant owner 31 Yes Yes Yes
4 Project manager 45 No No Yes*
4 Lead process engineer 18 No Yes No
4 Asset development manager 19 No Yes Yes
5 Lead engineer 23 No No Yes
5 Managing director 24 Yes Yes Yes
6 Project manager 28 No No Yes
6 Project manager front-end >30 Yes Yes No
6 Control manager 17 Yes Yes Yes
* Project manager was only involved in the late project execution phase
3.2 Case 1: Design, construct and start-up of a chemical plant

(good project performance)
3.2.1 Brief case description
The objective of project 1 was to design, construct and start up a new chemical plant in
South-East Asia, in an industrialized environment. The plant was a copy of an existing
plant and mainly proven technology was used, with some smaller unproven parts. The
project was owned by a two partner joint venture that was established for this project. The
project team consisted of about 55 members in the owner’s team. There was close co-
operation with the engineering contractor, who worked under a lump sum plus incentive fee
EPCM (Engineering, Procurement, Construction, Management) contract. The contractor’s
team consisted of about 200 members. A maximum of around 4000 workers were onsite
during peak time. The planned capital expenditure of the project was about 520M$ and it
was a cost driven project. The project was considered as existing business for the company.
Based on project documentation, it was concluded that the project performance was very
good in terms of meeting budget, schedule, quality and health, safety and environment
(HSE) requirements.
3.2.2 Interview results on project complexity

A summary of the interview findings on project complexity is given in Table 3.2.
52
Table 3.2: Summary interview results on project complexity, project 1

Scores (1-5)*
Overall
Organizational
Environment
Project
Project Complexity changed direction of
Technical
Perspective
complex? during lifetime? complexity
change?
1 Project manager Yes 1 2 2 Yes Decrease

1 Project controls manager Yes 2 2 2 Yes Decrease
1 Future site owner Yes 3.5 4 2 Yes Decrease
*
1 = low complexity, 5 = very high complexity
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 didn’t 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 project’s complexity was related to
the many parties involved at both owner and contractor’s 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 manager’s 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.
Table 3.3: Summary interview results on FED, project 1

Project
Opinion on
Perspective Value of FED?
“Fit for purpose scaling”?
Importance of team integration Rules and procedures are a
1 Project manager Thorough FED prevents scope must, but not too much,
changes PM needs flexibility
Thorough FED enables straight Follow all procedures,
1 Project controls manager
implementation no bypassing
PM should get real
1 Future site owner Importance of team integration
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 front-
end 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 pro-
actively 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
3.2.4 Overall case conclusion

Although at first sight, project 1 could appear to be very complex (working with a joint
venture partner, large CAPEX, a large number of people involved); this wasn’t experienced
as such by the experienced interviewees. They indicated that the project was complex, but
only to a small extent. From the interviews, the value of the integrated team became
apparent. In this project a well-integrated project team was realized, with people from the
contractor and the two owner’s organization working closely together in the FED phase as
well as during project execution. Note the (accepted but apparent) dominance of the project
manager’s company in the JV. Still the presence of the JV did considerably contribute to
the complexity of project 1: additional effort was spent to align the parties involved.
Thorough attention in the FED phase enabled the straight forward implementation of this
large project. The interviewees had a clear difference of opinion regarding “fit for purpose
scaling”: in view of the project manager and the future site owner, flexibility for the project
manager works out. The controls manager however does not believe in a more flexible
approach. In view of the project manager, project management in fact is nothing more than
people management. This was successfully applied in project 1.
3.3 Case 2: Development and construction of a new facility

The objective of project 2 was to develop and build a large facility in Central America, in a
rather industrialized environment. The facility consisted of proven technology. The project
was owned by a two partner joint venture that was established for this project. The two
partners both had a background in the oil and gas industry. The project team consisted of
about 22 members (12 expats and 10 locals) in the owner team. The maximum number of
workers on site was around 1500. The planned capital expenditure was about 370M$ and
the project was schedule driven. The owner organization had neither experience with
building such a facility in that country nor with the engineering contractor involved,
although they did have experience with this type of asset. The project was therefore
considered as considerable new business for the company. The contractor worked under an
EPCC (Engineering, Procurement, Construction and Commissioning) lump sum contract.
Based on project documentation, it was concluded that the project performance was very
good in terms of meeting budget, schedule, quality and HSE requirements.

A summary of the interview findings on project complexity is given in Table 3.4. The
project manager considered project 2 as complex in several aspects: multiple shareholders
with non-aligned objectives, technically complex because of the physical size of the site
location and its consequences for logistics. Further, in his view the project included a
complex technical process, in which different steps had to be taken in a specific order with
different materials and specialisms involved, high quality requirements and limited
specialized resources available. The aspect that contributed most to the project complexity,
according to the project manager, was related to the different stakeholders involved.
In contrast to the project manager, in view of the engineering manager, project 2 was not
complex: the technical scope he didn’t consider as complex. He considered the interfaces
little more complex; particularly the relations with stakeholders and clients in the country
where project 2 was performed. He did not consider the project as complex, but still the
55
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.

Scores (1-5)*
Complexity Overall
Organizational
Environment
Project
Project changed direction of
Technical
Perspective
complex? during complexity
lifetime? change?
2 Project manager Yes 2.5 4 2.5 Little Decrease

2 Engineering manager No 2 3 4 Yes Increase
2 Project owner No/yes 3 4 5 Yes 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.

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
Opinion on
If done thoroughly, no new complexity
No formal procedures, freedom
2 Project manager in execution, except for the
works well for experienced PM
unexpected.
If requirements were clear in FED,
Engineering
2 unforeseen scope elements could have - (not discussed)
manager
been tackled.
Applied in the project, FID
Reducing risks
2 Project owner decision was taken based on
Stimulate team integration before FID
(too) limited information
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 owner’s 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.

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 project’s 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 owner’s 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.
3.4 Case 3: Design and construct of chemical plant (marginal

project performance)
The objective of project 3 was to design and construct a chemical plant in an industrial area
in Western Europe. The plant was a copy of an existing plant, only the layout had to be
adapted for this project. Although some improvements were made with respect to the
existing plant, proven technology was used, but the owner organization didn’t have much
experience in this specific field. The project was fully owned by a subsidiary company of
58
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.

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 owner’s 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.

Scores (1-5)*
Complexity Overall
Organizational
Environment
Project

Technical
Perspective
lifetime? change?
Decrease /
3 Project manager Yes 1 5 3 Yes
increase
3 Process design / ADM No 2 4 2 Yes Increase
3 Future plant owner No 2 5 1 Yes 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 project’s 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.

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 owner’s 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
Opinion on
Applied in the project, from technical
Assessing foreseen parties
perspective; does the technology
3 Project manager whether they were capable of
allow for skipping certain
doing the project.
procedures.
Owners Organization management
FED had no value in treating
Process design / methodology was strictly applied,
3 complexity (organizational
ADM overvaluing planning, not really “fit
complexity not foreseen)
for purpose scaling”.
Not really applied, but highly
3 Future plant owner Clear role distribution
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 owner’s organization management methodology, without having the possibility to adapt
it to their particular project. One consequence of following the owner’s 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.

Looking generally at the project characteristics, this project would not be considered very
complex. There was only one company involved (the owner’s 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
owner’s organization and the subsidiary company, with the owner’s organization providing
the project manager. This tension might have influenced the perception of the interviewees
on how the project’s 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
3.5 Case 4: Modification of current facility (poor project

performance)
The objective of project 4 was to improve operational performance at a large site in an
industrialized area in Western Europe. The project was a typical brownfield project
consisting of modification and extension of current equipment. Only proven technology
was included in the project, but not all partners did have experience with the technology
involved. A subsidiary company of the owner organization was the owner of the project.
Several departments within the company were involved including technical disciplines and
more project related ones. The project team consisted of the project manager, the cost
controller, the construction manager of the engineering contractor and the project manager
of the engineering contractor. The contractor worked under an EPCM contract as part of a
broader alliance contract. The workforce typically ranged between ~20 and ~70 people on
site. The planned capital expenditure of the project was about 35M$ and the project started
as a schedule driven project. The project schedule drive, however, decreased because of
unforeseen changes in the market. The project was considered existing business for the
company. Based on project documentation, it was concluded that the project performance
was poor in terms of meeting budget, schedule, quality and HSE requirements.

A summary of the interview findings on project complexity is given in Table 3.8. In view
of the project manager, project 4 was complex in team aspects, in terms of underestimation
of the technical complexity and organizational aspects like multi-phased project execution
and the brownfield character. The aspect that contributed most to the project complexity,
according to the project manager, was related to technical organizational aspects,
particularly in the project execution phase.

Scores (1-5)*
Complexity Overall
Organizational
Environment
Project

Technical
Perspective
lifetime? change?
4 Project manager Yes 4 4 4 No n.a.

4 Lead process engineer Yes 3 4 1 Yes Increase
4 Asset development manager Yes/no 4.5 3.5 2.5 Yes 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.

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 weren’t 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
Opinion on
Complexity in execution was not recognized All procedures were
in FED; project should have been put on hold followed but the content
4 Project manager
in FED. FED should be more about content, and real depth was
less tick the box. lacking.
Consequences for project implementation
Part of FED was skipped
were underestimated, despite involvement of
Lead process in this project and is
4 operations people.
engineer skipped too easily in
Only after FID people seem to start thinking.
general.
Continuity in the project team matters.
The project did
No one realized the complexity of the everything it had to do
Asset development project, interrelations between different and more. But: the
4
manager elements. quality of the activities
In case of late scope changes, postpone FID. 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

Based on the project characteristics, some complexity could have been expected in the
project. It was a brownfield project, i.e. there could be complicating interactions with the
current site. Not all partners involved did have experience with the technology involved. On
the other hand, it was existing business for the company and there were not so many people
involved. Still the complexity of the project was considerably underestimated in the FED
phase, particularly because of all different (small) scope elements and their unforeseen
interactions, and the project showed serious underperformance. The complexity of the
project was perceived to increase during the lifetime of the project, but it seems this
increase is related to underestimation of complexity in earlier project phases. Also
underestimation of the interaction with the current site might have played a role, e.g. the
brownfield character of the project in contrast to a greenfield project in which less
interaction problems would be expected.
Based on the gathered information, the lack of real content could be one of the reasons for
poor project performance. Procedure-wise, all was done that had to be done, but the
activities lacked the required content. Although operations people were involved in the
project, the operation of the existing facility got priority over the project. Operations
implementation planning seems not to be taken seriously. Also discontinuity in the project
team might have contributed to the poor project performance.
3.6 Case 5: Development of new offshore energy facility (good

The objective of project 5 was to gain experience with the development of new offshore
energy sources in Western Europe, hence in a remote environment. Unproven technology
was involved. The project can be characterized as a demonstration project for companies as
well as governmental parties involved. The project was owned by a two partner joint
venture, established for this project. The two partners were complementary in terms of
expertise. The contractor worked under a lump sum turnkey contract. The owner’s project
team consisted of 5 to 6 members, the project team at the contractor had about 50 members.
Including the workers, at the peak there were about 130 people working on the project. The
planned capital expenditure of the project was about 200M$, partly financed by
governmental subsidies. The project was both cost and schedule driven; there was a fixed
price as well as a fixed schedule. Note that this twofold drive (cost & schedule!) is
remarkable, but in this project it was related to the obtained subsidies. This project was
considered new business for the company. Based on project documentation, it was
concluded that the project performance was good in terms of meeting budget, schedule,
quality and HSE requirements.

A summary of the interview findings on project complexity is given in Table 3.10. In view
of the project manager, project 5 was complex in terms of the scale of the overall project.
The number of parties involved was high (lots of subcontractors) and the arrangements for
corporate governance were numerous (it was a joint venture structure both at owner’s and
contractor’s side). Because of the contract type, the contractor had to control most of the
complexity, but still the project manager considered the project complex. He could not
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.

Scores (1-5)*
Complexity Overall
Organizational
Environment
Project
Technical
Perspective
lifetime? change?
Increase,
5 Project manager Yes 4 3 4 Yes
areas change
5 Lead engineer Yes 4 2-51) 2 Yes Increase
2) Decrease /
5 Managing director No 3 4 2-4 Yes
Increase
*
1)
Perspective owner organization: 2, perspective contractor: 5.
2)
Project execution phase: 2, front-end phase: 4.
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.

A summary of the interview findings is given in Table 3.11.

Project
Opinion on
Process of putting together good

project execution plan before FID. There was no formal assurance
This was a huge effort that brought process; they drafted a process
5 Project manager
together the team. based on the available
Rigorous management processes are procedures.
important.
Not aware of “fit for purpose
More attention should have been given
scaling” applied in the project.
to HSSE culture at (sub)contractors
5 Lead engineer In his view procedures used
and experience of parties involved,
were based on existing
could have increased the value of FED.
standard procedures.
Increasing technical complexity could
have been better taken care of in front-
Useful. A careful selection of
end (more detailed design study). More
existing standards was used in
5 Managing director influence of owner organization, less
this non-traditional project.
work at contractor. More attention for
There was liberty to do so.
treating organizational complexity:
bringing different cultures together.
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 owner’s 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 owner’s 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.

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 owner’s 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
3.7 Case 6: Construction of new facility (marginal project

performance)
The objective of project 6 was to build, own and operate a new plant that would act as the
gas supplier for an existing plant in a rural area in Asia. Implementing a new technological
process was seen as a sustainable solution to keep that existing plant economically viable.
New and unproven technology was included in the project. The project was owned by a two
partner joint venture. The partners of the joint venture had different backgrounds
(international oil company and a local, government owned company). The main contract
type with the engineering contractor was EPC lump-sum. The project team consisted of
about 20-25 members in the owner’s team. The majority of the project team members were
local employees, also because of the required local content. In total, there were about 1000
workers onsite. The planned capital expenditure of the project was about 220M$ and it was
a cost driven project. The project was considered rather new business to the company.
Based on project documentation, it was concluded that the project performance was just
acceptable in terms of meeting budget, schedule, quality and HSE requirements. Schedule
delays and cost overruns were compensated by a successful start-up and handover.

A summary of the interview findings is given in Table 3.12.

Scores (1-5)*
Project complex?
Complexity Overall
Organizational
Environment
Project
changed direction of
Technical
Perspective
during complexity
lifetime? change?
6 Project manager Yes 4 4 3-4 Yes Evolving

6 Project manager front-end Yes 3 2 4 Yes Decrease
6 Control manager Yes 5 5 4 No 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 owner’s 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 start-
up, 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.

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.

Opinion on
Project
Perspective Value of FED? “Fit for purpose

scaling”?
In hindsight it is easier to see what you should

have done, although considerable effort was Not applied in the
6 Project manager
spent in FED. One never knows the problems project
that will happen when construction starts.
FED tried to prepare for project complexity, for
Project manager Not applied in the
6 example by specifying all in the JV contract on
front-end project
which he often relied.
FED tried to address all complexities, Not applied in the
6 Control manager
technological challenges became clear. 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.

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.
3.8 Cross case analysis

This section presents a cross case analysis towards the different perspectives on project
complexity and the possibility of adapting front-end development to specific project
complexities.
3.8.1 In which way do project professionals consider their project

as complex; how do their perspectives on project complexity
differ?
This section analyzes the 18 interviews, grouped into perspectives of the project managers
(7), the team members (6) and the owner representatives (5) on the complexity of their
projects.
The view of the project manager, having main responsibility for the project, is considered
most important. All project managers considered their project “complex”. The aspect they
considered most complex was for 5 of them related to organizational complexity, for one
related to operating in the specific environment and for one a combination of different
aspects, including organizational complexity. Hence organizational complexity prevails, in
perspective of the project managers. Technical complexity is not mentioned as contributing
most to project complexity, in view of the project managers, even though some (parts) of
the projects could be considered as highly innovative. The project managers, all having an
engineering background, seem so well trained in the technical area that they have full grip
on and understanding of the technical aspects.
Six of the project managers indicated the project complexity changed during the project life
cycle. Three of them indicated the complexity decreased, the others emphasized that the
complexity areas changed. From the latter three, two of them indicated an increase of
technical complexity after the final investment decision. This is opposite to the earlier
mentioned decrease, but this might be explained by the level in which the technical design
was clear at the moment of investment decision and/or the use of unproven technology in
the project. The other project manager indicated that the project complexity in the
execution phase was underestimated in the project development phase. So the opinions on
the complexity development throughout the project differed considerably amongst the
project managers.
Four of the six team members considered their project “complex”. Similar to the project
managers, the aspect they considered most complex was for the majority of the team
members (4) related to organizational aspects. One team member stressed the linkage of
different aspects being the most important and one team member considered the difficulty
of influencing the local stakeholders as contributing most to project complexity. Again
technical complexity was not referred to as contributing most to project complexity.
Five of the six team members indicated the project complexity changed during the project
life cycle, of which four saw an increase of project complexity in the execution phase. The
72
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 couldn’t 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 owner’s
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
3.8.3 Classification of projects according to their complexity level?

Now the project complexity was investigated for six projects from three different
perspectives, could these six cases be classified towards their “overall” project complexity?
Based on the interview results presented in this chapter, that is not possible. Several aspects
contributing to project complexity were identified, but it became clear that project
complexity is perceived differently by different professionals involved in the project.
Every person has an own view on project complexity and an own definition of project
complexity - “it is all in the eyes of the beholder”. Such a definition might be colored by
one’s experiences, skills or role in the project under concern. Different perspectives make a
clear definition of project complexity rather difficult, and moreover, also the dynamic
character of project complexity complicates the situation. Over different project phases, the
complexity of the project was shown to change, which should be taken into account when
assessing project complexity.
When project complexity would be determined purely based on the “objective” project
descriptions, using a common measure like “size”, scores would be different. Case 1 would
receive a higher complexity score, but the interviewees did score the project rather low,
which might be related to the many years of experiences of the three interviewees,
combined with the good project atmosphere and very satisfying project result, positively
coloring their thoughts about the project. Case 4 would receive a low complexity score
based on size-complexity, but the experienced interviewees did score the project rather
complex. And case 5 would score rather low on size-complexity, but scored relatively high
in view of the respondents, (despite the contractor / owner split), probably because of the
in-experience in the particular field. Similarly, using just another measure for complexity
like “newness of technology”, case 4 would by score very low (again as opposed to the
opinion of the interviewees) and for example case 2 would also score rather low. Hence by
just taking one measure, without knowing the context, it is seems impossible to assess the
complexity of a project. Looking back at the list of characteristics of complex projects that
were listed in Section 2.7.1 (for example: uncertainty, dynamic interactions, pluralist
environment, irregularity), this is not surprising. Based on the 6 cases, we conclude that the
one and only “overall” project complexity does not exist. Different areas of project
complexity, such as technical complexity, organizational complexity and complexity of the
environment were shown to play a role in determining the project’s complexity: some
projects were more complex in the organizational aspects, the others more in the
environmental and/or technical aspects.
In order to classify projects towards their complexity, an extensive framework would be

required consisting of several aspects, all contributing to project complexity. With such a
framework, the problem of different perspectives is not overcome, but how the different
perspectives relate to the role of people within a project could be investigated in more
detail. The work experience of participants should be taken into account in such
investigations.
3.8.4 Dealing with project complexity in the front-end phase

Project complexity was often underestimated or not well recognized in the front-end phase
in the studied cases. In case project complexity was not recognized, the front-end phase
could not be adapted to the particular complexity. Still, interviewees did see the value of the
front-end phase, particularly in stimulating integrated teams, preventing scope changes and
enabling straight forward implementation. The benefit of using a “fit for purpose scaling”
75
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 Case nr
Prevent late scope changes 1, 2, 3, 4
Influence of project manager on human resourcing 1, 2, 3, 6
Continuity of the team 1, 2, 4
Contract type and consequences 1, 2, 5
Integrated project team 1, 2, 6
Interaction between project manager and steering committee 1, 3, 6
Social team building activities 1, 5
Project meetings 1, 5
Interaction between project manager and (sub)contractors 1, 5, 6
Avoid late entry of parties 2
Selection of project manager 2, 3, 4, 6
Presence of necessary disciplines 2, 4
Active monitoring of risks throughout the project (risk register) 2, 5
Alignment of project goals 3, 4, 6
Active monitoring of project goals 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):

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 well-
educated 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.
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 project’s 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 project’s 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 project’s 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):
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.
4.1 Research approach

An inductive research strategy was chosen to answer the research questions (Blaikie,
2009). This chapter aims to synthesize the existing theoretical and empirical work in this
area with new empirical work. It does not aim to test certain theories, which would require
a deductive approach. Rather, it aims to establish a detailed description of project
complexity, hence using an inductive approach.
First, a literature survey was performed in which elements were gathered that are assumed
to contribute to project complexity (see also Chapter 2). Next, case studies were performed
in which elements, contributing to project complexity, were identified from eighteen
interviews about six different projects in the process engineering industry (see also Chapter
3). On purpose, the interviewees were not aware of the literature study results while being
interviewed, hence strengthening the empirical evidence (Yin, 2002). The results from the
literature search and the case studies were then used to develop, building on existing work,
a detailed framework to grasp project complexity in large engineering projects. A detailed
framework was aimed for because of its foreseen future application for tailored project
management. Different types of projects require a different management approach
(Shenhar, 2001), and, using the complexity framework, the management of the project
could be made contingent upon the specific complexities in the project.
4.2 Project complexity elements from literature

The starting point in the development of the framework was a literature review. A
literature review was performed, followed by the identification of elements that are
suggested to contribute to project complexity according to the current project management
literature.
4.2.1 Gathering elements from literature

Several literature sources, including the ones mentioned in Section 2.7, were used to
identify the elements that contribute to project complexity from a literature perspective.
Literature databases were first searched for relevant articles with the keyword ‘project
complexity’ (date of appearance was 1996 or later). Those articles were studied including
the referenced articles. The process was stopped once no new relevant referenced articles
were found. Elements contributing to project complexity were listed and compared to
identify the key elements. In total 40 elements contributing to project complexity resulted
from the literature search (see Table 4.1). The referred articles in Table 4.1 cover the most
relevant literature about project complexity.
80
Chapter 4: Grasping project complexity: the TOE framework
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
(Müller & 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 project’s complexity. As indicated earlier, next to technical aspects,
particularly organizational and environmental aspects play an important role.
81
Table 4.1: Elements contributing to project complexity from literature sources

(40 elements in total)
Elements from Authors Elements defined,
literature alphabetically ordered
Degree of definition of (Crawford, 2005; Geraldi & Adlbrecht, Clarity of goals
goal, scope 2007; Vidal & Marle, 2008)
Company internal politics (Geraldi & Adlbrecht, 2007) Company internal support
(ambiguity, hidden
information)
Variety of project (Vidal & Marle, 2008) Compatibility of project
management methods management methods and
and tools applied tools
Form of contract (Müller & Turner, 2007; Geraldi & Contract types
Adlbrecht, 2007)
Partner’s transparency, (Geraldi & Adlbrecht, 2007) Co-operation JV partner
empathy (the personal
and intangible matter that
improves co-operation)
Interrelatedness/ (Williams, 1999; Geraldi & Adlbrecht, Dependencies between tasks
interdependence of 2007; Vidal & Marle, 2008)
elements
Dependency on other (Williams, 1999; Geraldi & Adlbrecht, Dependencies on other
departments, companies 2007) stakeholders
Commercial newness of (Geraldi and Adlbrecht, 2007) Experience with parties
the project (new partners, involved
team, processes etc.)
Knowledge (i.e. (Baccarini, 1996) Experience with technology
Education and/or
training)
Multi-objectives, with (Thompson, 1967; Baccarini, 1996; Goal alignment
conflicting goals Williams, 1999; Geraldi & Adlbrecht,
2007; Vidal & Marle, 2008)
Impact of a change in one (Tatikonda & Rosenthal, 2000; Vidal & Interrelations between
production process on Marle, 2008) technical processes
other production
processes
Competition (Vidal & Marle, 2008) Level of competition
Technological newness (Dewar & Hage, 1978; Tatikonda, 1999; Newness of technology
of the project Shenhar & Dvir, 2004; Geraldi & (world-wide)
Adlbrecht, 2007; Vidal & Marle, 2008)
Number of different (Baccarini, 1996; Williams, 1999; Geraldi Number of different
disciplines & Adlbrecht, 2007; Vidal & Marle, 2008) disciplines
Number of different (Geraldi & Adlbrecht, 2007) Number of different
languages languages
Number of different (Geraldi & Adlbrecht, 2007; Vidal & Number of different
cultures Marle, 2008) nationalities
Number of different (Geraldi & Adlbrecht, 2007; Vidal & Number of different norms
norms and standards Marle, 2008) and standards
Variety of financial (Vidal & Marle, 2008) Number of financial
resources resources
Variety of goals (Geraldi & Adlbrecht, 2007) Number of goals
Differentiation by (Miller, 1973; Hall, 1979; Müller & Number of locations
territory Turner 2007; Vidal & Marle, 2008)
Number of partners, (Ashby, 1957; Baccarini, 1996; Williams, Number of stakeholders
contractors, suppliers 1999; Geraldi & Adlbrecht, 2007; Vidal
& Marle, 2008)
Number of activities (Vidal & Marle, 2008) Number of tasks
82
Elements from Authors Elements defined,

literature alphabetically ordered
Differentiation by time (Dewar & Hage, 1978; Baccarini, 1996); Overlapping office hours
(i.e. involved at different
times during a project )
Influence of politics (Geraldi & Adlbrecht, 2007) Political influence
Scheduling (Thomas & Mengel, 2008) Project drive
Project duration (Xia & Lee, 2005; Vidal & Marle, 2008) Project duration
Configuration of macro- (Geraldi & Adlbrecht, 2007) Required local content
organization (local
stakeholders)
Skills (Baccarini, 1996; Thomas & Mengel Resource & Skills availability
2008; Vidal & Marle, 2008)
Risk management (Williams, 2002) Risk management
Number of deliverables, (Geraldi & Adlbrecht, 2007; Vidal & Scope largeness
largeness of scope Marle, 2008)
(number of components
etc.), number of decisions
to be made, Quantity of
information to analyze
Size of the project (in (Weaver, 1948; Williams, 2002; Geraldi Size in capital expenditure
budget) & Adlbrecht 2007; Müller & Turner,
2007; Thomas & Mengel, 2008; Vidal &
Marle, 2008)
Size of the project (in (Weaver, 1948; Williams, 2002; Geraldi Size in Engineering hours
number of people) & Adlbrecht, 2007; Müller & Turner
2007; Thomas & Mengel 2008; Vidal &
Marle, 2008)
Number of project (Williams, 1999; Xia & Lee, 2005; Vidal Size of project team
members & Marle, 2008)
Frequency and impact of (Geraldi & Adlbrecht, 2007) Stability project environment
changes in macro-
organization (suppliers,
contract, raw material
pricing, exchange rates)
Client transparency, (Geraldi & Adlbrecht, 2007) Trust in contractor
empathy (the personal
Team transparency, (Geraldi & Adlbrecht 2007; Vidal & Trust in project team
empathy (the personal Marle, 2008)
Frequency and impact of (Geraldi & Adlbrecht, 2007) Uncertainties in scope
changes in technological
aspects (quality, velocity
etc.), dynamism (i.e.
changing information,
specifications, change
order etc.)
Degree of definition of (Crawford, 2005; Geraldi & Adlbrecht, Uncertainty in methods
methods 2007; Vidal & Marle, 2008)
Variety of perspectives (Geraldi & Adlbrecht, 2007; Vidal and Variety of stakeholders'
Marle, 2008) perspectives
Variety of tasks (Williams, 1999) Variety of tasks
83
De Bruijn et al. already distinguished three dimensions of complexity: technical

complexity, social complexity and organizational complexity (de Bruijn et al., 1996).
Further developing their work and work of others (Jaafari, 2003; Mason, 2007; Xia & Lee,
2005), a framework consisting of technical, organizational and environmental elements
contributing to project complexity is proposed to cover the different aspects of project
complexity in large engineering projects. The traditional technical view is mainly focused
on the technical content of the project (T), the organizational view (O) includes the
organizational and softer (people) aspects and the environmental view (E) includes the
influence from environment.
In the distinction of the T, O and E categories, in fact a systems perspective and an actor
perspective can be recognized. The systems perspective is recognized particularly in the
technical dimension and the actor perspective in the organizational and environmental
(external organizational) dimensions. Describing system and actor perspectives on
sociotechnical systems, De Bruijn and Herder argue that “these perspectives are
“competing” perspectives which must be used alongside each other” (de Bruijn & Herder,
2009), p. 991. Considering projects as sociotechnical systems, we could distinguish a
system perspective (“a technical-rational perspective”), p. 981 and an actor perspective
(“actors as intentional agents”), p.981 on the complexity of the project, not with the aim to
integrate these perspectives, but with the aim to grasp project complexity from all areas.
Hence, in developing a framework to grasp project complexity, all elements found are
assigned to either the technical, organizational or environmental category (see Table 4.4 on
page 88).
4.3 Project complexity elements from case studies

Subsequently, the information from the case studies was used to identify aspects in the
projects that had contributed to the project complexity from the perspective of project
management practice. Because of the exploratory character of this study, the interviewees
involved in this part of the research, were not aware of the results of the literature survey.
A detailed description of these case studies was already provided in Chapter 3. In the
interviews, the candidates (project manager, team member and an owner representative, for
6 projects) were asked by means of open questions what elements had contributed to the
project complexity of the particular project, from their point of view. To start the interview
and help the further analysis, their interpretation or definition of project complexity was
asked for first.
All transcripts were studied to identify the elements contributing to project complexity. A
matrix was created with the elements contributing to project complexity in rows and the 18
interviews in columns. The results of the interviews were added ‘blindly’ e.g. when filling
the current interview results, the columns with the other interview results were hidden. The
number of ‘new’ elements, raised by the interviewees, reduced considerably after the first
6 interviews (which covered the 6 different projects) and no new elements were raised
after the 14th interview; which indicates data saturation, see Figure 4.1.
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
Table 4.2: Elements (49) contributing to project complexity based on 6 cases, 18

interviews
Mentioned in how Mentioned in how
Elements defined many interviews? many cases?
Experience with technology 17 6
Variety of stakeholders' perspectives 16 6
Number of different PM methods and tools 15 6
Resource & Skills availability 15 6
Number of stakeholders 14 6
Contract types 13 6
Uncertainties in scope 13 5
Experience with parties involved 13 5
Interrelations between technical processes 12 6
Newness of technology (world-wide) 12 6
Trust in contractor 11 6
HSSE issues 11 5
Co-operation JV partner 11 5
Trust in project team 10 5
Political influence 10 5
Company internal support 9 4
Number of different norms and standards 8 5
Number of different nationalities 8 5
Dependencies on other stakeholders 8 5
Level of competition 6 5
Environmental risks 6 4
Technical risks 6 4
Variety of tasks 6 4
Uncertainty in technical methods 6 3
Number of different languages 6 3
Interference with existing site 6 3
Number of tasks 6 3
Goal alignment 5 4
Number of locations 5 4
Scope largeness 5 3
Size of site area 5 3
Internal strategic pressure 5 3
Dependencies between tasks 4 4
Size of project team 4 4
Quality requirements 4 3
Number of financial resources 4 3
Project drive 4 2
Weather conditions 3 3
Remoteness of location 3 3
Organizational risks 3 2
Size in CAPEX 3 2
Number of different disciplines 3 2
Overlapping office hours 3 2
Experience in the country 3 2
Size in Engineering hours 2 2
Union Power 2 2
Required local content 2 1
Clarity of goals 1 1
Stability project environment 1 1
86
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 stakeholder’s 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
project’s 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.
4.4 The TOE framework for project complexity in large

engineering projects
To develop the framework for project complexity in large engineering projects, the
elements list from literature and the elements list from the cases were combined and
reordered. To obtain richness in the framework but to avoid adding “arbitrary” elements,
the following criteria were defined to include an element in the framework:
- Evidence both from literature and practice, in total at least three sources, or,
- Evidence from at least two independent literature sources, or,
- Evidence from at least three interviews, covering at least two cases.
Following the literature review proposal (Section 2.7 and Section 2.10) and the
considerations in Section 4.2.2, the elements were clustered into a framework of technical
complexity, organizational complexity and environmental complexity, called the TOE
framework. On a lower level, the elements were further grouped into subcategories, see
Table 4.3. Most of the subcategories consist of various elements related to the subcategory,
together providing a broader view on that aspect of project complexity.
Table 4.3: Subcategories of TOE

Technical Organizational Environment
Goals Size Stakeholders
Scope Resources Location
Tasks Project team Market conditions
Experience Trust Risk
Risk Risk
87
88
Table 4.4: TOE framework (50 elements in total)
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 project’s 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 that’s fine since the objective of the framework
primarily is a better understanding of project complexity and getting a footprint of the
project’s 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
4.5 Discussing the framework

Traditionally, size is seen as the dominant (but criticized!) measure of project complexity
(Williams, 2002). In our study, few interviewees mentioned the traditional size (in terms of
engineering hours or capital expenditure) as contributing to project complexity, despite the
fact that four of the projects under investigation had a capital expenditure over US$ 200
Million. Much more often, size related aspects like “number of different project
management methods and tools” and “number of stakeholders” were mentioned, hence
suggesting the need for refinement of the general aspect ‘size’ as contributing to project
complexity. This supports the overall idea of this research to develop a detailed framework
to grasp project complexity in large engineering projects.
The TOE framework contains many elements related to structural complexity and
uncertainty (Section 2.7.2, page 35). Both technological complexity and organizational
complexity, as mentioned by (Williams, 1999) are explicitly included in the broader
technical complexity and organizational complexity as main categories of project
complexity. The majority of the elements in the technical category of the framework have
a structural character, like the number of goals, largeness of scope, number of tasks,
dependencies between tasks, etc. Also uncertainties in goals and methods are covered in
the elements from the technical category. Some structural elements are recognized in the
organizational category such as the number of project management methods and tools, the
number of different disciplines. Further, the stakeholders’ multiplicity and multi-
objectivity is covered in elements like goal alignment (technical category), the number of
stakeholders and the variety of stakeholders’ perspectives (environmental category).
In the TOE framework, softer aspects and environment (Section 2.7.2, page 35) are
explicitly included. Softer aspects can be recognized in both the organizational category
and the environmental category in elements of the TOE framework such as trust,
availability of resources and skills, experience with parties involved, interfaces between
disciplines involved etc. The environmental category further covers elements such as
political influence, level of competition, strategic pressure, required local content,
interference with existing site, weather conditions, etc.
In the TOE framework, risk (Section 2.7.3, page 37) is considered as a contributor to
project complexity. To address the importance of risk as contributor to project complexity,
the TOE framework includes a separate risk element in all three categories being high risk
in either technical, organizational and/or environmental view. Also aspects of risk are
covered in various other elements of all three categories, especially topics concerning
uncertainty but also other like weather conditions, political influence, etc.
Overall, it is concluded that the presented TOE framework fits the current important
literature concepts as described in Section 2.7 and Section 4.2. Moreover, the framework
presents an “integrative” list of elements that contribute to project complexity in large
engineering projects. It integrates the different theoretical concepts as well as the
perspectives from practice.
Maylor et al. published the MODeST dimensions of perceived managerial complexity

(Maylor et al., 2008). Their extensive framework provides a ‘grounded structural model of
managerial complexity’ based on a multistage empirical study in the telecommunications
sector, the defence sector and a regional transport infrastructure provider. They distinguish
the dimensions of “Mission”, “Organization”, “Delivery”, “Stakeholders” and “Team”
91
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.
4.6 Use and further development of the TOE framework

Here we sketch with what application aim the TOE framework was developed. The TOE
framework can be used as a basis to assess the complexity of an engineering project.
Applying the TOE framework for a project gives a footprint of that project in terms of
where the complexity is expected in the project. Application of the TOE framework could
for example support the risk assessment in early project phases. Since project complexity
changes during the project life cycle, use of the framework in various stages of the project
should be considered in order to also grasp the dynamics of project complexity. Careful
selection of the persons involved in the complexity assessment is needed because of the
inherent subjective nature of the assessment. The use of complexity assessment might
“uncover significant challenges of the project” (Geraldi, 2009). The TOE framework could
support such a complexity assessment.
The ultimate goal of the use of the framework is to better adapt the front-end development
steps of projects to the specific complexities using the complexity footprint. A project in
its early stage could be assessed on its expected complexity and specific actions could be
taken. For example, a project in which predominantly technical complexities are expected
might require a different project manager than a project in which predominantly
environmental complexities are expected. Knowing, understanding and characterizing
these complexities by applying the TOE framework early in the project and in subsequent
project phases is assumed to improve the project management.
Based on the footprint, it might be decided to put extra or less effort in process
management, stakeholder management, risk management, etc., following approaches as
suggested for example by Jaafari on risk management (Jaafari, 2001) or Aaltonen et al. on
stakeholder management (Aaltonen, Jaakko, & Tuomas, 2008). In line with current
literature ideas, the project manager could be selected and/or further developed based on
the competences required to manage the particular complexity (Bosch-Rekveldt et al.,
2009b; Remington & Pollack, 2007; Thomas & Mengel, 2008).
Aiming to understand project complexity does not necessarily assume controllability of

project complexity. The authors believe that understanding project complexity should be
decoupled from the “natural” engineering desire of a “predict and control” approach.
Rather, an understanding of project complexity is suggested to support the management of
projects, where management is not exclusively following the “predict and control” strand,
but also includes a more process oriented “prepare and commit” strand (de Bruijn et al.,
2003). Further, understanding project complexity in order to better manage projects is not
automatically focused on reducing project complexity.
Further developments of the TOE framework are foreseen to overcome current research
limitations. The first limitation is the qualitative character of the presented study. In
92
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.
4.7 Conclusion & recommendations

To help managing project complexity, this chapter presented a framework for
characterizing project complexity in large engineering projects, thereby answering research
question 2 from Chapter 1 (How can we characterize project complexity in large
engineering projects?). The TOE framework is based on both literature and empirical data.
Applying the framework for a specific project results in a footprint of its complexity,
providing potential handles to better manage the project. The framework is intended to be
used for assessment of complexity of projects in the process engineering industry. Because
of the dynamics of project complexity, repeated use in different project phases is foreseen.
Using an inductive approach by combining literature insights strengthened with the

elements resulting from the eighteen interviews about the six cases, the TOE framework
enables a broad view on project complexity. In total 50 elements contributing to project
complexity were identified in the following three areas: technical complexity,
organizational complexity and environmental complexity. Deliberately, the number of
elements in the framework was not reduced to be able to describe the richness of project
complexity. To facilitate its use, three levels were defined within the TOE framework;
three categories (TOE), fourteen subcategories (T: goals, scope, tasks, experience, risk; O:
size, resources, project team, trust, risk; E: stakeholders, location, market conditions and
risk) and fifty elements. This offers the opportunity to discuss on various levels with the
different parties and stakeholders involved in a project which aspects make the specific
project complex. The current setup is flexible and allows extension of the framework, for
example if necessary for use in a different industry.
The resulting TOE framework was reflected against current literature concepts and was
shown to integrate the current dominant concepts. Moreover, the concepts were developed
into clear elements in the TOE framework bringing together theoretical perspectives and
perspectives from practice. To overcome current research limitations, completeness of the
framework and repeatability and reproducibility of using the framework will be
investigated by means of quantitative approaches in Phase II and Phase IV (Chapter 6 and
Chapter 9).
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 (high-
level) 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 sub-
95
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
Chapter 5: NAP survey study
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 respondent’s 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.
5.2 Survey design

The questionnaire was developed based on a literature review and transcripts of interviews
performed in Chapter 3 and the TOE complexity framework in Chapter 4. The survey
contained questions related to:
- Company background,
- Respondent background,
- General characteristics of the most recent project,
- The project’s complexity: the perceived complexity (TOE) as well as scoring the
individual TOE elements,
- Front-end activities: which were applied and to what extent,
- Project performance: based on indicators (cost, schedule) and perception (quality),
- Foreseen application of the complexity framework.
All survey questions are listed in Appendix B. The general project characteristics, the
interviewee background and the company background could be used as control variables.
The content of the questions related to project complexity, front-end activities and project
performance is explained in more detail in the subsequent sections.
5.2.1 Identifying the project’s complexity

Based on literature and case studies, a multi-dimensional approach to grasp project
complexity was developed, see Chapter 4. The TOE framework distinguishes three
97
dimensions in project complexity: Technical, Organizational and Environmental

complexity and consists of 50 elements. Survey questions were defined for each of these 50
elements. Appendix C lists how the TOE elements were translated into survey questions.
Separate from the questions evaluating the TOE framework elements, questions were asked
about the respondent’s perception of project complexity in terms of technical complexity,
organizational complexity and environmental complexity. This way we gathered two
opinions of the respondents on the complexity of their project: directly their perceptions
and indirectly via the TOE element scores.
Knowing that project complexity can change throughout the project’s lifecycle (Chapter 3),
the complexity of the project in the project execution phase was asked for. In case we asked
the respondents’ opinion specifically for other project phases, this was made explicit with
statements like “prior to the project” or “before the project started”.
5.2.2 What was done in the front-end phase of the project?

In this part of the survey, we had to operationalize the broad concept of “activities in the
front-end phase” to researchable variables. In Chapter 2, we found the suggested
importance of value improving practices (VIPs). A value improving practice, by others also
called best-practice, can be thought of as “a repeatable technique or methodology that,
through experience and research, has proven to reliably lead to a desired result in a more
effective and efficient way than other practices” (van der Weijde, 2008). Typically, VIPs
are applied in the framework of a stage gated project management process. In order to pass
a stage gate, the results of applying certain VIPs have to be demonstrated by the project
team to a project assurance body.
In the case study described in Chapter 3, project professionals also suggested several
crucial front-end activities (see Table 3.14 on page 76). These activities could be clustered
around five themes: building the project team, project goals and alignment, governance and
organization structure, contracting and risk management. Some of these themes also occur
in the identified value improving practices from literature (see Table 2.6 on page 28). For
this research, we decided to include questions about the front-end activities as suggested in
the case studies, as well as some of the VIPs. We assumed that these aspects would make
the difference and that the “normal” FED practices would be correctly applied.
The IPA VIPs, the CII best practices and the NAP best practices from their publication on
front-end loading (de Groen et al., 2003; Oosterhuis et al., 2008) were clustered and
ordered in Table 5.1. Note that the terminology of “best practices” and “value improving
practices” is used interchangeably in practice.
The IPA Value Improving Practices (IPA, 2009a), are to a large extent technically oriented.
The CII best practices (CII, 2009) seem more management related. The NAP best practices
combine the technical perspective of the IPA VIPs with a more managerial perspective, like
the CII best practices do. Practices that occurred at least twice in Table 5.1 were considered
for inclusion in the research. From these practices, those were selected that were least
focused on technical details and most on project management aspects. The VIP on
partnering / long term agreement was considered outside the scope of the current research.
98
Table 5.1: Overview of VIPs / Best practices and selection for inclusion in this study
Selected for
NAP best practices IPA VIPs CII Best Practices inclusion in this
study?
Constructability review Constructability review Constructability Yes
Technology selection Technology selection Yes
Design-to-capacity Design-to-capacity Yes
Value engineering Value engineering Yes
Integrated project team
Team building Yes
Collaborative engineering
Pre-task planning Planning for start-up
Yes
Pre-project planning
Senior management
Alignment Yes
involvement
Benchmarking and
Benchmarking Yes
metrics
Performance management Quality management Yes
Knowledge management Lessons learned Yes
Process safety management
No, too much
Process simplification Process simplification
focused on
Process reliability modeling Process reliability
technical content,
Process synthesis modeling
not on PM aspects
Process intensification
Zero design
Energy optimization No, too much
Energy optimization
Waste minimization Zero accidents focused on
Facility optimization
Classes of facility Techniques technical content,
Waste minimization
quality not on PM aspects
Classes of plant quality
Standard project
specification
Minimum standards & No, too much
specifications Customizing standards focused on
Standardized work and specifications technical content,
processes not on PM aspects
Customized standards &
specifications
No, too much
focused on
Design tools 3-D CAD
technical content,
not on PM aspects
No, out of research
Long Term Agreement Partnering
scope
Generic engineering No, only one source
Account management and
controlling No, only one source
Communication
SHE review No, only one source
E-commerce No, only one source
Monetary and recognition
No, only one source
awards to individuals
Predictive maintenance No, only one source
Materials management No, only one source
Disputes prevention
and resolution
Change management No, only one source
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 Description
Practice)
Project team A structured process that allows the formation of a “fit−for−purpose scaled”
building project team.
Technology A systematic process to select the best technology options that meet the
selection business objectives and improve competitive advantage.
Analysing the design to ensure that the facilities can be built in a manner
Constructability
that minimizes construction cost while maintaining standards of safety,
review
quality and schedule reduce costs/time.
Evaluating the maximum capacity of each major piece of equipment, action
Design−to−
is taken to reduce unnecessary excess capacity that is identified (scope
capacity
related).
Value A disciplined method used during design aimed at eliminating or modifying
engineering items that do not add value to meeting business needs.
Operations
Up front planning to significantly improve the probability of achieving a
implementation
flawless start-up and processing at the specified levels of availability.
planning
Goal−setting and Identifying the goals and opportunities for the project and aligning these
alignment with the parties involved.
Risk A process that results in the identification and response planning for risks to
management the project.
External A structured process to add value to a project by comparing it relative to

benchmarking projects of similar characteristics carried out by the industry.
Reviewing a project at various steps in its development to understand how a
Project quality
project is progressing and whether approved strategies and required
control
practices are being implemented and producing the expected results.
A structured process for capturing, interrogating, analysing, making
Lessons learned systemic corrections, archiving and implementing lessons learned during the
inception, development and execution of an engineering project.
Stakeholder A structured process identifying and involving all stakeholders of the
management project.
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, today’s 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
Building the team Presence of necessary disciplines
Selection of project manager
Influence of project manager on human resourcing
Alignment of project goals
Goals and alignment Active monitoring of project goals
Late scope changes
Intervention and co-operation between project manager
and steering committee
Governance and organization
Intervention and co-operation between project manager
structure
and (sub)contractors
Project meetings
Contracting Contract type
Active monitoring of risks throughout the project (risk
Risk management
register)
These front-end activities were surveyed in the form of statements to be answered on a 5-

point 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
definition, overrun(s) of up to 10% are considered acceptable. Note that project

performance was also considered good in case of delivering under budget and/or ahead of
schedule. From a resource management point of view, such projects could be considered
unsuccessful since resources were reserved for a project while they could have been used
more effectively elsewhere. Potentially, initial estimates were too conservative for these
projects. However, limiting project success to a project management perspective justifies
the choice of assessing the realized budget / schedule against the agreed estimates and
considering all under-runs as successful. This performance definition was used to make two
groups in the data: projects with good project performance and projects with poor project
performance.
Next to the distinction of the data into these two groups of projects, for each project a
composed project performance variable was calculated by cumulating the scores for quality
performance, schedule performance and cost performance. This newly created interval
variable was used to investigate correlations between project performance and project
complexity / front-end activities.
5.3 Data treatment

5.3.1 Data collection
The target group of the survey consisted of project professionals in companies in the NAP
network. The maximum number of questions to be answered was 82. In practice, this
number could be lower since smart routing was used: some questions were only activated in
case of a positive answer of the respondent. The survey was developed and executed in the
web-based application NetQ (www.netq.nl). The Net-Q data was stored in SPSS
compatible format.
Before the survey was distributed, the potential participants kindly were asked for their
participation, not only by the researchers but also by the director of the NAP network. This
was done to create commitment amongst the respondents and hence improve the response
rate (Porter & Whitcomb, 2007). The survey was available on-line between 12 June 2009
and 9 July 2009. The respondents were sent a reminder on 1 July 2009.
The survey was distributed through the database of the NAP network by e-mail. In total
about 330 project professionals in about 100 member companies were approached. These
project professionals were allowed to forward the survey request to other project
professionals within their company. Progress was saved on the participants’ computer and
measures were taken to prevent double submissions from one participant. No company
name, nor any person’s name was explicitly asked for, but respondents could indicate their
willingness to be involved in subsequent research, which was used in the in-depth research
towards critical front-end activities, described in Chapter 8 of this dissertation. Apart from
the use of the contact details for selecting participants for subsequent research, these
respondent’s details were not used in the analysis.
The survey was started by a total of 107 respondents, 67 of whom finished it entirely. With
67 completed responses, a response rate of about 20% was achieved. For a web survey, this
is above a typically reported response rates of 15% (Porter & Whitcomb, 2007). Why a
considerable number of the survey starters (40 of 107) did not complete the survey can be
explained by looking at the actual time spent to complete the survey, see Figure 5.1.
102
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).
Figure 5.1: Time spent to complete the survey
5.3.2 Data analysis

The data obtained by the survey was analyzed using both descriptive and multivariate
methods in SPSS. Descriptive techniques were used to review the data concerning the
separate variables of the research (project complexity, front-end development and project
performance), while the relationships between them were tested using multivariate
techniques. The majority of the questions were asked by means of 5-point Likert scale
questions. Data obtained from such questions is generally assumed to be suitable for use in
multivariate techniques as interval variables (Jaccard & Wan, 1996; Kim, 1975; Labovitz,
1967). Since the data merely consisted of non-normally distributed variables, Spearman’s
rho correlation was used (Field, 2009). The use of Spearman’s rho (or rank) correlation was
preferred over Pearson’s correlation anyway because the latter assumes equidistance of the
interval variables, which is under on-going scientific debate for 5-point Likert scales
(Dawes, 2008). Also, Spearman’s correlation is said to be of wider validity and less
vulnerable to outliers (Altman, 1991).
The presence of a correlation between two variables does never give an indication of the
direction of the causality (Field, 2009). Only in case there are other reasons to assume a
causality direction, for example time evidence, one could conclude about the direction of
the calculated correlation. Still, one should be careful with drawing such conclusions since
third variables, not included in the research, could have had an even stronger effect. For
example, we did not include the influence of the project manager’s performance in our
current research, although this also has an influence on the project’s performance.
103
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 front-
end 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.
5.4 General survey results

This section briefly presents the general survey results that are relevant for the data
interpretation in the subsequent chapters. First several characteristics of the respondents are
analyzed, followed by a characterization of the projects under investigation. Next the
project driver(s) and the project performance is presented.
5.4.1 The respondents

The vast majority of the respondents were male (63 out of 67), only 4 female respondents
completed the survey. The study background of the respondents predominantly was in
engineering or science (62 out of 67), the others had a business related background.
Regarding their education level, except for 2 respondents, all obtained at least a Bachelor’s
degree. The majority of the respondents obtained a Master’s degree (44 out of 67).
The respondents did have a lot of working experience, see Figure 5.2: only 10 respondents
worked shorter than 15 years, the others (57 respondents) worked more than 15 years of
which 27 respondents work even longer than 25 years. Their project management
experience generally was less. Six respondents did not have experience as a project
manager and also 6 respondents had less than 5 year experience as a project manager. The
largest group (23 respondents) had between 5 and 10 years of project management
experience. Ten respondents had between 10 and 15 year project management experience
and 16 respondents had between 15 and 20 year project management experience. Finally,
six respondents had between 20 and 25 year of project management experience.
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 company’s 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
Figure 5.3: Project drivers: quality, schedule, cost
The most frequently mentioned other project driver was “safety”, which could be expected
in the sector under investigation in which safety plays an important role (Bakker et al.,
2010). In case safety was mentioned (14 projects), the project was driven completely by
safety in the vast majority of the projects involved (10 projects), which again shows the
importance of safety in this sector.
5.4.4 Project performance

The data (67 projects) contained 20 projects with good project performance and 34 projects
with poor project performance. Following the definition of Section 5.2.3, the project had to
be delivered within 10% budget overrun, within 10% schedule overrun and with sufficient
quality to belong to the group of projects with good project performance. Translating this to
the survey data, this meant that scores of 3 and higher represent a successful outcome on
that performance indicator. To obtain these comparable measures, we recoded the data. In
the recoded data, the maximum score for meeting cost and schedule estimate was 6 (each)
and the maximum score for (perceived) quality was 5, cumulating to a maximum
performance score of 17.
For 13 projects, data was missing regarding budget, schedule and/or quality. How these
projects performed thus could not be assessed. Figure 5.4 shows the cumulative
performance scores for the 54 cases of which the data was available. Note: projects with a
cumulative score of 9 and higher are only successful in case all of the three indicators
scoring 3 or higher. One could argue that for those projects without quality or cost driver
(see Figure 5.3) performance in that aspect is not relevant, but these projects were amongst
the cases for which no performance scores were available.
The higher the performance score, the better the project had performed. The number of
cases against the performance scores for cost, schedule and quality as well as their
cumulative score is given in Figure 5.5. Generally, it seems that the schedule performance
was least successful and the quality performance was most successful. In the current project
sample, following our previously mentioned project performance definition, the projects
under investigation have a success rate of 20/54 = 37%.
106
Figure 5.4: Cumulative score for project performance (N=54)
Figure 5.5: Number of cases against performance scores (N=54)

Left panel: Cost, schedule and quality scores. Right panel: cumulative scores.
Now we have presented the survey setup and some general findings in Chapter 5, Chapter 6
presents the in-depth evaluation of the TOE complexity framework as well as the relations
between complexity elements and project performance. Subsequently, Chapter 7 evaluates
the front-end activities, the relations between front-end activities and project performance,
and how project complexity plays a role in these relations.
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):

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
6.1 Analysis of survey data

The survey response data contained 67 completed surveys. This sample size is considered
sufficient to do exploratory analysis (Field, 2009). For firm quantitative conclusions, more
data would be required. Based on an exploratory scatter plot analysis, it was concluded that
the 67 surveys contained no outlier cases: none of the cases scored systematically very
different than the rest. Hence all 67 responses were included in the overall analysis. We
were interested in correlations between different variables, e.g. between elements of the
TOE complexity framework, project performance and perceptions of complexity. Since the
data contained non-normally distributed variables, Spearman’s rho correlation was used.
The following “classification” for the correlation strength was used (Cohen & Holliday,
1982):
- to 0.2: very weak to negligible correlation,
- 0.2 to 0.4: weak, low correlation,
- 0.4 to 0.7: moderate correlation,
- 0.7 to 0.9: strong, high correlation,
- 0.9 to 1.0: very strong correlation.
For analysis purposes, the definition of the complexity framework elements was such that a
high score always meant a higher contribution to project complexity, which was not always
clear from the element names itself. The following element names were therefore changed:
- Clarity of goals => unclear goals,
- Goal alignment => unaligned goals,
- Experience with technology => lack of experience with technology,
- Resource and skills availability => resource and skills scarcity,
- HSSE awareness => lack of HSSE awareness
- Experience with parties involved=> lack of experience with parties involved,
- Trust in the project team => lack of trust in the project team,
- Trust in the contractor => lack of trust in the contractor,
- Company internal support => lack of company internal support,
- Experience in the country => lack of experience in the country,
- Stability of project environment => unstable project environment.
From here onwards, these new names are used.
6.2 Correlations between project complexity and project

performance
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
Chapter 6: Evaluating project complexity
Table 6.1: Significant correlations between project performance and project

complexity
Correlation
Meaning of
Var1 Var2 strength Sign.(p) N
correlation
(rs)
Increased technical
Technical
-.401** .003 54 complexity decreases
complexity
project performance
Increased
Project Organizational organizational
-.308* .023 54
performance complexity complexity decreases
project performance
Increased external
Environmental
-.221 .109 54 complexity decreases
complexity
project performance
*significant at 0.05 level, ** significant at 0.01 level
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
Table 6.2: Significant correlations between project performance and project

complexity elements
Correlation
Var1 Var2 Sign.(p) N Meaning of correlation
strength (rs)
TG2: unaligned Unaligned goals decrease
-.492** .000 53
goals project performance
TG3: unclear Unclear goals decrease
-.355** .008 54
goals project performance
TS2: Uncertainties in scope
uncertainties in -.287* .037 53 decrease project
scope performance
TT4: Uncertainty in methods
uncertainty in -.276* .044 54 decreases project
methods performance
OS2: Compatibility problems
incompatibility in PM methods / tools
Project -.367** .007 53
of different PM decrease project
performance
methods / tools performance
ORE2: Resources and skills
resources and -.292* .032 54 scarcity decreases project
skills scarcity performance
ORE5:
Interface problems
interfaces
between different
between -.325* .016 54
disciplines decrease
different
project performance
disciplines
ES5: lack of The lack of company
company -.287* .036 54 internal support decreases
internal support project performance
*Correlation is significant at 0.05 level (2-tailed)
** Correlation is significant at 0.01 level (2-tailed)
6.3 Correlations between element scores and perceived

complexity
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
25
consider it technically complex
20
Count

15 consider it organizationally complex
10
consider it environmentally complex
5
0
Strongly Disagree Neutral Agree Stronly Agree
disagree
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 Perceived Perceived
technical organizational environmental
complexity complexity complexity
Perceived Correlation Coefficient 1.000 .320** .190
technical Sig. (2-tailed) .008 .126
complexity N 67 67 66
Perceived Correlation Coefficient 1.000 .287*
organizational Sig. (2-tailed) .020
complexity N 67 66
Perceived Correlation Coefficient 1.000
environmental Sig. (2-tailed)
complexity N 66
** Correlation is significant at the 0.01 level (2-tailed)
* Correlation is significant at the 0.05 level (2-tailed)
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 project’s
complexity:
- project size,
- role of the respondent in the project,
- respondent’s 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 Spearman’s 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
Table 6.4: Spearman correlations between

factors endangering achieving project objectives and perceived complexity
Please indicate which of the following factors Perceived Perceived Perceived
significantly endangered achieving the project technical organizational environmental
objectives (more than one answer possible): complexity complexity complexity
- Project goal(s) issues, rs .349** .413** .128
causing complexity in the Sig. (2-tailed) .004 .001 .306
project N 67 67 66
- Project scope issues, rs .230† .180 .081
project N 67 67 66
- Project task(s) issues, rs -.035 -.017 .003
project N 67 67 66
- Technical experience issues, rs .371** .119 .137
project N 67 67 66
rs .479** .312* .087
- Technical risks, causing
Sig. (2-tailed) .000 .010 .485
complexity in the project
N 67 67 66
rs .048 -.001 -.128
- Project size issues, causing
Sig. (2-tailed) .702 .991 .307
N 67 67 66
rs .023 .232† -.033
- Resource issues, causing
Sig. (2-tailed) .856 .059 .794
N 67 67 66
rs .032 .238† .169
- Project team issues, causing
Sig. (2-tailed) .799 .052 .174
N 67 67 66
- Organizational risks, rs -.090 .312* .172
project N 67 67 66
rs .095 .218† .242†
- Trust issues, causing
Sig. (2-tailed) .444 .076 .051
N 67 67 66
rs -.183 .108 .016
- Stakeholder issues, causing
Sig. (2-tailed) .139 .384 .896
N 67 67 66
- Project location issues, rs .017 .143 .074
project N 67 67 66
rs .034 .288* .237†
- Market conditions, causing
Sig. (2-tailed) .787 .018 .055
N 67 67 66
- Environmental risks, rs .026 -.066 .347**
project N 67 67 66
† Correlation is significant at the 0.1 level (2-tailed)
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, Spearman’s 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 element’s 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 respondent’s
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 in-
depth 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. Did the element show meaningful correlations to other elements in the framework?
3. 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?
4. Could problematic results be related to the current formulation of the survey
question?
5. Could problematic results be related to the current project sample?
6. 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 Spearman’s
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
Table 6.5: Correlation results T-elements

Meaningful
Correlation
correlations
Sub- with
ID Elements defined with other Conclusion
ordering perceived
TOE
complexity?
elements?
Goals TG1 Number of goals T† No Use data
Goals TG2 Unaligned goals O** Yes Use data
Goals TG3 Unclear goals O† Yes Use data
Do not use
Scope TS1 Scope largeness - One data, remove
element
Scope TS2 Uncertainties in scope O† Yes Use data
Scope TS3 Quality requirements T**, E† Yes Use data
Do not use
Tasks TT1 Number of tasks - Yes
data
Do not use
Tasks TT2 Variety of tasks - No
data
Dependencies
Tasks TT3 T† No Use data
between tasks
Uncertainty in
Tasks TT4 T* Yes Use data
methods
Interrelations between Do not use

Tasks TT5 - No
technical processes data
Conflicting norms and

Tasks TT6 O* Yes Use data
standards
Newness of
Experience TE1 technology (world- T†, O† Yes Use data
wide)
Lack of experience
Experience TE2 - Yes Use data
with technology
Risk TR1 Technical risks T**, O* Yes Use data
†
Correlation is significant at the 0.1 level (2-tailed)
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 work-
packages 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
removed from the framework. All details can be found in Appendix D.2
119
Table 6.6: Correlation results O-elements

Correlation Meaningful
with correlations
Sub- perceived with other
ordering ID Elements defined complexity? TOE elements? Conclusion
Use data,
Size OS1 Project duration T† Yes move to T-
category
Incompatibility of
different project
Size OS2 O**, E* Yes Use data
management methods
and tools
Use data,
Size OS3 Size in CAPEX - Yes move to T-
category
Do not use
Size in Engineering
Size OS4 - Yes data, remove
hours
element
Size OS5 Size of project team O* Yes Use data
Do not use
Size OS6 Size of site area - Yes data, remove
element
Use data,
Size OS7 Number of locations O† Yes move to T-
category
Use schedule
Resources ORE1 Project drive O†, E* Yes
drive data
Resource & Skills
Resources ORE2 O** Yes Use data
scarcity
Lack of experience
Resources ORE3 - Some Use data
with parties involved
Lack of HSSE
Resources ORE4 O† Yes Use data
awareness
Interfaces between
Resources ORE5 O**, T* Yes Use data
different disciplines
Number of financial
Resources ORE6 - Some Use data
resources
Resources ORE7 Contract types - Some Use data
Project Number of different
OP1 - Yes Use data
team nationalities
Project Number of different
OP2 O* Some Use data
team languages
Project Presence of JV
OP3 E† Yes Use data
team partner
Project Overlapping office Do not use
OP4 - No
team hours data
Lack of trust in
Trust OT1 - Yes Use data
project team
Lack of trust in
Trust OT2 - Yes Use data
contractor
Risk OR1 Organizational risks O** Yes Use data
†
120
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 O-
elements. 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 stakeholder’s 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
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 E-
subcategories 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.
Let’s investigate this in some more detail.
122
Table 6.7: Correlation results E-elements

Meaningful
Correlation
correlations
with
Sub-ordering ID Elements defined with other Conclusion
perceived
TOE
complexity?
elements?
Number of
Stakeholders ES1 O† Yes Use data
stakeholders
Variety of
Stakeholders ES2 stakeholders' O** Yes Use data
perspectives
Dependencies on
Stakeholders ES3 T*, O** Yes Use data
other stakeholders
Stakeholders ES4 Political influence T* (neg) Yes Use data
Lack of company
Stakeholders ES5 - Yes Use data
internal support
Required local
Stakeholders ES6 - Some Use data
content
Interference with
Location EL1 O† Yes Use data
existing site
Location EL2 Weather conditions - Yes Use data
Remoteness of
Location EL3 - Yes Use data
location
Lack of experience
Location EL4 O† Yes Use data
in the country
Market Internal strategic Do not use
EM1 - No
conditions pressure data
Market Instability project
EM2 O†, E† Yes Use data
conditions environment
Market
EM3 Level of competition - Yes Use data
conditions
Risks from
Risk ER1 E** No Use data
environment
†
None of the stakeholder elements (number of stakeholders, variety of stakeholders’

perspectives, dependencies on other stakeholders, political influence, lack of company
internal support, required local content) show a significant correlation to perceived
environmental complexity, but 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
123
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 project’s 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
With the E-category, Environmental complexity, we intended to refer to the organizational

issues with an external cause. However, often environmental seemed to be interpreted in a
“green” way (e.g. environmental protection). In order to avoid further confusion the new
category name is External. This category contains those elements of the external
organization that cannot directly be influenced, as well as other external factors or the
surrounding of the project that contribute to the external complexity of the project.
Despite the (strong) correlations with perceived organizational complexity, the stakeholder
elements are not moved to the O-category. Rather, it is emphasised that the stakeholder
elements related to the stakeholders externally to the project team. Complexity related to
the stakeholders in the project team internally is assumed to be covered by the elements
presence of JV partner, lack of experience with the parties involved, size of the project
team, lack of trust in the project team.
The respondents were not asked to rank the complexity elements amongst each other.
Looking at the results of Table 6.5 to Table 6.7, the correlations with the highest
significance level indicate which of the elements are more relevant than others, in view of
the practitioners. Or in other words, which of the elements are best recognised by the
practitioners. Specifically the risk elements show highly significant correlations to the
different forms of perceived complexity respectively, indicating that the practitioners
indeed recognised the link between risks and complexity of the project. This also yields for
TOE elements that relate to the involvement of different parties, such as the elements
dependencies on other stakeholders, the variety of stakeholders’ perspectives and interfaces
between different disciplines. Highly significant with perceived complexity were also the
correlations of the elements incompatibility of different pm methods and tools, resource and
skills scarcity and unaligned goals. Incompatible PM methods and tools, difficulties in the
availability of required resources and skills and non-alignment of project goals coincided
with higher perceived organizational complexity. Further, perceived technical complexity
highly and significantly correlated to high quality requirements, e.g. high quality
requirements in a project coincide with higher technical complexity. Although the elements
mentioned in this paragraph are best recognised by the practitioners (or better formulated;
their implications on the project’s complexity), it would be unwise to leave the other
elements unattended.
Suggested changes to the TOE framework, as initially developed in Chapter 4, are listed as
follows (see Table 6.8). From the T-category, one element could be removed from the TOE
framework (scope largeness). The corresponding survey questions of several elements need
reformulation for future use:
- uncertainties in scope,
- number of tasks,
- variety of tasks,
- dependencies between tasks,
- interrelations between technical processes,
- lack of experience with technology.
125
Table 6.8: TOE with proposed adaptations

(Italic elements should not be included in further analysis of survey results, but elements should
stay in the framework. Strikethrough elements should be removed from the framework.)
Corr.
TOE New sub-ordering ID Elements defined
result
T Goals TG1 Number of goals T†
T Goals TG2 Unaligned goals O**
T Goals TG3 Unclear goals O†
T Scope TS2 Uncertainties in scope O†
T Scope TS3 Quality requirements T**, E†
O Scope OS1 Project duration T†
O Scope OS3 Size in CAPEX -
O Scope OS7 Number of locations O†
T Scope TE1 Newness of technology (world-wide) T†, O†
T Tasks TT1 Number of tasks -
T Tasks TT2 Variety of tasks -
T Tasks TT3 Dependencies between tasks T†
T Tasks TT4 Uncertainty in methods T*
T Tasks TT5 Interrelations between technical processes -
T Tasks TT6 Conflicting norms and standards O*
T Tasks TE2 Lack of experience with technology -
T Risk TR1 Technical risks T**, O*
O Resources ORE1 Project schedule drive O†, E*
O Resources ORE2 Resource & Skills scarcity O**
O Resources ORE3 Lack of experience with parties involved -
O Resources ORE4 Lack of HSSE awareness O†
O Resources ORE5 Interfaces between different disciplines O**, T*
O Resources ORE6 Number of financial resources -
O Resources ORE7 Number of contracts -
O Project team OP1 Number of different nationalities -
O Project team OP2 Number of different languages O*
O Project team OP3 Presence of JV partner E†
O Project team OP4 Overlapping office hours -
O Project team OS5 Size of project team O*
Incompatibility of different project management
O Project team OS2 O**, E*
methods and tools
O Project team OT1 Lack of trust in project team -
O Project team OT2 Lack of trust in contractor -
O Risk OR1 Organizational risks O**
E Stakeholders ES1 Number of external stakeholders O†
E Stakeholders ES2 Variety of external stakeholders' perspectives O**
E Stakeholders ES3 Dependencies on external stakeholders T*, O**
E Stakeholders ES4 Political influence T* (neg)
E Stakeholders ES5 Lack of company internal support -
E Stakeholders ES6 Required local content -
E Location EL1 Interference with existing site O†
E Location EL2 Weather conditions -
E Location EL3 Remoteness of location -
E Location EL4 Lack of experience in the country O†
E Market conditions EM1 Internal strategic pressure -
E Market conditions EM2 Instability project environment O†, E†
E Market conditions EM3 Level of competition -
E Risk ER1 Risks from environment E**
T Scope TS1 Scope largeness -
O Size OS4 Size in Engineering hours -
O Size OS6 Size of site area -
†
126
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.
6.4 Completeness of the TOE framework

To evaluate the completeness of the TOE framework, the NAP survey contained one open
question asking about the most complex element in the project and one open question
asking about what is lacking in the TOE framework. These answers contribute to a
“completeness check” of the framework in its current version.
6.4.1 Most complex element(s) in the project

Respondents were asked to look back at the project under consideration and to indicate
what the most complex element in their project was. Their answers (Table 6.9) were
analyzed and, where possible, attributed to a related TOE element by the author. Four
respondents indicated that the project was not complex and hence they could not mention
the most complex element. Some of the respondents indicated there was more than one
most complex element. The vast majority of the most complex elements could directly be
related to the current TOE elements.
Amongst the most complex elements that could not directly be related to the current TOE
elements, (the behavior of) the client was mentioned most often (five times). Interaction
with the client is inherently related to doing business, hence performing projects and
literature also suggests the importance of the client role in projects (Bryde, 2008).
However, mentioning the client as the most complex element in the project suggests an “it
is not our fault” attitude: the client is the party outside one’s control cycle, and therefore
easy to blame. In the TOE element lack of experience with parties involved, implicitly part
of the client characteristics are covered.
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 stakeholder’s 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.
6.5 Applying a TOE-like framework

The NAP survey also included several questions related to the application of a framework
to assess project complexity. It is realised that responses about the potential use of a tool or
system are by definition positively biased: most likely the respondents were too positive in
their response. That they indicated they plan to use a tool or system does not guarantee they
will do when it is available. However, if practitioners do not support any application
beforehand, it is unlikely they will support it once it becomes available. Therefore a
positive response on potential use of a complexity framework is a necessary (but not
sufficient!) condition for potential future application.
In the survey, a few questions were related to application of the complexity framework for
the respondent’s project for which they filled in the complete survey. Only a few
respondents disagreed with statements about the possibility to identify complexity elements
in their project using the framework or supporting their project management, see Figure
6.2. The vast majority of the respondents is neutral or agreed that the complexity
framework could have helped them in their current project.
131
35
A framework to assess the complexity of
30 a project could have helped me identifying
potential complexity elements in this
25
project
20
Count
A framework to assess the complexity of

15 a project could have helped me to
manage this project
10
5 If it would be available, I would use a
framework to assess the complexity of
0
my next project
disagree
Figure 6.2: Answers related to application of a complexity framework
Figure 6.2 also shows that the majority of respondents would use a complexity framework
in their next project, if it would be available. So for applying a complexity framework in
their next project, they were clearly more positive.
Why would the respondents use a framework to assess the complexity of their next project?
They clearly saw the benefit of applying such framework: the majority of the respondents
agreed or strongly agreed that using a framework is likely to be beneficial for the project
outcome, see Figure 6.3. The intended use of the complexity framework, amongst others, is
foreseen in creating awareness about the complexity of the project amongst the different
stakeholders in the project. As shown in Figure 6.3 this was, again, predominantly agreed
by the respondents. Only one respondent disagreed, the vast majority agreed or even
strongly agreed that using a complexity framework can create awareness about the project
complexity amongst the different stakeholders.
40
35 In general, using a framework to assess
30 the complexity of a project is likely to be
beneficial for the project outcome
25
Count
20
15
10 In general, a framework to assess the
5 complexity of a project can create
awareness about the project complexity
0 amongst the different stakeholders
disagree
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 In general, it would be beneficial to apply
30 a framework to assess the complexity of
a project in different project phases
25
Count
20
15
10 In general, a framework to assess the
5 complexity of a project can be applied
only in early project phases (prior to
0 project execution)
disagree
Figure 6.4: Use of the complexity framework in different project phases
Summarizing these findings about application of a complexity framework, it is concluded

that the majority of the respondents supported our intentions of the framework:
- To support project management, beneficially contributing to project performance.
- To create awareness amongst the involved stakeholders.
- To be used during different project phases, starting in the early FED phase, but
continuing during project execution.
With these intentions, actual use of a complexity framework as a self-assessment tool in
early project phases could be thought of. The framework should enable to score all
elements on an equal scale, for example 1 (no complexity contribution) to 5 (most severe
complexity contribution). All elements could be scored for a project in its early phase
(repeated for all next phases), hence creating a complexity “footprint” of the project. Based
on such footprint, decisions could be taken about managing the specific project
complexities. By gathering (anonymous) complexity footprints, a database of reference
projects could be created which could be consulted before deciding about how to manage
the specific complexities.
6.6 Aggregated scores for T, O and E complexity

Thus far, this chapter focussed on the evaluation of the detailed TOE complexity
framework. As a result of Chapter 4, all TOE elements were assumed to contribute to the
complexity of the project. This was confirmed for the majority of the elements by the
results of the survey study, see Table 6.8. For actual use of the framework, however, it also
seems useful to look at the possibility of determining aggregated complexity scores, e.g. for
T, O and E complexity. Such a higher level complexity footprint could support higher level
discussions between stakeholders. Based on the detailed scores for each of the complexity
elements (the detailed complexity footprint), category scores could be calculated to obtain a
quick project overview (the more general complexity footprint).
To come to aggregated scores for T-, O-, and E- complexity where all elements potentially
contribute equally to complexity, all answers need to be scored in the same range. The
majority of the survey questions about each of the T-, O- and E- elements had to be
answered on a 5-point Likert scale; hence a 1-5 scale for each element was the most
appropriate. Answers on three or four point scales were translated into the 5-point scale.
The answers on the few open questions were recoded into 5 categories. Details on the data
handling are given in Appendix E. Only those elements of the framework were included in
the calculations, for which meaningful correlations with other complexity elements were
133
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 Cronbach’s 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 Cronbach’s Alpha was calculated for the T-, the O- and the E- subcategories
(Table 6.11).
Table 6.11: Reliability statistics

Number of items in scale α N
Technical complexity 14 0.666 48 (19 missing)
Organizational complexity 15 0.669 41 (26 missing)
External complexity 13 0.561 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
Correlation Coefficient .416** .568** .166
Technical
Sig. (2-tailed) .000 .000 .183
Complexity
N 67 67 66
Correlation Coefficient .174 .575** .114
Organizational
Sig. (2-tailed) .160 .000 .363
Complexity
N 67 67 66
Correlation Coefficient .051 .519** .266*
External
Sig. (2-tailed) .683 .000 .031
Complexity
N 67 67 66
134
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:

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
7. How can a framework to grasp project complexity be used to improve project

performance?
A framework can only be used if it is a valid framework. The framework developed in
Chapter 4 was therefore thoroughly evaluated and checked for completeness, resulting in an
updated version of the framework. The respondents largely agreed with our 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. Meaningful aggregated complexity scores (for technical,
organizational and external complexity) were developed, to be used in the subsequent
Chapter 7.
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 (Bosch-
Rekveldt et al., 2011b)
Now we have developed (Chapter 4) and evaluated the TOE complexity framework
(Chapter 6), this chapter aims to link the project’s complexity characterisation, the front-
end 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 project’s 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):
6. 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 front-
end 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.
7.1 High level relations between complexity, front-end

activities and project performance
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
Chapter 7: Evaluating front-end activities
Front-end activities were operationalized twofold: 12 relevant value improving practices

(VIPs) were selected as described in Chapter 5. For the VIP-part, explicit questions were
asked on the amount of effort spent on each of the VIPs. For the current high-level
exploration, the total effort in front-end activities was operationalized by summing the
effort scores for the 12 Value Improving Practices (VIPs) as defined in Table 5.2.
The dependent variable was the project performance, composed similarly to the definition
in Section 5.2.3: total performance is the sum of schedule performance, cost performance
and quality performance. The higher this score, the better the project performed. From the
dataset of 62 projects, 12 projects were removed because of missing values for their
performance. The remaining 50 projects’ data set was divided into 4 groups:
• low complexity, little effort in front-end activities,
• low complexity, high effort in front-end activities,
• high complexity, little effort in front-end activities,
• high complexity, high effort in front-end activities.
The 50 projects in the sample were allocated to a group based on the median value for the
calculated total complexity and the median value of the sum of all (investigated) applied
activities in the front-end phase. This way, we could split our data in two complexity
groups (low and high complexity) and two front-end activity groups (little effort and much
effort in VIPs), based on the middle values in the current data set.
Next it was investigated whether the project performance varied significantly between these
groups, using two-way (also called factorial) ANOVA tests. In these ANOVA tests, the
fixed factors were the complexity (low =1, high =2) and the effort in application of VIPs
(little =1, high =2). Results are reported in detail in the subsequent subsections. Note that
no meaningful conclusions can be drawn on the number of projects in each of the groups
since we forced this group distribution.
7.1.1 Results total complexity, VIP effort and project performance

Table 7.1 shows the descriptive statistics for the group analysis (total complexity and VIP
effort).
Table 7.1: Descriptive statistics (VIP effort, total complexity, on project performance)
Mean = 11.13 Mean = 9.00
VIP
SD = 1.92 SD = 2.79
(high effort)
N = 15 N = 11
Mean = 9.50 Mean = 8.00
VIP
SD = 3.03 SD = 2.93
(little effort)
N = 10 N = 14
Complexity Complexity
(low) (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 T-
complexity 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 T-
complexity, 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)

Mean = 11.36 Mean = 8.92
VIP
SD = 1.86 SD = 2.61
(high effort)
N = 14 N = 12
Mean = 9.64 Mean = 7.77
VIP
SD = 2.91 SD = 2.92
(little effort)
N = 11 N = 13
T-Complexity T-Complexity
(low) (high)
Similar results were found for the group analysis taking front-end activities and O-
complexity 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, non-
overlapping 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)

Mean = 11.36 Mean = 8.92
VIP
SD = 1.82 SD = 2.64
(high effort)
N = 14 N = 12
Mean = 9.73 Mean = 7.69
VIP
SD = 2.83 SD = 2.93
(little effort)
N = 11 N = 13
O-Complexity O-Complexity
(low) (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)

Mean = 11.00 Mean = 9.46
VIP
SD = 1.78 SD = 2.96
(high effort)
N = 13 N = 13
Mean = 8.73 Mean = 8.54
VIP
SD = 3.26 SD = 2.90
(little effort)
N = 11 N = 13
E-
E-Complexity
Complexity
(low)
(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.
7.2 Activities typically performed in the front-end phase

As described in Chapter 5, the activities that are typically performed in the front-end phase
were split into the value improving practices (VIPs) and some ‘other’ practices. First we
will present the results of applying these 12 VIP activities. Next, we will present the results
of applying the ‘other’ practices.
7.2.1 Activities in front-end: Value Improving Practices (VIPs)

The VIPs were surveyed in four questions of which the results are given in Table 7.5. The
table indicates the number of cases in which a particular answer was given. The highlighted
results are discussed.
1. How much effort was spent in the activity?

The majority of the VIPs were substantially applied in every project. Risk management,
project quality control and constructability review were substantially applied according to
about two-third of the respondents. Two activities stood out as being applied considerably
less than the others: external benchmarking and to a lesser extent stakeholder management.
External benchmarking was not applied at all in many projects (21) and only little in most
others (19). In 10 projects it was substantially applied and for the remaining 12 projects,
data was missing. Stakeholder management was usually lightly applied (30) or substantially
(20). The number of 20 responses for “substantially” is rather low compared to the effort
spent in the other activities.
2. Was this application of the VIPs sufficient, too little, or too much?
The amount of application of the VIPs was considered sufficient according to the majority
of respondents. “Too much application” was very rare, but some VIPs were considered to
have been applied too little. VIPs that were considered to be applied too little by more than
25% of the interviewees were: operations implementations planning, goal-setting and
alignment, and stakeholder management. Particularly for the latter two, this is remarkable
given the literature indicating the importance of goal setting and alignment (Hacker &
Doolen, 2007; Locke & Latham, 2002), and stakeholder management (Yang, Qiping Shen,
Ho, Drew, & Xue, 2010). Apparently there is still a gap between what is described in
literature and what really happens in practice.
3. Was the activity beneficial to the project?

When asked about the benefits of the VIPs for the project result the majority were
considered beneficial (agree) or very beneficial (strongly agree). The most beneficial VIPs
according to the interviewees were: project team building, constructability review, risk
management and, to a lesser degree, project quality control. The recognized benefit of
lessons learned positively surprised us; it seems practice is aligned with literature trends
stressing the importance of lessons learned (Cooke-Davies, 2002; Williams, 2003),
although this literature also stresses the difficulty of effective implementation of lessons
learned. In practice, the respondents said to have applied lessons learned sufficiently, which
is also contrary to our experiences.
142
Table 7.5: Survey results of VIP questions

Numbers of cases in which particular answer was given, N = 62
Grey filled cells are discussed in the text
Operations implementation planning
Goal-setting and alignment
Stakeholder management
Constructability review
External benchmarking
Project quality control

Project team building
Technology selection
Design to capacity
Value engineering
Risk management
Lessons learned
None 2 5 2 3 5 5 6 2 21 2 3 6
Effort
Little 18 20 9 18 19 21 22 16 19 14 21 30
Substantial 39 28 45 34 31 31 30 41 10 43 36 20
Missing 3 9 6 7 7 5 4 3 12 3 2 6
Too little 13 2 6 3 15 19 18 15 8 9 13 21
Amount
Sufficient 45 49 47 48 37 35 39 39 33 45 44 34
Too much 0 0 0 2 1 2 0 3 3 3 1 0
Missing 4 11 9 9 9 6 5 5 18 5 4 7
Strongly disagree 1 0 0 0 0 0 0 0 0 0 0 0
Disagree 0 1 0 7 5 6 3 4 6 1 5 5
Beneficial
Neutral 6 15 12 18 11 17 13 14 8 9 12 19
Agree 35 23 27 22 28 18 29 26 11 37 34 17
Strongly agree 14 8 13 4 5 8 5 12 2 8 4 6
Missing 6 15 10 11 13 13 12 6 35 7 7 15
Strongly disagree 17 11 18 7 9 11 13 16 3 10 9 10
Disagree 29 25 26 29 24 22 25 24 10 30 31 21
Burden
Neutral 8 10 8 12 13 11 10 12 10 11 12 14
Agree 1 1 1 3 3 5 3 3 4 3 2 3
Strongly agree 1 0 0 0 0 1 0 1 1 1 1 0
Missing 6 15 9 11 13 12 11 6 34 7 7 14
143
4. Was the activity a burden to the project?

None of the VIPs was considered a burden to the project by more than six respondents (six
respondents agreed for the VIP operations implementation planning). Project team building,
constructability review, and risk management are the least considered a burden, more than
25% of interviewees strongly disagreed with these VIPs being a burden to the project.
These VIPs are also the ones that were considered the most beneficial to the project.
Combining the answers on the four discussed questions

The two least applied VIPs are stakeholder management and external benchmarking.
Stakeholder management was considered to be applied too little by 21 interviewees (34%),
one of the highest rates of all VIPs. External benchmarking was considered to be applied
too little in only eight cases (13%). Hence we can conclude that, not applying external
benchmarking is often considered sufficient, but stakeholder management should be applied
more thoroughly in the eyes of many of the interviewees. The VIPs that were considered
the most beneficial to the project were also the ones that were considered the least of a
burden to the project: project team building, constructability review, project quality control
and to a lesser extent risk management. It was therefore to be expected that these were also
the most applied of all VIPs: indeed all of them were applied substantially in more than 39
cases. Risk management and lessons learned are often thought to be hardly applied in
practice, which is not confirmed in this study. Goal alignment was applied too little by 29%
of the respondents. Given its perceived importance, there is something to gain there. To a
lesser extent, this yields the application of operations implementation planning.
7.2.2 Other activities in front-end development

The “other” practices, resulting from the case study findings in Chapter 3, also described in
Chapter 5) were surveyed in the form of statements to be answered on a Likert scale
(strongly disagree – strongly agree). Results are given in Table 7.6; the highlighted cells are
discussed in detail. For the majority of the “other” practices a dominant answer, usually
agree or disagree depending on the direction of the statement, was found. Four “other”
practices were agreed or strongly agreed on by more than 2/3 of the respondents: the
business and project team had the same goals in mind for this project, the project manager
had a say in human resourcing of this project, the project team incorporated all necessary
disciplines and the project manager cooperated closely with the steering committee of the
project. These results reflect good co-operation within the company and good preparation in
terms of team composition in the majority of projects under investigation.
Three statements had more than one dominant answer: scope changes occurring late in the
FED phase, active risk register monitoring, and the project suffering from late entry of
parties. Late scope changes and late entry of parties may be affected by external factors and
are not always completely controlled by a project manager. The process of risk
management on the other hand is within the control of a project manager. Note the
discrepancy between risk management as a VIP (Table 7.5) and the active use of a risk
register to control risks throughout the project (Table 7.6): the VIP risk management was
usually applied substantially, sufficiently and was considered very beneficial, but using the
risk register to actively monitor risks during the whole FED phase was done as often as not.
This could indicate that:
- People see the active risk monitoring not as part of the VIP risk management,
- People see it as part of the VIP risk management but do not execute this VIP properly,
- People use different tools than the risk register for active risk monitoring,
- Respondents gave socially desirable answers.
144
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 Strongly
Disagree Neutral Agree Missing
disagree agree
1. Within my company, the
business and project team had
the same goals in mind for
0 5 9 31 15 2
this project
2. The goals of this project were
actively monitored 0 6 16 26 11 3
throughout FED
3. Substantial scope changes
occurred in a late stage of 0 17 11 22 9 3
FED
4. The project manager had a
say in human resourcing of 1 6 8 34 11 2
this project
5. The project team incorporated
all necessary disciplines
0 3 4 41 13 1
6. A lack of cohesion in the
team endangered the project 6 31 9 13 2 1
outcome
7. The foreseen complexity of
this project was taken into
account when selecting the 5 11 10 24 10 2
project manager for this
project
8. More social team building
would have been beneficial 0 13 26 17 4 2
for the project
9. The project manager
cooperated closely with the
steering committee of the
1 6 7 35 10 3
project
10. The steering committee
regularly intervened in this 3 25 19 12 1 2
project
11. Co-operation with
(sub)contractors was
hampered by the main
9 23 11 9 4 6
contract type
12. The project manager
regularly intervened in the 5 14 16 20 3 4
work of the (sub)contractors
13. The (sub)contractors worked
closely together with the 1 8 15 30 4 4
project manager
14. Too many project
management meetings were 2 35 13 6 3 3
held during the project
15. A risk register was actively
used to monitor risks 6 19 7 20 7 3
throughout the project
16. The project suffered from late
entry of parties
5 19 16 18 3 1
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.
7.3 Direct relations with project performance

Now we know what activities typically were applied (or not!) during front-end
development, the correlations of the front-end activities with project performance were
investigated. Several significant results were found; see Table 7.7 and Table 7.8.
Table 7.7: Overview of significant correlations

Number of Number of Percentage of
Relations between possible significant significant
relations relations relations
Front-end activities – Project performance 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
Correlation
Var1 Var2 strength Sign.(p) N Meaning of correlation
(rs)
2. Project goals Active monitoring of
were actively .412** .003 50 project goals increases
monitored project performance
VIP: Amount of Perceived sufficient
application of goal application of goal setting
.358* .013 47
setting and and alignment increases
alignment project performance
1. The business and
Goal alignment between
project team had
business and project team
the same goals in .292* .039 50
increases project
mind for this
performance
project
application of application of project
.380** .008 47
project team team building increases
building project performance
6. A lack of team More problems due to a
cohesion lack of team cohesion
-.379** .007 50
endangered the decrease project
project outcome performance
Project
8. More social team
performance
building would More social team building
have been -.315* .026 50 decreases project
beneficial to project performance
outcome
11. Co-operation Co-operation with
with (sub)contractors that was
(sub)contractors -.329* .022 48 hampered by contract type
was hampered by decreases project
contract type performance
16. The project Late entry of parties
suffered from late -.342* .015 50 decreases project
entry of parties performance
VIP: Application of Application of operations
operations implementation planning
.444** .001 49
implementation increases project
planning performance
application of application of external
.324* .044 39
external benchmarking increases
benchmarking project performance
*
significant at 0.05 level, ** significant at 0.01 level
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.
7.4 Moderated relationships

As we will see in the analysis framework in Section 7.4.2, it is necessary to show a
relationship between project complexity and front-end activities before a moderated
relationship with project performance can be found (Donaldson, 2001). Testing the
relationship between project complexity and front-end activities also has a practical value
since awareness of interaction between the two is required if we ever want to be able to
adapt the front-end development phase to project complexity. Before investigating the
moderated relationships between project complexity, front-end activities and project
performance, first the contingency theory is recaptured (see also Section 2.6).
7.4.1 Contingency theory

Contingency theory originates from organizations studies (Dessler, 1976), with a number of
pioneers (Burns et al., 1961; Galbraith, 1973; Lawrence & Lorsch, 1967; Thompson, 1967;
Woodward, 1965) and is more recently described by Donaldson (2001). According to
contingency theory, the organizational structure is made dependent on the contingency
factors, with a fit between organizational structure and a contingency factor leading to best
organizational performance. In other words: the right combination of contingency factor
and organizational structure leads to better organizational performance. That means that
organizations utilizing the organizational structure that better suits its contingency factors
will perform better than organizations using a structure that does not match the contingency
factors. Main (classic) contingency factors identified in organizational research are:
strategy, rate of change, size, task uncertainty and technology (Donaldson, 1996).
In organizational contingency theory two characteristics of contingency factors are defined.

These two characteristics play an important role in applying contingency theory to project
management. The first characteristic is that a contingency factor acts as a moderator in a
relationship. This means that the relationship between two variables (A and B, see Figure
7.1) depends on, or is moderated by, the moderating variable C. The effect of A on B
differs when C is low or high. For instance A can have a negative effect on B when C is
high and a positive effect when C is low. Thus C can be seen as the moderating or
conditioning variable of this relationship (Bryman & Cramer, 2009; Galtung, 1967).
Acting as a moderator is a necessary but not sufficient condition for being a contingency
factor. Next to the moderating effect, it is essential that the right combination of A (the
independent variable) and C (the contingency factor) will result in high B. This second
characteristic is known as “fit” between variables A and C. Elaborating the previous
148
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.
Figure 7.1: C (Complexity) as a moderator of the relationship between A (front-end

activities) and B (Performance)
In other words: applying a contingency approach to project management means that project
management (in this study: the activities in the front-end development phase) would be
applied to fit the contingency factor (so the front-end phase is adapted to the project
complexity), with this fit improving the project performance. As described before in this
dissertation, the potential importance of making project management contingent upon its
context or environment is stressed in literature (Engwall, 2003; Shenhar & Dvir, 2007a;
Smyth & Morris, 2007; Williams, 2005). Finding the right combinations of front-end
activities and project complexity would help to improve project performance in the future,
because it would be possible to adapt front-end development practices to the particular
project complexity ‘footprint’, already in early project phases.
7.4.2 Analysis framework

Testing for contingency can be done using an analysis framework from organizational
research, based on the work of Donaldson (2001). An empirical approach was followed:
based on the available data, patterns were investigated according to the following steps:
• 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.
Step 3 of testing for causality is often problematic in organizational theory, because

causality is challenged as structure and contingency factors undergo simultaneous changes,
149
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.
Figure 7.2: Overview of potential relationships
7.4.3 Relations between front-end development and project

complexity
Step 2a of the analysis framework involved the investigation of relations between front-end
activities and project complexity. Please note that their possible link with project
performance is treated in the next subsection 7.4.4.
The number of possible relations between front-end activities and project complexity was
120 (40 FED variables times 3 complexity variables). In total 14 significant relations were
found which is about 12% of the total number of possible relations (and hence more than
the minimum of 5% that one would expect with α = 0.05). Significant results indicated a
direct relationship between the particular front-end activity and project complexity.
However, no conclusions can be drawn on causality here because project complexity might
be influenced by front-end activities but front-end activities might be influenced by project
complexity (Bryman & Cramer, 2009).
Table 7.9 shows five significant correlations between technical complexity and front-end
activities. The correlation between technical complexity and the perceived amount of
application of risk management is modest at the 0.01 significance level (rs = -.452, p =
.000), e.g. increased technical complexity coincides with perceived too little application of
risk management. In other words: risk management is applied too little in view of the
respondents with increasingly technically complex projects and this could need more
application.
150
Technical complexity weakly correlated to the perceived amount of application of lessons

learned (rs = -.272, p=.039), e.g. increased technical complexity coincides with too little
application of lessons learned in view of the respondents. Hence more application of
lessons learned would be beneficial for technically complex projects. This also yields for
goal setting and alignment. A weak correlation was found between technical complexity
and the perceived amount of goal setting and alignment (rs =-.271, p=.042), e.g. increased
technical complexity coincides with too little application of goal-setting and alignment.
With technically complex projects, more goal-setting and alignment could be beneficial.
One could then expect active goal monitoring throughout the front-end development phase
for technically complex projects, but in the dataset, a weak negative correlation was found
between technical complexity and active monitoring of project goals (rs = -.264, p=.043),
showing that with technically complex projects, lower active monitoring of goals was
actually applied in view of the respondents. Finally, a weak correlation was found between
technical complexity and the late entry of parties (rs=.255, p=.047): in view of the
respondents, increased technical complexity coincides with problems due to late entry of
parties.
Table 7.9 also shows five significant correlations between organizational complexity and
FED. At a p-level of 0.01, there were two significant, weak correlations: one between
organizational complexity and the perceived amount of goal setting and alignment (rs = -
.358, p=.006) and one between organizational complexity and the late entry of parties (rs =
.339, p=.008). So increased organizational complexity coincides with a too little application
of goal setting and alignment in view of the respondents and increased organizational
complexity coincides with more problems due to late entry of parties. One could
hypothesize that the latter (late entry of parties) negatively influences the functioning of the
project team. Other correlations between organizational complexity and front-end activities
indeed show the importance of the project team in view of the respondents. Increased
organizational complexity weakly correlated to the statement that a lack of cohesion in the
team endangered the project outcome (rs= .280, p=.029); e.g. increased organizational
complexity coincides with problems due to a lack of team cohesion. For increasingly
organizationally complex projects, more teambuilding could have been beneficial, based on
this dataset (rs = .261, p = .044). There is also room for improvement in the field of
selecting the project manager, according to the respondents. With increasingly
organizationally complex projects, the foreseen complexity of the project was not taken into
account when selecting the project manager (rs = -.273, p=.035).
Finally, Table 7.9 shows four significant correlations between external complexity and
front-end activities. Increased external complexity was shown to coincide with the
perceived amount of application of risk management (rs = -.320, p=.015). So not only
technical complexity coincides with too little application of risk management, but also
external complexity, albeit with a lower strength and hence to a lesser extent. Further,
increased external complexity coincides with less co-operation between the PM and the
steering committee (rs = -.286, p=.028). Again indicating the importance of the function of
the project team, weak correlations with external complexity were found for the perceived
amount of application of project team building (rs= -.279, p=.034) and the statement that
more teambuilding would have been beneficial for the project (rs =.273, p=.035). E.g. with
increased external complexity, more teambuilding would be required in view of the
respondents.
151
Table 7.9: Significant correlations between complexity and front-end activities
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 front-
end 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
amount of possible relations. Therefore, we should be careful drawing too strong

conclusions based on the subgroup analysis. Still the results (particularly those on the 0.01
level) indicate which areas need further investigation.
The significant correlations found with the subgroup analysis were modest (0.40 to 0.69) in
the group of projects with good performance (19 projects) and low to modest (0.20 to 0.39,
0.40 to 0.69) in the group of projects with poor project performance (31 projects). This was
to be expected, since with smaller samples, the correlation strength needs to be higher to be
significant. The strongest of all correlations was found in the subgroup of projects with
good performance. The relations found within the group projects with good performance
are discussed first.
The strongest correlation was found between technical complexity and the perceived
amount of application of risk management (rs = -.648, p=.004), e.g. increased technical
complexity coincides with too little application of risk management in view of the
respondents. In these projects with good performance, it was recognized that the perceived
amount of application of risk management was too little. Note that this does not say how
much risk management actually was applied! We can explain the finding on the amount of
application of risk management as follows. First, the projects could have performed even
better when sufficient risk management was applied, whatever level this sufficiency would
be. Second and maybe more realistic, the importance of applying sufficient risk
management with increasingly complex projects is more apparent in projects with good
performance: those respondents simply have a better understanding of what project
management is about.
In view of the respondents, increased organizational complexity coincides with more say in
human resourcing (rs = .604, p=.008), contributing positively to project performance. So for
increasingly complex projects, it seems beneficial that the project manager has a say in
human resourcing of the project. Increased external complexity coincides with both too
little perceived application of risk management (rs = -.498, p=.036) and too little perceived
application of external benchmarking (rs=-.562, p=.036). Again: the respondents recognize
the importance of sufficient application of both risk management and external
benchmarking with increasingly complex projects, particularly in the projects with good
performance. Finally, increased technical complexity coincides with regular interventions
by the steering committee (rs=.489, p=.034), contributing positively to project performance.
According to the respondents, regular interventions by the steering committee are beneficial
particularly for technically complex projects.
154
Table 7.10: Significant correlations within subgroups
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.
7.5 Summary of relations found between front-end activities,

complexity and project performance
The previous sections (Section 7.1 to Section 7.4) showed how we derived relationships
between front-end activities, project complexity and project performance in our project
sample. First on high level following a 2x2 business approach, subsequently in more detail.
From the 2x2 study, we found that increased project complexity coincides with decreased
project performance (significantly) and spending effort in VIPs coincides with improved
project performance (almost significantly).
Subsequently, we performed detailed investigations towards the potential relationships

between front-end activities, project complexity and project performance. Results of the
detailed investigations are summarized in Figure 7.3 and Figure 7.4 and discussed in detail
hereafter, including their managerial implications. Note that the current research mainly
included subjective measures on the application of value improving practices and selected
“normal” practices. Often, the perception of the respondent was measured, and it was not
assessed what actually has been done.
First, there are the direct relationships between front-end activities and project performance
(block 1 in Figure 7.3):
- Goal alignment between business and project team increases the chance of good
project performance. This empirical finding supports literature findings (Cooke-
Davies, 2002; Meskendahl, 2010) and empirical findings (Scholten et al., 2010)
that show the importance of goal alignment between business and project team.
- Co-operation with (sub)contractors, hampered by contract type, decreases the
chance of good project performance. From literature we know that contract type
indeed can influence the co-operation between owner-contractor (Müller &
Turner, 2005; Pinto et al., 2009).
- Applying operations implementation planning increases the chance of good project
performance. Again these findings support literature findings indicating that
“customer participation in the development process and final user preparations
have the highest impact on project success” (Dvir, 2005). Note that about one third
of the respondents found that operations implementation planning was applied too
little; hence indicating the potential for improvement.
157
Sufficient application of external benchmarking increases the chance of good project

performance. Here there can be major room for improvement since only in 10 projects
external benchmarking was applied substantially. The majority of respondents did not apply
external benchmarking (21 projects) or applied it only lightly (19 projects). The challenge,
obviously, is to assess what the sufficiency level should be. No literature could be found to
support this finding.
Figure 7.3: Relationships influencing project performance: results current dataset
Second, there are the direct relationships between front-end activities and project
performance where, separately, those front-end activities also showed a relation with
project complexity (block 2 in Figure 7.3, more detailed representation in Figure 7.4). As
indicated before, it is not clear which factor is a cause, and which factor a result in that
latter relationship: front-end activities might influence project complexity or vice versa.
The relationships found in our empirical research were:
- Active goal monitoring increases the chance of good project performance.
However, increased technical complexity coincides with lower active monitoring
of project goals. So it seems that in case of technically complex projects, more
attention could be paid to active monitoring of project goals.
- Sufficient application of goal setting and alignment increases the chance of good
project performance. However, increased organizational complexity as well as
technical complexity coincides with the perception of insufficient application of
goal setting and alignment. E.g. particularly in case of organizationally and/or
technically complex projects, it seems important to pay enough (and more than
currently!) attention to goal setting and alignment.
- Sufficiently applying project team building increases the chance of good project
performance, and increasing organizational and external complexity coincides
158
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.
Figure 7.4: Relationships complexity, front-end activities and performance in more

detail (dashed block from Figure 7.3)
Third, there is the moderated relationship in which project complexity acts as a moderator
in the relationship between the front-end activity and project performance (block 3 in
Figure 7.3). This means the relationship varies when project complexity varies. Other than
the front-end activities in block 1, the relationship between the front-end activity and
project performance only exist in combination with (a certain type of) project complexity.
Only one moderated relationship resulted from this research: when technical (or external)
complexity rises, there is lower sufficiency of application of risk management (e.g. more
risk management would be required), increasing project performance. In other words: with
more complex projects, more effort should be spent in risk management to increase the
chance of good project performance. This finding seems to support earlier research on risk
159
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.
7.6 What is the influence of the respondents’ role?

In the previous sections we investigated the potential relations between front-end activities,
project complexity and project performance across the whole dataset, not taking into
account the respondents’ role. Sample limitations (number of projects in our dataset) did
not allow such detailed analysis. From earlier qualitative studies (see also Chapter 3 of this
dissertation), however, we found that the role of the respondent might also influence their
perspective on project complexity and the management of the project. Therefore we also
did perform some exploratory analysis towards the influence of different roles of the
respondents on their view on complexity and their view on front-end activities.
For this analysis, the complete dataset as described in Chapter 5 was used; hence 67
different projects were included. The project complexity was operationalized using the
TOE framework (Table 6.8) and the front-end activities were operationalized by the value
improving practices (Table 5.2) and the “other” front-end activities” (Table 5.3).
The respondents had different roles, basically on two levels (Section 5.4.1):
1. their role in the project (PM, team member, business representative),
160
2. the role of their company in the project (owner, (managing) contractor,

subcontractor).
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 non-
parametric 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 Respondent’s 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)
Mean Rank
Project Business Team
Test item H(2)
manager representative member
Complexity Number of goals 6.45* 35.97 41.25 25.19
elements Incompatibility of different
(50 in total) 12.86** 27.69 31.77 46.50
PM methods and tools
Perceived amount of VIP
7.78* 35.80 30.17 24.09
goal setting and alignment
Perceived benefit of VIP goal
9.49** 31.05 14.50 29.80
setting and alignment
Perceived burden of VIP risk
6.28* 26.56 34.00 38.84
management
Too many project
management meetings were 6.58* 28.00 39.86 37.84
Front-end held
activities The project manager
(64 in total) cooperated closely with the 6.57* 37.15 26.17 26.78
steering committee
A lack of team cohesion
endangered the project 10.65** 27.28 40.04 42.41
outcome
The project suffered from late
6.97* 28.41 44.27 35.71
entry of parties
The foreseen complexity was
taken into account when 17.07*** 41.13 26.38 20.47
selecting the project manager
***
Kruskal-Wallis test result is significant at the 0.001 level
**
*
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 “hands-
on” 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 respondent’s company

As indicated in Section 5.4.1, three different roles were distinguished with respect to the
role of the respondent’s company in the project: owner (N=22), (managing) contractor
(N=33) and subcontractor (N=5). In another 7 projects, the respondent’s 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
owner’s 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
Managing Sub-
Test item H(2) Owner
Contractor contractor
Conflicting norms and standards 7.62* 21.86 33.56 32.88
Complexity
Project schedule drive 6.92* 24.55 35.45 24.00
elements
Lack of trust in contractor 7.18* 20.76 28.81 10.83
(50 in total)
Lack of experience in the country 8.24* 22.25 35.73 32.30
Perceived amount of VIP
operations implementation 8.37* 35.38 26.25 17.50
planning
Benefit of VIP operations
9.40** 32.58 20.38 32.50
implementation planning
Benefit of VIP goal setting and
7.07* 31.43 22.02 17.33
alignment
Burden of VIP goal setting and
6.76* 21.23 27.70 42.00
alignment
Applying VIP stakeholder
Front-end 6.61* 31.19 25.89 12.75
management
activities
Benefit of VIP stakeholder
(64 in total) 7.81* 28.68 18.67 16.00
management
Benefit of VIP project team
6.22* 33.93 24.90 20.13
building
*
Benefit of VIP value engineering 7.80 29.18 25.07 6.17
Benefit of VIP lessons learned 6.03* 32.38 22.66 29.13
Applying VIP constructability
8.12* 24.97 31.71 18.75
review
The project manager cooperated
closely with the steering 7.58* 31.83 31.52 12.30
committee
**
*
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 front-
end 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):
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
performance with project complexity as a contingency factor. Results of this exploration

indeed suggest that with particular complexities, spending more effort in particular front-
end activities might be beneficial. Following a contingency approach, moderated relations
between front-end activities, project complexity and project performance were looked for,
next to the direct relations between front-end activities and project performance and project
complexity and project performance. One significant moderated relationship was found:
risk management was influencing project performance, moderated by technical and external
complexity. In case of technically and or externally highly complex projects, more risk
management would be needed to improve project performance.
In this chapter, insight was obtained in the relations between front-end activities, project
complexity and project performance using multi-level analysis techniques. The high level
2x2 matrix set up (Section 7.1) provided the evidence of project complexity reducing the
project performance. The subsequent detailed analysis (Section 7.2 to Section 7.6) resulted
in the value improving practices and “other” front-end activities beneficially contributing to
project performance in our data sample. Using a contingency approach, not only direct
relations between the variables were investigated but also moderated relations. In the
remainder of this section, first the methodological limitations are discussed, followed by
managerial implications of this chapter’s findings.
7.7.1 Methodological limitations

The NAP survey had an exploratory character: it “grasped” the wide field of front-end
development of projects, investigating linkages between front-end activities and certain
aspects of project complexity and their (joined) influence on project performance,
specifically for engineering projects. With the current dataset of 67 projects, possible
relationships between numerous variables were investigated. Because of the large amount
of variables, we have to be careful drawing firm conclusions. Still, the results show certain
relationships between project complexity, front-end activities and project performance, see
also the managerial implications in Section 7.7.3.
The survey contained questions with a rather subjective character. This is related to the
difficulty of objectively assessing the practise of project management: how should one
measure for example the absolute amount of effort that was spent in applying VIPs? And
even if this absolute amount would be known, it cannot be interpreted without taking into
account the context of the specific project (think of the principles of constructivism: there is
no single truth: truth is socially constructed). To strengthen the current results related to the
relevant VIPs, Chapter 8 presents an in-depth case study focusing on how the most relevant
VIPs were actually applied and how these were contributing to the project performance.
Current data limitations could also be overcome by “simply” and continuously gathering
more data from engineering projects from within the NAP network companies. Also
extension of the research into adjacent industry sectors could be considered, hence
overcoming the limited generalization possibilities of the current results. To allow for some
generalization inside the sector, the respondents were asked to select their most recently
completed project, as opposed to their most favourable one, or their best/worst one.
7.7.2 Comparison with literature

This chapter suggests that the current situation in project performance already considerably
could be improved in case project managers would actually practice what they preach.
Recent research of Papke-Shields et al. investigated the use of project management
167
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 chapter’s 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 IPA-
Industry 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 manager’s 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 project’s
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

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).
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 project’s 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
Criterion Cases left
step
0 Projects from the NAP survey 67
1 Involvement in Front-End Development stage 62
2 Willingness of respondent to participate in subsequent research 25
3 Score “little” or “substantial” on independent variables (VIPs) 14
4 Being perceived as technically complex 7
5 Contact person’s role was project manager 4
172
Chapter 8: The application of value improving practices
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 Role in Project
Case Interviews
REF-ID project performance
2; PM and team member
A 8 Owner Good
(chemical engineer)
3; PM and two team members
B 41 Contractor Good
(electrical engineer and process engineer)
3; PM and two team members
C 42 Contractor Very poor
(architect and civil engineer)
D 83 Contractor Poor 1; PM
2; PM and team member

E Additional Owner Good
(mechanical engineer)
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
Figure 8.1: Overview of selected cases: scores on project performance
8.1.3 Case protocol, validity and analysis set up

The cases were analyzed qualitatively: case by case as well as across the different cases,
focusing on the actual implementation and application of the VIPs. A case study protocol
was developed and included the following activities:
• In-depth study of survey results for the specific cases, resulting in a case summary
based on the survey results as a starting point for the interviews
• Contacting the identified project managers via e-mail with the invitation to
cooperate in this follow-up research.
• Distribution of case summaries and topics to be discussed during the interviews to
the interviewees.
• Conducting semi-structured interviews about how the main activities influencing
project performance were applied, using the list of questions in Appendix F.
• Asking the project manager to identify two project team members and asking for
their participation.
• Distribution of the interview results (narratives) back to the interviewees, asking
them for comments and approval to use these narratives in the research.
• Analysis of the interview results, case by case (based on the narratives) and across
the cases.
To assess the validity of the research design, the concepts of construct validity, internal
validity and reliability are addressed (Blaikie, 2009; Yin, 2002). To start with the latter, the
concept of reliability (the study could be repeated with the same results) was ensured by
developing a case study protocol, recording interview data and storing all case study results
in a database. The internal validity (are causal relationships found indeed caused by the
factors studied) was ensured by thorough analysis of the results, triangulation with literature
and careful formulations of the conclusions, stressing 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 enhanced by asking the participants in the case study to review and approve
the interview reports. Also, company sensitive information was made anonymous thereby
enabling other researchers to feedback on the research. In the interviews, the opinion or
definition of the interviewees on the concept(s) under discussion was explicitly asked for,
and taken into account during the analysis.
174
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.
8.2 The 5 cases at first glance

8.2.1 Case A: A construction project by an owner organization
The key objective of this project was to increase the production capacity of an existing
production facility and to improve its cost efficiency by building a new plant. This
construction project was undertaken for operational necessity and to comply with
legislation. It was an own investment: the project was completely paid by the owner
company where the interviewees were working. The stakeholders in this project were
mainly internally oriented. Next to the owner company, (sub)contractors were involved.
The cost estimate of 30MEuro was met; the schedule estimate of 30 months was exceeded
with 3 months.
The owner project team consisted of 8 persons and managed the engineering contractor in
close collaboration. Actually it was an integrated project team, where the project owner
allocated specialists (chemical and process engineers) to guide and steer the contractor
onsite. The close collaboration was indicated as one of the project success factors in this
project because of the resulting direct and efficient information exchange and knowledge
sharing. Another perceived success factor related to the project team composition was the
involvement of one of the current team members in the preceding, related R&D project.
In view of the interviewees, the project team was actively involved in the definition of the
detailed user requirement specification, after the high level goals were set by higher
management. The project manager stressed within the project team the importance of
knowing the project driver (in this case cost driven) by all parties involved. The project
manager actively monitored project goals by issuing monthly progress reports.
On project level, risk identification, prioritization and allocation of risk ownership was
performed when the business case was formulated and when the user requirement
specifications were defined by the project team. At that time, the results were reported to
the Steering Committee. Subsequent recurrent systematic risk identification and monitoring
was not performed in view of the interviewees. According to the survey results, they
applied this VIP “little”.
Despite the survey results indicating “little” application of the VIP External benchmarking,
this was actually not applied in view of the interviewees, highlighting the difficulties of
benchmarking in an industry where patented processes and products are involved.
Operation implementation planning (OIP) was performed by the early involvement of the
future owners (operations and maintenance). This early involvement was the key factor in
175
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
contractor’s side. The owner also appointed a project manager and delivered two process
engineers to the integrated project team. According to the contractor’s 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 client’s 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
roles, positive interpersonal relationships and alignment of the different disciplines

involved.
Project goals and deliverables were set following the contractor’s standard work
procedures. Subsequently, these were further described in the project plan. The contractor
was already involved (in a consultant role) in defining the very early project requirements,
which was considered beneficial since it contributed to better understanding of the specific
requirements later on in the project. The project goals were monitored by the project
manager who compared the project plan and the progress reports of the lead engineers on a
monthly basis. Progress was reported and discussed in the project team meetings with the
client on a monthly basis. According to the project manager, monitoring the goals by
assessing the progress reports and having stage gates beneficially contributed to project
performance (or, formulated more precisely, prevented an even bigger project failure). It
created the opportunity to work together effectively and to keep pace. On request of the
client, and as a result of the related parallel project, project requirements changed
considerably, resulting in serious project delays.
The project manager indicated that the client was mainly responsible for risk management.
On a yearly basis the contractor was involved in a risks analysis workshop together with the
client. Besides the yearly risk analysis workshop, the contractor also identified and
monitored risks. This was done on a monthly basis by making it an integral part of their
project meetings. The RISMAN method (Well-Stam, 2003) was used which is a method
that enables identifying risks, prioritizing risks and coming up with mitigations. During
these monthly meetings the risks were updated in a central document. The project manager,
assisted by the project management assistant, was responsible for the monthly risk
management actions. In his view, risk management as performed by the contractor was a
contribution to the project performance (at least prevented an even worse project
performance). According to the team members, the most serious risk in this project was the
influence of various stakeholders (other than the client) as they could stagnate the decision
making progress. The mitigation for this risk, early in the project already defined by the
contractor, was to make clear agreements with the client and to structure meetings in
advance by setting milestones and deliverables in order to stimulate timely delivery.
Although clear mitigations were defined, the client could not deliver essential project
information in time (because of reluctance of other stakeholders), resulting in project delay.
Neither external benchmarking, nor operations implementation planning were applied by

the interviewees. In their view, these practices are unknown in the civil engineering
industry.
Reflecting on the above summary, it seems that this project faced interface problems. An
integrated project team, in which the client was included, could have overcome such
interface problems. Interface problems also resulted in not being able to maintain goal
alignment throughout the project. As a result of the long duration and public environment,
the project was influenced by a changing political situation after elections which
subsequently altered the project scope. Discontinuity in the project team did not help. Risk
management was formally (but marginally…) applied, following a structured process. An
integrated project team could have overcome serious issues here: owner and contractor
applied (aspects of) risk management both, but separately. And formally codifying the risks
as done by the contractor was not sufficient. More general, it is not about formally applying
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

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
On request of the customer, external benchmarking was performed by IPA. According to

the project manager the outcome of the external benchmarking study could not be used to
leverage the performance of the project.
Operations implementation planning was done according to the project manager, but
mainly in terms of checking and testing the new equipment, and system trial runs.
According to the project manager these procedures ensured a successful start-up.
Reflecting on the above summary, it seems the lack of systematic risk management in the
early project phase contributed to the schedule delay. A risk evaluation every three months
seems rather infrequent. In this case, there was an integrated project team, but real
involvement and integration seems lacking. Results of the IPA benchmarking study were
not used to improve the project performance (lack of integration) and although operations
implementation planning was done in view of the contractor’s project manager, this seems
limited to the technical part whereas involving the operations department early in the
project could have prevented schedule delays (again a lack of integration and involvement).
8.2.5 Case E: A Greenfield design and construction project by an

owner (good project performance)
The key objective of this project was to build a new factory on a new location to produce an
existing product with a new production process. Hence new technology was included in the
project. The project needed a total investment of about 100 million Euro (100% by the
project owner) and the planned duration was three years. The project was split in two
phases. Phase 1 ended during front-end development when the cost estimate was increased
with more than 40%. The project was temporarily stopped and a redefinition of the project
scope was made. A new project manager was appointed, a new contract with an
engineering contractor was made and phase 2 started. The major challenge of this project
was that project execution started while R&D was not yet ready because of business
pressure. In total, the project budget was overrun with 10 million and the project was
delayed with 3 months and delivered with good quality, which made it a good performing
project in the definition of the current study.
The project team consisted of members from both the project owner and the contractor. The
multidisciplinary, integrated team (piping, mechanical equipment, installation, civil,
process engineers and production) was fully dedicated to this project. In total 20 team
members were involved. In view of the project manager, this integrated team offered the
opportunity to communicate directly with each other when problems arose, for example
aligning design adjustments. These design adjustments were communicated efficiently
throughout all disciplines in the team. Constructive disagreements such as having different
views on design occurred in the team. In view of the project manager these disagreements
could have been reduced by composing the project team also based on competencies and
personal characters rather than solely on the engineering disciplines needed.
Because of the urgency of the project, the management board put pressure on the initial
time schedule. Therefore the conceptual design started while the technology was not
completely proven and tested. In phase 1, no clear milestones and deliverables were set for
the R&D part of the work, leading to rework once results came available and a temporary
stop of the project. The new project manager started with a workshop in which all internal
stakeholders were involved in order to define a new business case for the project. The
essential deliverables of R&D were defined and ways to obtain savings were discussed.
180
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. Operation’s 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.
8.3 Cross case analysis

Using the previous within-case analyses, this section presents the cross-case analysis. Table
8.3 presents an overview of the value improving practices applied in the various cases. First
181
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?
Case A Case B Case C Case D Case E
Owner Contractor Contractor Contractor Owner
VIP
Performance: Performance: Performance: Performance: Performance:
good good very poor poor good
Project team
building: Having
Yes Yes No Yes Yes
an integrated
project team?
Goal setting Yes Yes Yes Yes Yes
Monitoring
Yes Yes Yes Yes Yes
project goals
Risk
identification Partly Yes Partly Partly Partly
and management
External
No Yes No Partly Partly
benchmarking
Operations
implementation Yes No No Partly Partly
planning
8.3.1 Findings on team design

In four cases (A, B, D and E) the project team was consisting of members of both the
project owner and the contractor. Concerning these four cases, this team composition
beneficially contributed to project performance as it increased efficiency. Reasons
mentioned were that design adjustments/formal scope changes were integrated faster; the
right knowledge was available when crucial data was missing and problems could directly
be solved. Therefore, working in integrated project teams likely contributes to a reduction
of scope changes and to an increase in client satisfaction. The failed case C (building of the
transportation hub) especially illustrates this conclusion. This project did not have an
integrated project team. Integrating the client in the contractors’ team likely would have led
to better interface management by having a better understanding of the project
environment. Supporting our earlier quantitative findings (see Chapter 7), the importance of
integrated project teams, in which the contractor and the project owner closely collaborate,
is evident.
All project teams were multidisciplinary. In two cases (D, E), it was suggested that a team
should be composed by looking at competencies rather than solely at which engineering
disciplines are needed. In four cases (A, B, D and E) it was suggested that having the right
team composition offers the opportunity to engage and manage the stakeholders. The
involvement of the future user, as well as the required specialists (R&D staff) stimulated
alignment and successful project delivery.
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 other’s 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 project’s 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 doesn’t 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
instructions and maintenance requirements operational at the moment of project

commissioning. The construction operators organised site visits and trainings to make the
future users acquainted with the facility. So the case study indicated the following benefits
to the project when applying OIP:
• Reaching start-up time faster,
• Reaching steady state production faster,
• Identifying flaws early,
• Avoiding risks and non-quality.
One case (E) was not prepared sufficiently for start-up, which resulted in a delay in
reaching the targeted production yield. A better preparation could have reduced the delay.
For two other cases (A and D) OIP had a direct positive relation with project performance.
It is noted that mainly project owners seem to initiate effort in this FED activity and
consider this activity vital. The contractor’s horizon does not seem to extend beyond the
execution phase (mechanical completion is very different from operational readiness).
To conclude, operations implementation planning (or preparing for startup) seems an

important contributor to good project performance, not only for the success criteria (i.e.
meeting cost and schedule), but more importantly for the success factors (i.e. trust,
acceptance). Involving the departments of operations and maintenance early in the FED
phases supports the development of trust amongst the parties involved. As a result of that
trust, it seems acceptance for (organizational) change is gained.
8.3.7 Comparing the 5 cases

According to Table 8.3, case D and case E scored similar in the application of the VIPs.
Why then did only one of these cases have a good project performance? Similarly, case A
did not fully apply all VIPs, but still was performing well. Isn’t it useful to use Value
Improving Practices? Our qualitative study suggests that the way of applying VIPs is
crucial. Working according to VIPs with a “tick the box” attitude is not enough: truly
integrated teams, truly investing joint effort in VIPs can make the difference. In such an
integrated team, there should be integration of the owner staff and the project contractor
staff. Note that next to the 6 VIPs investigated in our study, other factors might have had an
influence on project performance.
Two of the projects were performed by the project owners (case A and E), the other three
by contractors. In the contractor cases, two more traditional owner-contractor relations were
observed (case C, D) and one successful long term relationship (case B). In cases C and D,
there was no “true” integration: there was no integrated team at all (case C) or activities
were performed just because “the owner requested” (case D). The poor performance of
these projects is probably at least partially related to the absence of such true integration.
Whereas the earlier quantitative study (Chapter 7) already suggested the relations between
each of the VIPs and project performance, the current qualitative study stresses the
importance of the interplay between the different VIPs (with a central role for the integrated
team!) and how the VIPs are actually applied.
8.4 Team integration pays off

When talking about the application of VIPs in the different projects with the interviewees
during the course of this research, it became clear that besides VIPs, the people involved in
the project play the crucial role in achieving good project performance. They are the ones
186
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).
8.5 Conclusion and recommendations

This chapter aimed to answer the following research question: How do front-end activities
contribute to better project performance? (research question 5 as defined in Chapter 1).
187
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 front-
end 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):

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.
9.1 Final TOE framework

Based on the findings presented in Chapter 6, the TOE framework was slightly adapted.
Some elements were moved to another category, some were reformulated and some were
removed. In the final version of the TOE framework, the T elements represent the potential
complexity causes in the project related to the project scope or the content of the project.
The O elements represent the potential complexity causes in the project related to the
project internal organization. The E elements represent all the potential external complexity
causes in the project, related to external issues or external organizational complexities. The
TOE framework as to be evaluated in this chapter is given in Table 9.1. Note that the
subcategories were removed: these were particularly useful in the development of the
framework.
9.2 Survey design

In this phase of the research, the aim was to collect additional evidence to evaluate the (use
of) the TOE framework. For gathering data from a large number of respondents, a survey is
a suitable research tool and therefore, again a web-based survey was designed (Baarda & de
Goede, 2006; Verschuren & Doorewaard, 1999).
In contrast to the survey described in Chapter 5, which was focussed on the respondents’
view on recently completed projects, this survey focussed on a more general view of the
respondents on projects that they considered to be typical for their sector, the process
industry. This was done to overcome sample problems like those faced in Chapter 5, by
broadening the scope from individual projects to the whole sector. This broad focus was
explicitly mentioned for each question in the survey where this was considered relevant.
First, respondents were asked to indicate their company’s role (owner / contractor / other)
and their experience level (as a project manager and working for their company). Next, the
respondents had to score each of the 47 elements of the TOE framework on their potential
contribution to the complexity of a project (not – little – some – substantial – very much).
190
Chapter 9: Validating the TOE framework
Table 9.1: Final TOE framework, 47 elements in total
Technical Complexity Organizational Complexity External Complexity

(17 elements) (16 elements) (14 elements)
Number of project goals High project schedule drive Number of external stakeholders
Non−alignment of Lack of Resource & Skills Variety of external stakeholders'
project goals availability perspectives
Unclarity of project Lack of Experience with Dependencies on external
goals parties involved stakeholders
Uncertainties in scope Lack of HSSE awareness Political influence
Strict quality Interfaces between different
Lack of company internal support
requirements disciplines
Required local content (forced co-
Project duration Number of financial sources
operation with local parties)
Size in CAPEX Number of contracts Interference with existing site
Number of different
Number of locations Weather conditions
nationalities
Newness of technology Number of different
Remoteness of location
(world−wide) languages
Lack of experience with
Presence of JV partner Lack of experience in the country
technology
Involvement of different time
Number of tasks Company internal strategic pressure
zones
Instability of project environment
Variety of tasks Size of project team (exchange rate, oil price, raw
material price, etc.)
Incompatibility between
Dependencies between
different project management Level of competition
tasks
methods / tools
Uncertainty in methods Lack of trust in project team Risks from environment
Involvement of different
Lack of trust in contractor
technical disciplines
Organizational risks
standards
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 project’s 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
Design−to−Capacity
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.
9.3 Data treatment

9.3.1 Data collection
The study was limited to project managers of four selected companies from the NAP
network. Two of the respondent companies were owner companies and two were contractor
192
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.
Table 9.3: Overview of responses

Group Number of requests Respondents Response rate
Total 111 64 58%
Contractor 35 24 69%
Owner 76 40 53%
While completing the survey, the progress was saved on the participant’s 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.1: Time spent to complete this survey

193
9.3.2 Data analysis

The data obtained in the survey was analyzed using both descriptive and non-parametric
methods in SPSS. Descriptive techniques were used to review the data concerning the
contribution of the individual elements to the project’s complexity. Non-parametric
methods were used to find out group effects: do the owners indeed have a different
perspective on specific complexity elements than the contractors? Non-parametric methods
were needed because of the non-normal distributions in the data. Spearman’s correlations
were calculated to check for the effect of experience.
Qualitative analysis methods (Miles & Huberman, 1994) were used to interpret the results
on how to deal with project complexity and the open questions concerning the use and
development of the framework: the gathered data was transferred from extended text
towards easier interpretable summarized tables and displays. Also manual recoding of the
open answers was performed to investigate the respondents’ general attitude towards the
application and value of the TOE framework (negative, neutral, positive, don’t know).
9.4 Survey results

First some background information on the respondents is provided, after which the
evaluation of the TOE framework is presented including the analysis of the specific owner
and contractor perspectives. Next, it is discussed how the project managers would deal with
the most relevant complexity elements. Finally, the results on the potential use of the TOE
framework are presented.
9.4.1 Respondents work experience

The respondents on average worked longer for the company (median in the category
“between 15 and 20 years”) than their years of experience in project management (median
in the category “between 10 and 15 years”), see Figure 9.2. As could be expected, they
typically did not start their career as a project manager. A highly significant, weak positive
correlation was found between the years of experience as project manager and the years of
working for the company (rs=.337, p=.007, N=64). Figure 9.2 shows that the majority of the
survey respondents did have considerable project management experience (>5 years),
which increases the value of their answers.
Figure 9.2: Years of experience as project manager (left) and at the company (right)
194
9.4.2 Evaluation of the TOE framework

The cumulative scores per element are shown in Figure 9.3.
Figure 9.3: Cumulative element scores, N=64
195
What do the cumulative scores mean?

- A cumulative score of 64 means that 64 respondents indicated “not”,
- a cumulative score of 128 means that 64 respondents on average indicated “little”,
- a cumulative score of 192 means that 64 respondents on average indicated “some”,
- a cumulative score of 256 means that 64 respondents on average indicated
“substantial”,
- and a cumulative score of 320 means that 64 respondents indicated “very much”.
As can be seen in Figure 9.3, no element was scored lower than 128 and only 4 elements
were scored lower than 192 (strict quality requirements, number of different nationalities,
involvement of different time-zones and weather conditions). These lowest scoring elements
could be candidates for removal from the TOE framework, see also the discussion in
Section 9.5. Amongst the highest scoring elements (score > 256) are elements related to
project goals (unclarity and non-alignment), uncertainties in scope, lack of resource and
skills scarcity and a lack of trust in the project team and in the contractor. The vast
majority of the elements were scored between “some” and “substantial”, indicating the
perceived relevance of these elements in their contribution to project complexity.
Subsequently, respondents had to indicate their top-3s of most and least contributing
elements; see Table 9.4 and Table 9.5 for the highest scores and appendix H for all results.
Comparing Figure 9.3 and Table 9.4, all highest scoring elements of Figure 9.3 appear in
the top-3, except for the element lack of trust in the contractor.
Table 9.4: Most contributing elements (max 3 selections per participant)

Most contributing to project complexity Percentage of respondents (N=64)
Technical
Non-alignment of project goals 58%
Uncertainties in scope 56%
Unclarity of project goals 55%
Organizational
Lack of resource and skills availability 70%
Lack of trust in project team 50%
High schedule drive 38%
External
Variety of stakeholders’ perspectives 58%
Lack of company internal support 44%
Interference with existing site 28%
Lack of experience in the country 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
constrained resources. As recent literature highlights, improved project portfolio

management might be needed to optimally distribute the available resources (Laslo, 2010).
The availability of resources and skills is outside the responsibility of the project manager
(Murray, 2009). From the O-complexity elements, also a lack of trust in the project team
was mentioned often (by 50% of the respondents), indicating the importance of obtaining
trust in a project team, which also is stressed in literature (Pinto et al., 2009). For the E-
elements, the element variety of stakeholders’ perspectives was mentioned most often, by
almost 60% of the respondents. This is the only E-element for which such high agreement
was found under the respondents; other elements scored lower than 50%.
Table 9.5 shows the top-3 of most often mentioned elements that would be least
contributing to complexity. This is generally less outspoken (lower percentages):
respondents agreed more on the highest scoring elements. Based on the least contributing
elements in view of more than 50% of the respondents, removal of the following elements
could be considered: involvement of different time zones, number of different nationalities
and weather conditions, see also the discussion in Section 9.5.
Table 9.5: Least contributing elements (max 3 selections per participant)

Least contributing to project complexity Percentage of respondents (N=64)
Technical
Number of tasks 45%
Involvement of different technical standards 45%
Strict quality requirements 34%
Organizational
Involvement of different time zones 64%
Number of different nationalities 56%
Number of financial sources 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)
Mann-Whitney Effect
Element N Significance z
(Test Statistic U) size r
Company internal
64 271 0,001 -3,177 -0,397
pressure
Required local content 64 307,5 0,007 -2,702 -0,338
Organizational risks 64 320 0,017 -2,397 -0,300
Unclarity of project
64 331 0,024 -2,259 -0,282
goals
Variety of external
stakeholders 64 340 0,026 -2,225 -0,278
perspectives
Technical risks 64 631.5 0,023 2,272 0,284
Size in CAPEX 64 622,5 0,037 2,087 0,261
Number of locations 64 613 0,043 2,023 0,253
Instability of project
64 611 0,046 1,992 0,249
environment
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
by enabling constructive discussions between owners and contractors, in which opinions

are shared about the expected complexity aspects of the project.
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 owner’s project is probably considerably larger than the typical size of
a contractor’s 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 (40-
60% 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 company’s 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 goal-
setting 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
204
Figure 9.7: How to deal with project complexity (%): most contributing E-elements
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)
- Don’t 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
Table 9.7: Summary of survey findings on application of the TOE framework

Owners’ responses Contractors’ responses
Answers related to:
(N=40) (N=24)
Risk management 6 11
Project complexity assessment 14 3
Team / stakeholders alignment 9 3
Not useful 3 0
Not applicable 5 1
Don’t know 3 5
Question not well understood 2 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
- “Conducting elements from the framework in team sessions in order to create

awareness and value.”
These responses point towards the creation of shared awareness in the project team by
completing a TOE complexity framework in team sessions and/or review meetings.
Generally, the project owner respondents seem to have a broader view on the application of
the TOE complexity framework: for the contractor respondents often the application was
limited to “as part of risk management” whereas for the owner respondents the application
was wider in “project assessment” of which risk management might be a part. Maybe
sampling issues play a role here as only 2 contractor companies and 2 owner companies
were involved and their views on risk management might be coloured. As can be seen in
Table 9.7, only 3 of the 64 respondents did explicitly perceive the TOE complexity
framework as not useful, another 6 respondents answered “not applicable” and 8
respondents did not know the answer on the question. In general, these results show a
potential for actual application of the TOE complexity framework in practice.
9.4.5 Added value of the TOE complexity framework

A necessary condition to create support for implementation of the new TOE complexity
framework is its value for the people who work with it. Once potential users see the value
of a new tool, it is more likely they will explore it and actually start using it (Briggs, Davis,
Murphy, & Carlisle, 2007; Briggs, Murphy, Carlisle, & Davis, 2009). Although the TOE
complexity framework in its current version is a framework rather than a real tool, the
respondents were asked towards the perceived value of the TOE complexity framework.
The answers on the open question: “What would be the added value of the TOE complexity
framework, if any?” were more difficult to categorize, since they were less outspoken than
the answers on the question about the application of the framework. Respondents seemed to
have difficulties in distinguishing application and added value of the TOE complexity
framework. After first integral analysis, the categories as shown in Table 9.8 were defined.
Table 9.8: Summary of survey findings on added value of the TOE complexity
framework
Owners’ responses Contractors’ responses
Answers related to:
(N=40) (N=24)
Better alignment 6 2
Structured approach 8 4
Communication with stakeholders 4 0
Support decision making 5 3
Identify priorities 4 3
Integrate 0 3
Awareness 1 2
No added value 2 2
Not applicable 2 1
Don’t know 7 5
Question not well understood 3 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
- "Key element of a project is good alignment in all aspects and disciplines, to my
opinion that's what project management is about. TOE could be a tool to create
awareness for (mis)alignment and contribute to improved alignment. That's what I
guess. I have no experience in using TOE tool."
- “It is a good tool for communication with a wide variety of stakeholders about the
specific project.”
In the latter response, the owner expressed a view which is outward oriented: focussed on
communicating with the wide variety of stakeholders involved.
Next to the focus on achieving alignment and better communication, in view of the owner
respondents also the structured approach of the TOE complexity framework adds value to
the project:
- “The added value must be in the systematic approach towards project complexities”
- “It enables to have a structured approach towards risk mitigation and provides a good
indication of the progress and challenges within the project.”
Subsequently, next to current risk assessment practices, the value of using the TOE
complexity framework could be:
- "Added value is next to a risk assessment, where we normally identify a number of the
mentioned issues; would be:
o method is quick and can be filled out by all project team members
o quick method to summarize the identified risks
o top five list for focus on project, including severity indication of the subjects."
- "Increase risk awareness and support Risk management. Support VIP selection.
Support decision making wrt project staffing/ required competencies"
Here the focus is on prioritization of potential complexities and selection of the activities to
undertake to treat these complexities. One of the actions would be to staff the project
accordingly, which is in-line with earlier publications on matching the project manager’s
competences on the particular project complexity (Bosch-Rekveldt et al., 2009b; Thomas &
Mengel, 2008).
In addition to these owner views, some contractors’ opinions were:

- “It provide some structure to the assessment of project complexity”
- “Controlling the project, awareness of potential issues.”
- “It is essentially a Risk Management Framework combined with Mitigation
strategies. This is very important.”
- “In case organizations do not use a structured approach to risk management, it
will for sure add value to help them assess a project and develop (upfront) a plan
to deal with its complexities”
- “A framework that enables the project team to make the hidden issues and risk
visible”
Generally, the contractor opinions seem more “internally” oriented. Whereas for the project
owners, the value of TOE is also in stakeholder management, value in this area seems not
recognized by the contractor respondents. To a large extent, this can be related to the
“traditional” role difference between contractors and owners: for contractors the project
owner is the one and only important stakeholder and not considered “a stakeholder” but just
“the project owner”. Stakeholders, other than the project owner, are less of a contractor’s
concern.
As can be seen in Table 9.8, only 4 of the 64 respondents did not see any value of applying
the TOE complexity framework. Another 3 respondents answered “not applicable” and 12
209
respondents did not know the answer on this question. The 12 “don’t 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
Chapter’s 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
other’s 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.
9.5 Discussion and conclusions

This chapter aimed to answer how a framework to grasp project complexity could be used
to improve project performance (research question 7 from Chapter 1). Such a framework
can only successfully be used when it really grasps a project’s complexity; therefore it was
investigated first to what extent the various elements do contribute to project complexity.
211
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 T-
category 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
Turner’s 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
Figure 9.8: Visual representation of the final TOE framework
9.5.2 Treating project complexity

The respondents could select which of 12 selected value improving practices (VIPs) they
would apply to treat elements of project complexity that – in their view- contributed most to
project complexity. For some of the complexity elements, the proposed treatment was
obvious, for example the complexity element non-alignment of project goals would be
treated by the VIP “goal setting and alignment” by 33 of the 37 respondents for which this
complexity element was in the top-3 of complexity elements. However, for other elements
suggested treatment was more disperse, such as uncertainties in scope or a lack of resource
and skills availability, although some VIPs seem applicable to solve all complexities.
A particular VIP related to resource availability, particular in a project portfolio context,

seems missing. Such a VIP could be beneficial in treating one of the most contributing
elements to project complexity: a lack of resource and skills availability.
Overall looking at the results, it seems that the VIPs goal setting & alignment, stakeholder
management, risk management and project team building would be most widely applied.
213
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 owner’s perspective versus a contractor’s 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 project’s
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
Chapter 10: Discussion, conclusions and recommendations
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 (Söderlund, 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 project’s 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
10.1.3 Limitations of the research

Limitations of the research are in the high number of variables under consideration (40
front-end variables, 3 aggregated complexity variables) in the Phase II survey (Chapter 5)
and the limited number of projects available in the sample (67 projects) to apply statistics.
Given the high number of variables, more data should be gathered to more firmly underpin
the current results. More data could come from within the NAP network, but also expansion
towards other types of projects or sectors could be considered to investigate generalization
opportunities, see also Section 10.3.2. As a result of gathering more data, also shift in
results might be expected since current insignificant differences might become significant.
Hence, also the resulting TOE framework needs further development and regular updates.
In the exploratory phase of the study, Chapter 3, primary attention was given to the project
owner perspective, but as the later phases of the research showed, contractors do
(inherently) have different perceptions on the concepts under study. Therefore inclusion of
the contractors’ perspective earlier in the research potentially could have resulted in
different front-end activities to be taken into account in the survey, although in this phase
contractors typically do not have the dominant role.
Another limitation of this kind of research is the difficulty of objectively operationalizing

and quantifying effort spent in front-end activities. And even if one could measure this
effort objectively, data interpretation is difficult because of the unique character of projects,
by definition. Recent research assessed the use of project management practices (Papke-
Shields et al., 2010) by investigating the product or artefact resulting from a project
management practice, rather than the practice itself. Such an approach indeed could help in
objectively quantifying effort spent in front-end activities, but does not give information on
the quality of application.
A fourth limitation is in the subjective character of “project complexity”. Dependent on

experience, personal character, company culture, etc., everyone has a different connotation
of “project complexity”. The subjective character was deliberately included and explicitly
given attention in the research, by carefully formulating survey and interview questions and
including for example multiple persons per case (Phase I en Phase III), but still it has
consequences for the application of the complexity framework, which is one of the main
results of this research. The importance of the context, however, is aligned with the
intended constructivist character of the research. Next to the inherent subjective character
of “project complexity”, another related limitation is that the dynamic character of project
complexity is currently only taken into account by repeated application of the TOE
framework in the different project phases.
A fifth limitation of this research is the assumed soundness of the project management
process in the projects and companies under study. From Chapter 5 onwards, the attention
was focused on value improving practices (besides some relevant front-end activities
resulting from the case studies); as those were the (assumed) practices that can make the
difference. When no sound project management process is in place, however, application of
value improving practices might be “beyond horizon”.
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:
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.

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 respondent’s 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

In Chapter 4, it was shown that project complexity has numerous causes. Comparing
literature findings and case study findings resulted in a detailed framework to grasp project
complexity in which “hard” and “soft” factors were present. Based on 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.). 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).
After the development of the framework in Chapter 4 (Phase I), some iteration took place
on the framework in Chapter 6 (Phase II) and Chapter 9 (Phase IV). Results from the
quantitative survey in Chapter 6 delivered us the evidence that project complexity indeed
can be seen as a construct that contains several and various components, which are worth to
distinguish. Finally, in Chapter 9 the developed TOE framework was validated by asking
the 64 respondents to score all elements for their potential contribution to project
complexity in projects in the process industry. Based on this validation, the final TOE
framework was presented with 47 elements as given in Figure 9.8, page 213 of this
dissertation.

From Chapter 6 (Phase II) it was concluded that indeed project complexity negatively
influenced project performance in the samples that were studied, distinguishing the
technical, organizational and external dimensions of project complexity. 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. Note that several of these elements, most influential to improve
project performance, were also experienced as most contributing to project complexity in
Chapter 9 (Phase III): goals / scope related, lack of resource availability and a lack of
company internal support. These elements need more serious attention in the project to
improve project performance.
From the exploratory case studies in Chapter 3 (Phase I) 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.
From the survey results in Chapter 7 (Phase II), some front-end activities showed a
significant correlation with (dimensions of) project complexity:
complexity)
222
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.

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
particular front-end activities might be beneficial. Following a contingency approach,

moderated relations between front-end activities, project complexity and project
performance were looked for, next to the direct relations between front-end activities and
project performance and project complexity and project performance. One significant
moderated relationship was found: risk management was influencing project performance,
moderated by technical and external complexity. In case of technically and or externally
highly complex projects, more risk management would be needed to improve project
performance.

performance?
As concluded from Section 6.5, the respondents in Phase II largely agreed with our
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 (Chapter 6).
The TOE framework to grasp project complexity, as developed and validated in Chapter 9
(Phase IV), could be used in early project phases to identify the areas in which complexity
is expected to arise. This complexity assessment could be repeated at the different stage
gates. Practitioners throughout the study 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, 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.
Having answered all sub-questions, now time has come to answer the main question:
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
front-end activities and value improving practices. From our empirical data, we conclude
some particularly important front-end activities, see Figure 7.3 on page 158. 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. This importance of team integration was concluded from the
different phases in the study particularly the explorative case studies in Phase I and the
explanatory case studies in Phase III.
10.2.2 Overall conclusions

As the inaugural speech of professor Bakker already stated: management of projects is a
people process (Bakker, 2008). In the course of this dissertation, this theme frequently
popped up: the people involved in the project make or break the project. This was
mentioned in the exploratory case studies (Chapter 3), became clear from the survey results
on the importance of team building (Chapter 7), was again stressed in the third phase case
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 manager’s 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 front-
end “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 Front-
End 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., & Wikström, 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
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.
Käkönen, 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., Pannenbäcker, 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
CII. 2009. Construction Industry Institute Best Practices, http://www.construction-
institute.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
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.
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
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
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. Göttingen: 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.
Hyväri, 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
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., & Grønhaug, 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.
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): 740-
750.
Kutsch, E., & Hall, M. 2010. Deliberate ignorance in project risk management.
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.
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.
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 pre-
construction 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.
Müller, R., & Turner, J. R. 2005. The impact of principal-agent relationship and contract
type on communication between project owner and manager. International
Müller, 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): 522-
538.
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
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., & Wikström, 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
Pinto, J. K. (Ed.). 1988. The Project Management Institute - Project Management

Handbook (1st ed.). San Fransisco: Jossey-Bass.
Pinto, J. K. 2004. The Wiley Guide to Managing Projects: John Wiley and Sons.
Pinto, J. K., Slevin, D. P., & English, B. 2009. Trust in projects: an empirial assessment of
owner/contractor relationships. International Journal of Project Management,
27(6): 638-648.
PMI. 2004. A Guide to the Project Management Body of Knowledge (Third ed.): Project
Management Institute.
Pollack, J. 2007. The changing paradigms of project management. International Journal of
Porter, S. R., & Whitcomb, M. E. 2007. Mixed-mode contacts in web surveys: paper is not
necessarily better. Public Opinion Quarterly, 71(4): 635-648.
Pryke, S., & Smyth, H. J. 2006. The Management of Complex Projects. A Relationship
Approach. London: Blackwell Publishers.
Pugh, D. S., Hickson, D. J., Hinings, C. R., & Turner, C. 1969. Context of organization
structures. Administrative Science Quarterly, 14(1): 91-114.
Raz, T., Shenhar, A., & Dvir, D. 2002. Risk management, project success, and
technological uncertainty. R&D management, 32(2): 101-109.
Remington, K., & Pollack, J. 2007. Tools for Complex Projects. Aldershot: Gower
Publishing Company.
Roy, B. 2005. Paradigms and challenges. In J. Figueira, S. Greco, & M. Ehrogott (Eds.),
Multiple Criteria Decision Analysis: State of the Art Surveys, Vol. 78. New York:
Springer.
Santana, G. 1990. Classification of construction projects by scales of complexity.
Sauser, B. J., Reilly, R. R., & Shenhar, A. J. 2009. Why projects fail? How contingency
theory can provide new insights – A comparative analysis of NASA’s Mars
Climate Orbiter loss. International Journal of Project Management, 27(7): 665-
679.
Scholten, V. E., Mooi, H. G., & Wijngaard, P. J. M. 2010. The influence of the gap
between project manager and exectutives on project results, PMI Research and
Education Conference 2010. Washington.
Schoonhoven, C. B. 1981. Problems with contingency theory - Testing assumptions hidden
within the language of contingency theory. Administrative Science Quarterly,
26(3): 349-377.
Shenhar, A. J. 1998. From theory to practice: Toward a typology of project-management
styles. IEEE Transactions on Engineering Management, 45(1): 33-48.
Shenhar, A. J. 2001. One size does not fit all projects: Exploring classical contingency
domains. Management Science, 47(3): 394-414.
Shenhar, A. J., & Dvir, D. 1996. Toward a typological theory of project management.
Research Policy, 25(4): 607-632.
Shenhar, A. J., & Dvir, D. 2004. How projects differ and what to do about it. In P. W. G.
Morris, & J. A. Pinto (Eds.), The Resource Book on the Management of Projects.
New York: John Wiley.
Shenhar, A. J., & Dvir, D. 2007a. Project management research: the challenge and
opportunity. Project Management Journal, 38(2): 93-99.
Shenhar, A. J., & Dvir, D. 2007b. Reinventing Project Management: The Diamond
Approach to Successful Growth and Innovation. Boston, Massachusetts: Harvard
Business School Press.
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
Söderlund, J. 2004a. Building theories of project management: past research; questions for
the future. International Journal of Project Management, 22(3): 183-191.
Söderlund, 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.
Söderlund, 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): 74-
87.
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
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
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
Turner, J. R., & Mueller, R. 2003. On the nature of the project as a temporary organization.
Turner, J. R., & Simister, S. J. (Eds.). 2000. Gower Handbook of Project Management (3rd
edition ed.). Aldershot: Gower Publishing Limited.
Turner, R. J., & Müller, 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
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).
Williams, T. M. 1999. The need for new paradigms for complex projects. International
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
APPENDIX B: INTERNET SURVEY PHASE II (CHAPTER 5) .............................. 247
APPENDIX C: TRANSLATION TABLE: TOE ELEMENTS & SURVEY

QUESTIONS (CHAPTER 5) .......................................................................................... 256
APPENDIX D: CORRELATION RESULTS TOE ELEMENTS & DETAILED

ANALYSIS (CHAPTER 6) ............................................................................................. 259
D.1: CORRELATION OF T-ELEMENTS AND PERCEIVED COMPLEXITY ..... 268
D.2: CORRELATION OF O-ELEMENTS AND PERCEIVED COMPLEXITY ..... 274
D.3: CORRELATION OF E-ELEMENTS AND PERCEIVED COMPLEXITY ..... 285
D.4: SUMMARY OF ELEMENT EVALUATIONS .................................................... 292
APPENDIX E: REQUIRED ELEMENT TRANSFORMATIONS (CHAPTER 6)... 294
APPENDIX F: INTERVIEW QUESTIONS PHASE III (CHAPTER 8) ................... 296
APPENDIX G: INTERNET SURVEY PHASE IV (CHAPTER 9) ............................ 299
APPENDIX H: ELEMENTS MOST/LEAST CONTRIBUTING TO PROJECT

COMPLEXITY PHASE IV (CHAPTER 9) .................................................................. 304
243
APPENDIX A: List of interview questions explorative case
studies (Chapter 3)
Category ID Question
a_100 Which project
a_101 Name interviewee
a_102 Business card for contact details
a_101_1 Gender
a_101_2 Nationality
a_101_3 Engineering background?
a_101_4 Worked at which companies?
a_101_5 Other projects were you involved in / roles you had within Shell?
a_103 Years of project experience in total
a_104 Role in this project
a_105 Objective of the project
a_106 In which project phase were you involved in the project
Details
(month/year)?
participant
/project a_107 What was your role in estimation (cost, schedule)?
(~10 min) a_108 How was the co-operation with the business developer and asset
developer (operations manager) - integrated over the phases or
"sequential"?
a_109 Which parties were involved in the project (client, partners, main
contractors, government, ngo's etc)
a_110 In which phase(s) were the different parties involved?
a_111 What is (an indication of) the number of persons involved per party over
the different phases (ramp up / ramp down)?
a_112 How experienced were the project parties in their respective tasks?
a_113 Was there a lot of interaction between parties, which parties?
a_114 Was there a lot of interaction between tasks (sequential, pooled,
reciprocal), which tasks?
a_115 How was the project classified in terms of risk - consequences &
probability (Low/Mid/High)?
b_100 Do you consider this project (overall; FED&execution) as

successful? (yes /no)
b_101 In what way do you consider the project as successful?
b_102 Did you meet the 5 project promises (cost, schedule, scope, quality and
HSSE)?
b_103 How difficult was it to meet these promises?
b_104 Did the project introduce new technology or open a new market, how?
b_105 Were the parties involved satisfied with the project result?
b_106 Did any scope change play a role in the project execution?
b_107 If scope change occurred; when, why and how?
b_108 If scope change occurred; which parties played a role in the scope
Project
change, how?
result
b_109 If scope change occurred: how did you manage the scope change?
(~10 min)
b_110 If scope change occurred: what were the consequences of the scope
change?
b_111 Would you characterize the project as cost driven or schedule driven?
b_112 Were the cost estimates realistic, what did mainly drive the estimates?
b_113 Were the schedule estimates realistic, what did drive the estimates for
this project?
b_114 What was the role of governance in achieving the project result (steering
team, decision reviews, etc)?
b_115 Was there any rework necessary? Which project phase(s) and by
whom?
b_116 What particular difficulties or problems did you encounter during
the project that impacted the project result?
244
Appendix A: Interview questions (Chapter 3)
c_100 Would you consider your project as complex? (yes / no)

c_101 What is your definition of project complexity?
c_102 In what way would you consider your project as complex; please
distinguish different aspects?
c_103 TECOPS categories - Technical. Which elements contributed to
the project complexity? (continue with: what do you mean, who
involved, how dealt with, etc)
c_104 TECOPS categories - Economical. Which elements contributed to
c_105 TECOPS categories - Commercial. Which elements contributed to
c_106 TECOPS categories - Organizational. Which elements contributed
Project to the project complexity? (continue with: what do you mean, who
complexity involved, how dealt with, etc)
(~30 minutes) c_107 TECOPS categories - Political. Which elements contributed to the
project complexity? (continue with: what do you mean, who
c_108 In addition to TECOPS categories - HSSE. Which elements
contributed to the project complexity? (continue with: what do
you mean, who involved, how dealt with, etc)
c_109 How did the aspects of project complexity, just mentioned by you,
influence eachother?
c_110 What aspects contributed most to the complexity of this project
(max 5)?
c_111 On a 1-5 scale (1=least complex, 5=most complex) assess the
project's complexity per aspect, including its type
(technological/organizational/complexity of environment)
c_112 Did the overall complexity of the project change over its lifecycle?
c_113 If yes, how, for the main aspects of project complexity?
c_114 How did the project complexity influence the project result?
d_100 What is, in your view, the value of the FED for your project?
d_101 How did you adapt, in FED (1,2,3) your project to the project
complexity - most contributing aspects?
d_102 How did this influence the project result?
d_103 If FED was not adapted, how could you have adapted your FED to
this element?
d_104 How could this have influenced the project result?
Front end
d_105 Two main management approaches are: fully plan (to anticipate)
development
versus prepare to adapt (to be resilient). Which was predominant
(~15 min)
in your project?
d_106 Why this approach (or combination of approaches)?
d_107 Why (or why not) did the approach work for your project?
d_108 How did you apply "fit for purpose" during the FED process?
d_109 In hindsight, could you suggest changes in the FED related to the
processes in order to improve the project result?
d_110 In hindsight, could you suggest changes in the FED related to the
content in order to improve the project result?
e_100 In general: what topics should be investigated asap to improve the

Closure project result and why?
(~5min) e_101 How could this link to the management of project complexity?
e_102 Anything else you would like to bring to the table?
e_103 Thanks for participation; I'll write a report, do you want to review this
report?
245
246
APPENDIX B: Internet survey PHASE II (Chapter 5)
247
248
Appendix B: Internet survey (Chapter 5)
249
250
251
252
253
254
255
APPENDIX C: Translation table: TOE elements & survey
questions (Chapter 5)
ID Element name Survey question
elm_TG1 Number of goals 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 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
elm_TG3 Clarity of goals 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
elm_TS1 Scope largeness 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
Uncertainties in detailed. On a scale from 0% (rough design) to 100% (fully detailed design) please
elm_TS2 scope 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
Quality reference to the standard in the discipline? (Extraordinary low, Lower than normal,
elm_TS3 requirements 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.
elm_TT1 Number of tasks 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
elm_TT2 Variety of tasks 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
Dependencies or may not rely on outcomes of other WPs. To what extent were the WPs in this project:
elm_TT3 between tasks 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,
Uncertainty in Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know)
elm_TT4 methods There was uncertainty in the technical methods to be applied
Interrelations 34A. To what extent: Did technical processes in this project have interrelations with
between technical existing processes? (Not, Little, Substantial, Do not know)
elm_TT5 processes
36. Different types of technical standards might apply on a project, such as design
Conflicting norms standards and country specific norms. Did the project experience conflicting norms? (No,
elm_TT6 and standards Little, Yes, Do not know)
Newness of 34B. To what extent: Did the project make use of new technology, e.g. non−proven
technology technology? (Not, Little, Substantial, Do not know)
elm_TE1 (world-wide)
46B. Please indicate the answer that applies best to this project. ( Strongly disagree,
Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
Experience with The parties involved had applied the technology involved in the project before in similar
elm_TE2 technology situations
46P. Please indicate the answer that applies best to this project. ( Strongly disagree,
I considered the project being high risk (number, probability and/or impact of) in terms of
elm_TR1 Technical risks technical risks
256
Appendix C: TOE elements in survey (Chapter 5)

OS1 Project duration 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 of
compatibility issues, Little compatibility issues, Substantial compatibility issues, Do not know).
different project
OS2 38. Different parties in a project might use different project management tools (MS−Project,
management
Primavera, Palisade @risk, etc). Did you expect compatibility issues regarding the project
methods and tools
management tools to be used in this project on beforehand?
(No compatibility issues, Little compatibility issues, Substantial compatibility issues,
Do not know).
OS3 Size in CAPEX 11. What was the estimated capital expenditure of this project?
Size in Engineering 12. What was the expected total amount of man−hours in this project? (a rough estimate is
OS4
hours sufficient)
16. What was the approximate maximum number of people working simultaneously on the
OS5 Size of project team
project (including workers)?
23. What was the size of the area that the scope of the project had to deal with? (a rough
OS6 Size of site area
estimate is sufficient)
22. What was the total number of project sites (locations), including contractor locations, where
Number of
OS7 work for this project was performed? (All at 1 location, 2 to 4 locations, 5 to 9 locations, > 9
locations
locations, Do not know)
10. Please indicate to what extent this project was driven by the following factors or
ORE1 Project drive 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
Resource & Skills
ORE2 availability, Do not know)
availability
- Materials and equipment (All available, Minor difficulties with availability, Major
difficulties with availability, Do not know)
Experience with 39. Prior to this project, my company had worked with this project's (all parties indicated in
ORE3
parties involved 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
ORE4 HSSE awareness 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
Interfaces between between the different disciplines that potentially could have lead to interface problems in this
ORE5
different disciplines 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%, 1−20%, 21−40%,
Number of 41−60%, 61−80%, 81−99%, 100%, Do not know):
ORE6
financial resources 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,
ORE7 Contract types
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)
Number of different 43. What was the number of different nationalities involved in the project team with a
OP1
nationalities substantial contribution to the project? (1, 2 to 5, 5 to 10, >10, Do not know)
Number of different 44. How many different languages (written and spoken) were used in the project team for work
OP2
languages 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?
Co-operation JV
OP3 (JV partner(s), Consortium partner(s), Project owner, Managing contractor, (Engineering)
partner
Contractor(s), Subcontractor(s), Other, please specify)
24. How many overlapping hours did this project have because of different time-zones
Overlapping office
OP4 involved? (7 or 8 overlapping office hours, 5 or 6 overlapping office hours, 3 or 4 overlapping
hours
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,
Trust in project Neutral, Agree Strongly agree, Not Applicable, Do not know).
OT1
team 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
OT2 Trust in contractor (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).
OR1 Organisational risks
I considered the project being high risk (number, probability and/or impact of) in terms of
organizational risks
257

45. Counted in the number of groups “around the table” in the project (e.g. project team
Number of counts for one, local government counts for one, each contractor counts for one, etc),
ES1 stakeholders what was the total number of stakeholders for this project?
Variety of 46C. Please indicate the answer that applies best to this project. (Strongly disagree,
stakeholders' Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
ES2 perspectives Different stakeholders had different perspectives
46D. Please indicate the answer that applies best to this project. (Strongly disagree,
Dependencies on Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
ES3 other stakeholders My company was very dependent on the other stakeholders
46E. Please indicate the answer that applies best to this project. (Strongly disagree,
ES4 Political influence The political situation in the country did influence the project
46F. Please indicate the answer that applies best to this project. (Strongly disagree,
Company internal My company's business representatives and the senior management supported the
ES5 support project throughout
25. In some countries, you can only win the project when you will involve local parties; the
so−called required local content of the project. To what extent of the project budget, local
Required local content was obligatory in this project? (No local content required, Little local content
ES6 content required, Substantial local content required, Not applicable, Do not know)
46G. Please indicate the answer that applies best to this project. (Strongly disagree,
Interference with The project faced interference problems with previous use of the area or existing
EL1 existing site products/projects
46K. Please indicate the answer that applies best to this project. (Strongly disagree,
EL2 Weather conditions We expected extreme weather conditions to influence the project progress
46L. Please indicate the answer that applies best to this project. (Strongly disagree,
Remoteness of Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
EL3 location 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,
Experience in the Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
EL4 country 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,
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,
Internal strategic For this project, there was pressure from the business department in my company to
EM1 pressure deliver faster
46M. Please indicate the answer that applies best to this project. (Strongly disagree,
Stability project The project had to deal with fluctuating environment (such as exchange rates, raw
EM2 environment material pricing, oil prices, etc).
46N. Please indicate the answer that applies best to this project. (Strongly disagree,
Level of Disagree, Neutral, Agree Strongly agree, Not Applicable, Do not know).
EM3 competition The project was to be run in a highly competitive market
46R. Please indicate the answer that applies best to this project. (Strongly disagree,
Risks from I considered the project being high risk (number, probability and/or impact of) in terms of
ER1 environment environmental risks
258
APPENDIX D: Correlation results TOE elements & detailed
analysis (Chapter 6)
Spearman’s rho correlation results for all T, O and E elements are given in the subsequent
pages:
T-elements O-elements E-elements

T- elements Page 260 Page 261 Page 262
O- elements Page 263 Page 265
E- elements Page 267
Each cell shows:

Correlation Coefficient
Significance (2-tailed)
N
Subsequently, all elements and their correlations are discussed in detail (Appendix D.1 to
Appendix D.3), and summarized in Table D.4 (Appendix D.4).
259
260
Appendix D: Correlation table TOE elements (Chapter 6)
261
262
263
264
265
266
267
D.1: Correlation of T-elements and perceived complexity

All correlation results between the T-elements of the TOE framework and perceived
complexity are shown in Table D.1. Also, for all T-elements a summary of the findings is
given, followed by the interpretation of the results.
c
Table D.1: Correlations T-elements and perceived complexity

Correlation Coefficient .227† -.040 .113
elm_TG1:
Sig. (2-tailed) .065 .747 .366
number of goals
N 67 67 66
elm_TG2:
Sig. (2-tailed) .783 .000 .342
unaligned goals
N 66 66 65
Correlation Coefficient -.070 .212† .092
elm_TG3:
Sig. (2-tailed) .575 .085 .464
unclear goals
N 67 67 66
Correlation Coefficient .026 .124 .049
elm_TS1:
Sig. (2-tailed) .875 .446 .768
scope largeness
N 40 40 39
Correlation Coefficient -.025 .211(†) .024
elm_TS2:
Sig. (2-tailed) .847 .102 .855
uncertainties in scope
N 61 61 60
Correlation Coefficient .357**** .113 .234†
elm_TS3:
Sig. (2-tailed) .003 .364 .059
quality requirements
N 67 67 66
Correlation Coefficient -.024 .049 -.139
elm_TT1:
Sig. (2-tailed) .875 .745 .357
number of tasks
N 47 47 46
elm_TT2:
Sig. (2-tailed) .212 .739 .472
variety of tasks
N 58 58 57
Correlation Coefficient .219(†) .100 .087
elm_TT3:
Sig. (2-tailed) .102 .457 .522
dep. between tasks
N 57 57 56
Correlation Coefficient .270* .223† .045
elm_TT4:
Sig. (2-tailed) .028 .071 .720
uncertainty in methods
N 66 66 65
elm_TT5: Correlation Coefficient .073 -.142 -.150
interrelations between Sig. (2-tailed) .561 .258 .235
technical processes N 65 65 64
elm_TT6: Correlation Coefficient .124 .304* .089
conflicting norms and Sig. (2-tailed) .328 .015 .487
standards N 64 64 63
Correlation Coefficient .240† .232† .017
elm_TE1:
Sig. (2-tailed) .054 .063 .893
newness of technology
N 65 65 64
elm_TE2: Correlation Coefficient .131 .165 .008
lack of exp with Sig. (2-tailed) .295 .184 .949
technology N 66 66 65
Correlation Coefficient .534** .298* .076
elm_TR1:
Sig. (2-tailed) .000 .015 .549
technical risks
N 66 66 65
† Correlation is significant at the 0.1 level (2-tailed)
268
TOE Sub-ordering ID Elements defined Correlation result Action proposed

T Goals TG1 Number of goals T† 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.

T Goals TG2 Unaligned goals O** Use data
T Goals TG3 Unclear goals O† Use data
The element unaligned goals (elm_TG2) shows a moderate correlation to perceived

organizational complexity (rs=.507 p =.000). Although the element unaligned goals was
intended to be “content” related, hence contributing to technical complexity, whether or not
project goals are aligned has obvious implications for the organizational complexity in view
of the respondents. The same but to a lesser extent holds for the element unclear goals
(elm_TG3). This element showed a weak, hardly significant, positive relation with, again,
organizational complexity (rs =.212, p=.085), not with the expected perceived technical
complexity. Hence the respondents perceive goal-issues (either related to clarity or to their
alignment) as having implications for organizational complexity. However, since the
elements in the TOE framework were clustered in causes for project complexity and not in
implications of complexity, no move of these elements to the O-category was considered.
The elements unaligned goals and unclear goals were significant, positive correlating to
each other with a moderate strength (rs=0.599, p=0.000). Although both elements share a
number of significant, positive correlations with elements such as conflicting norms and
standards, lack of HSSE awareness, organizational risks, variety of stakeholder’s
perspectives and dependencies on other stakeholders, combination of these elements is not
yet considered: unaligned goals and unclear goals address different aspects contributing to
complexity. The obtained data could be used in the current analysis.

Do not use data,
T Scope TS1 Scope largeness - 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 doesn’t
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.

Use data, rephrase
T Scope TS2 Uncertainties in scope O† 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.

T Scope TS3 Quality requirements T**, E† Use data
The element quality requirements (elm_TS3) shows a weak positive correlation to

perceived technical complexity (rs = .357, p=.003) and a weaker and less significant
correlation to perceived environmental complexity (rs = .234, p=.059). This element
showed only a few significant correlations to other TOE elements of which the correlation
to technical risks (rs = .319, p=.009) and the negative correlation to lack of HSSE
270
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.

Do not use data,
rephrase survey
T Tasks TT1 Number of tasks - 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 doesn’t 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 element’s 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.

Do not use data,
rephrase survey
T Tasks TT2 Variety of tasks - 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

Dependencies Use data, rephrase
T Tasks TT3 between tasks T† 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.

T Tasks TT4 Uncertainty in methods T* Use data
The element uncertainty in methods (elm_TT4) shows a weak positive correlation to

perceived technical complexity (rs = .270, p=.028). This element shows weak to moderate
positive correlations to elements such as uncertainties in scope, newness of technology, lack
of experience with technology, technical risks, compatibility of different project
management methods and tools, interfaces between different disciplines, organizational
risk and variety of stakeholder’s perspectives. An increase in the uncertainty in methods
coincides with more uncertainties in scope, application of new technology, no experience
with technology, higher technical risks, compatibility problems with project management
methods and tools, interface problems between different disciplines, higher organizational
risks and more varied stakeholder’s perspectives, which all seem logical. The obtained data
for this element can be used in the current analysis.
Correlation
TOE Sub-ordering ID Elements defined result Action proposed
Do not use data, re-
Interrelations between phrase survey
T Tasks TT5 technical processes - 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

Conflicting norms
T Tasks TT6 and standards 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.

Newness of
technology (world-
T Experience TE1 wide) T†, O† Use data
The element newness of technology (world-wide) (elm_TE1) shows weak positive

correlations to both perceived technical complexity (rs=.240, p=.054) and perceived
organizational complexity (rs =.232, p=.063). This element shows a moderate positive
correlation to the other technical experience related element: lack of experience with
technology (rs=.472, p=.000): increased application of new technology coincides with a
lack of experience with technology. Also weak to moderate correlations are found with
uncertainties in methods, technical risks, compatibility of project management methods and
tools, and number of stakeholders involved. Increased application of new technology
coincides with more uncertainties in methods, higher technical risks, more compatibility
issues with project management methods and tools and more stakeholders involved.
Despite the ‘technical’ character of this element, also its implications in the organizational
area seem to be recognised by the respondents. The cause of the complexity, however, is
more content and thus technically oriented and this element should therefore stay in the T-
category. The obtained data for this element can be used in the current analysis.

Lack of experience Use data, rephrase
T Experience TE2 with technology - 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.

T Risk TR1 Technical risks T**, O* 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

Use data, move to T-
O Size OS1 Project duration T† category
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 T-
category and the obtained data can be used in the current analysis.
Action
TOE Sub-ordering ID Elements defined Correlation result proposed
Compatibility of different
project management
O Size OS2 methods and tools 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
Table D.2: Correlations O-elements and perceived complexity
Correlation Coefficient .205† -.004 .145
elm_OS1:
Sig. (2-tailed) .097 .975 .245
project duration
N 67 67 66
elm_OS2: Correlation Coefficient .187 .478** .262*
compatibility PM methods Sig. (2-tailed) .132 .000 .035
and tools N 66 66 65
Correlation Coefficient .013 .117 .051
elm_OS3:
Sig. (2-tailed) .921 .361 .693
size in CAPEX
N 63 63 63
Correlation Coefficient .036 .022 -.123
elm_OS4:
Sig. (2-tailed) .808 .880 .409
size in eng. hours
N 48 48 47
Correlation Coefficient .092 .301* .103
elm_OS5:
Sig. (2-tailed) .505 .026 .455
size of project team
N 55 55 55
Correlation Coefficient -.148 .138 .051
elm_OS6:
Sig. (2-tailed) .233 .267 .686
size of site area
N 67 67 66
Correlation Coefficient .031 .207† -.001
elm_OS7:
Sig. (2-tailed) .804 .092 .992
number of locations
N 67 67 66
Correlation Coefficient .055 .226† .270*
elm_ORE1:
Sig. (2-tailed) .659 .066 .028
project drive
N 67 67 66
elm_ORE2: Correlation Coefficient .004 .447** .136
resource and skills Sig. (2-tailed) .975 .000 .275
scarcity N 67 67 66
elm_ORE3: Correlation Coefficient .080 .161 .037
lack of exp with parties Sig. (2-tailed) .525 .201 .770
involved N 65 65 64
Correlation Coefficient -.120 .224† -.015
elm_ORE4:
Sig. (2-tailed) .351 .078 .906
lack of HSSE awareness
N 63 63 62
Correlation Coefficient .240† .534** .130
elm_ORE5: interfaces
Sig. (2-tailed) .050 .000 .299
between diff disciplines
N 67 67 66
elm_ORE6: Correlation Coefficient .052 .057 -.036
number of financial Sig. (2-tailed) .682 .657 .782
resources N 64 64 63
elm_ORE7:
Sig. (2-tailed) .346 .492 .433

contract types
N 61 61 60
elm_OP1: Correlation Coefficient .117 .189 -.087
number of different Sig. (2-tailed) .346 .126 .490
nationalities N 67 67 66
Correlation Coefficient .005 .255* -.170
elm_OP2:
Sig. (2-tailed) .965 .038 .172
number of diff languages
N 67 67 66
Correlation Coefficient .133 .144 .228†
elm_OP3:
Sig. (2-tailed) .283 .243 .065
co-operation JV partner
N 67 67 66
Correlation Coefficient .114 -.008 .029
elm_OP4: overlapping
Sig. (2-tailed) .365 .948 .823
office hours
N 65 65 64
elm_OT1: Correlation Coefficient .057 .043 -.024
lack of trust in project Sig. (2-tailed) .648 .734 .846
team N 66 66 65
elm_OT2:
Sig. (2-tailed) .942 .642 .569
lack of trust in contractor
N 52 52 51
elm_OR1: organizational
Sig. (2-tailed) .550 .000 .247
risks
†
N 66 66 65
276

Use data, move to
O Size OS3 Size in CAPEX - 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 Pearson’s correlation techniques and Pearson’s 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 Pearson’s 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.

Do not use data,
Size in remove from
O Size OS4 Engineering hours - 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

O Size OS5 Size of project team O* 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.

Do not use data,
remove from
O Size OS6 Size of site area - 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.

Use data, move to
O Size OS7 Number of locations O† 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
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 an 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. 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.

Use data for
schedule drive,
O Resources ORE1 Project drive O†, E* 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.
Action
Resource and skills
O Resources ORE2 scarcity 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
Correlation
TOE Sub-ordering ID Elements defined result Action proposed
Lack of experience
with parties Use data, rephrase
O Resources ORE3 involved - survey question
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 respondent’s 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.

Lack of HSSE
O Resources ORE4 awareness O† 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
Action
Interfaces between
O Resources ORE5 different disciplines O**, T* Use data
The element interfaces between different disciplines (elm_ORE5) shows a moderate

positive correlation to perceived organizational complexity (rs = .534, p=.000) and a much
weaker positive correlation to perceived technical complexity (rs=.240, p=.050). The
presence of correlations to both forms of perceived complexity could be explained by the
content of this element: interfaces can be easily associated with organizational complexity
and different disciplines will be more present in a technically complex project. A few
moderate positive correlations to other TOE elements related to interfaces or general
organizational complexity were found: resource and skills scarcity, dependencies on other
stakeholders, organizational risks, implying that interface problems between different
disciplines coincide with availability problems of resources and skills, more dependencies
with other stakeholders and higher organizational risks. Also several weaker correlations
with interface or uncertainty related elements were found, e.g. unaligned goals, uncertainty
in scope, number of tasks, uncertainty in methods, conflicting norms and standards,
technical risks, compatibility of project management methods and tools, number of
stakeholders and level of competition. The obtained data for this element can be used in the
current analysis.

Number of financial
O Resources ORE6 resources - Use data
Use data,
rephrase survey
O Resources ORE7 Contract types - question
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
Number of different Use data, rephrase
O Project team OP1 nationalities - 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.

Number of different
O Project team OP2 languages 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.

Co-operation JV
O Project team OP3 partner E† 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
Do not use data,
Overlapping office rephrase survey
O Project team OP4 hours - question
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.

Lack of trust in Use data, rephrase
O Trust OT1 project team - survey question
Lack of trust in Use data, rephrase
O Trust OT2 contractor - 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.

O Risk OR1 Organizational risks O** Use data
The element organizational risk (elm_OR1) shows a moderate positive correlation to

perceived organizational complexity (rs = .634, p=.000). Several significant weak to
moderate positive correlations with other elements of the TOE framework are found, not
limited to the O-elements. The element organizational risks correlates weak to moderate to
the elements unaligned goals, unclear goals, uncertainty in methods, conflicting norms and
standards, technical risks, compatibility of project management methods and tools, size in
CAPEX, lack of resource and skills availability, interfaces between different disciplines,
variety of stakeholder’s perspectives, dependencies on other stakeholders and political
influence. E.g. higher organizational risks coincide with more unalignment 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 stakeholder’s 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.
284
D.3: Correlation of E-elements and perceived complexity
All correlation results between the E-elements of the TOE framework and perceived
complexity are shown in Table D.3. Next, for all E-elements a summary of the findings is
Table D.3: Correlations E-elements and perceived complexity

Correlation Coefficient .019 .238† .088
elm_ES1:
Sig. (2-tailed) .886 .074 .516
number of stakeholders
N 57 57 57
elm_ES2: Correlation Coefficient -.007 .393** .029
variety of stakeholders Sig. (2-tailed) .955 .001 .819
perspectives N 64 64 64
Correlation Coefficient .256* .446** .135
elm_ES3: dependencies on
Sig. (2-tailed) .045 .000 .295
other stakeholders
N 62 62 62
Correlation Coefficient -.253* .196 .097
elm_ES4:
Sig. (2-tailed) .045 .123 .452
political influence
N 63 63 62
elm_ES5: Correlation Coefficient -.053 .145 .020
lack of company internal Sig. (2-tailed) .670 .245 .872
support N 66 66 65
Correlation Coefficient .047 -.019 .005
elm_ES6:
Sig. (2-tailed) .750 .897 .972
required local content
N 48 48 47
elm_EL1: Correlation Coefficient .176 .212† .092
interference with existing Sig. (2-tailed) .161 .090 .471
site N 65 65 64
elm_EL2:
Sig. (2-tailed) .543 .224 .798
weather conditions
N 64 64 63
elm_EL3:
Sig. (2-tailed) .330 .539 .291
remoteness of location
N 66 66 65
elm_EL4: Correlation Coefficient .022 .219† .086
lack of experience in the Sig. (2-tailed) .858 .076 .494
country N 67 67 66
elm_EM1:
Sig. (2-tailed) .375 .889 .245
internal strategic pressure
N 65 65 64
elm_EM2: Correlation Coefficient .040 .227† .211†
instability project Sig. (2-tailed) .749 .066 .091
environment N 66 66 65
elm_EM3:
Sig. (2-tailed) .844 .240 .202
level of competition
N 66 66 65
Correlation Coefficient -.098 -.071 .367**
elm_ER1:
Sig. (2-tailed) .433 .571 .003
risks from environment
N 66 66 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 E-
subcategories 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 E-
elements.
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.
Action
Use data,
rephrase
survey
E Stakeholders ES1 Number of stakeholders O† question
The element number of stakeholders (elm_ES1) shows a weak, hardly significant,

correlation to perceived organizational complexity (rs=.238, p=.074). It shows a moderate
positive correlation to uncertainties in scope (rs=.406, p=.003): a higher number of
stakeholders coincide with more uncertainties in the scope. Several positive weak
correlations were found, such as a higher number of stakeholders coincide with more
interface problems, longer project duration and more project locations. A weak negative
correlation was found with lack of experience in the country (rs=-.286, p = .031): having
more stakeholders coincides with less lack of experience in the country. In general, the
number of stakeholders seems to have organizational implications and is therefore closer
linked to perceived “organizational” complexity. This element, however, was intended to
be focused on external stakeholders and this should be clearer in the survey question. Still
the obtained data can be used in the current analysis.

Variety of
stakeholders' Use data, rephrase
E Stakeholders ES2 perspectives O** survey question
The element variety of stakeholders’ perspectives (elm_ES2) shows a weak correlation to

perceived organizational complexity (rs = .393, p =.001). It shows weak to moderate
positive correlations to elements such as unaligned goals, unclear goals, uncertainty in
methods, resources and skills scarcity, organizational risks, dependencies on other
286
stakeholders, lack of company internal support and interference with existing site. Varied
stakeholder’s 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.

Dependencies on Use data, rephrase
E Stakeholders ES3 other stakeholders T*, O** survey question
The element dependencies on other stakeholders (elm_ES3) shows a moderate positive

correlation to perceived organizational complexity (rs = .446, p=.000) and a weak positive
correlation to perceived technical complexity (rs = .256, p=.045). E.g. more dependencies
on other stakeholders coincide with increased organizational complexity and, to a lesser
extent, to increased technical complexity. Or, slightly rephrased: technically complex
projects coincide with more dependencies on other stakeholders and more dependencies on
other stakeholders coincide with higher organizational complexity. Hence, again,
respondents perceive the external or environmental complexity as organizational
complexity.
The element shows weak to moderate positive correlations to elements such as unaligned
goals, unclear goals, interfaces between different disciplines, organizational risks and
variety of stakeholder’s perspectives. E.g. more dependencies on other stakeholders
coincide with more serious unaligned goals, more unclear goals, interface problems
between different disciplines, more organizational risks and more varied stakeholder’s
perspectives. One strange negative correlation was found with interrelations between
technical processes: more dependencies on other stakeholders coincide with less
interrelations between technical processes (elm_TT5); supporting the previous observation
that the formulation of question relating to element TT5 needs adjustment. To strengthen
the focus on external stakeholders for this element, it needs reformulation. The obtained
data can, however, be used in the current analysis.

E Stakeholders ES4 Political influence T* (neg) 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.

Lack of company
E Stakeholders ES5 internal support - 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 company’s 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.

E Stakeholders ES6 Required local content - 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.

Interference with
E Location EL1 existing site O† 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 stakeholder’s
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 O-
category is considered, because of the before mentioned, suggested problem in the
definition of perceived environmental complexity.

E Location EL2 Weather conditions - 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
E Location EL3 Remoteness of location - 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.
Action
Lack of experience
E Location EL4 in the country O† 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.

Do not use data,
Internal strategic rephrase survey
E Market conditions EM1 pressure - 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.

Market Instability project
E conditions EM2 environment 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.

EM Level of
E Market conditions 3 competition - 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
Risks from Use data, rephrase
E Risk ER1 environment E** survey question
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 E-
elements. 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.
D.4: Summary of element evaluations

Table D.4: Summary of element evaluations
Result
Corr.
TOE
Sub-
ID Elements defined Action proposed
ordering
T Goals TG1 Number of goals T† Use data

T Goals TG2 Unaligned goals O** Use data
T Goals TG3 Unclear goals O† Use data
Do not use data, remove
T Scope TS1 Scope largeness - element
Use data,( rephrase question
T Scope TS2 Uncertainties in scope O† for future use)
T Scope TS3 Quality requirements T**, E† Use data
Do not use data, rephrase
T Tasks TT1 Number of tasks - question
T Tasks TT2 Variety of tasks - question
T Tasks TT3 Dependencies between tasks T† Use data, rephrase question
T Tasks TT4 Uncertainty in methods T* Use data
Interrelations between Do not use data, rephrase
T Tasks TT5 technical processes - question
T Tasks TT6 standards O* Use data
Newness of technology
T Experience TE1 (world-wide) T†, O† Use data
Lack of experience with
T Experience TE2 technology - Use data, rephrase question
T Risk TR1 Technical risks T**, O* 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)
292
Table D.4: Summary of element evaluations (continued)
Result
Corr.
TOE Sub-
ID Elements defined Action proposed
ordering

O Size OS1 Project duration T† category
Incompatibility of different
project management methods and O**,
O Size OS2 tools E* Use data
O Size OS3 Size in CAPEX - category
O Size OS4 Size in Engineering hours - from framework
O Size OS5 Size of project team O* Use data
O Size OS6 Size of site area - from framework
O Size OS7 Number of locations O† category
Use schedule drive data,
O Resources ORE1 Project drive O†, E* rephrase question
O Resources ORE2 Resource & Skills scarcity O** Use data
Lack of experience with parties
O Resources ORE3 involved - Use data, rephrase question
O Resources ORE4 Lack of HSSE awareness O† Use data
Interfaces between different O**,
O Resources ORE5 disciplines T* Use data
O Resources ORE6 Number of financial resources - Use data
O Resources ORE7 Contract types - Use data, rephrase question
O Project team OP1 Number of different nationalities - Use data, rephrase question
O Project team OP2 Number of different languages O* Use data
O Project team OP3 Presence of JV partner E† Use data
O Project team OP4 Overlapping office hours - question
O Trust OT1 Lack of trust in project team - Use data, rephrase question
O Trust OT2 Lack of trust in contractor - Use data, rephrase question
O Risk OR1 Organizational risks O** Use data
E Stakeholders ES1 Number of stakeholders O† Use data, rephrase question

Variety of stakeholders'
E Stakeholders ES2 perspectives O** Use data, rephrase question
Dependencies on other T*,
E Stakeholders ES3 stakeholders O** Use data, rephrase question
T*
E Stakeholders ES4 Political influence (neg) Use data
E Stakeholders ES5 Lack of company internal support - Use data
E Stakeholders ES6 Required local content - Use data
E Location EL1 Interference with existing site O† Use data
E Location EL2 Weather conditions - Use data
E Location EL3 Remoteness of location - Use data
E Location EL4 Lack of experience in the country O† Use data
Market Do not use data, rephrase
E conditions EM1 Internal strategic pressure - question
Market
E conditions EM2 Instability project environment O†, E† Use data
Market
E conditions EM3 Level of competition - Use data
E Risk ER1 Risks from environment E** Use data, rephrase question
** 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
APPENDIX E: Required element transformations (Chapter 6)
294
Appendix E: Required element transformations (Chapter 6)
295
APPENDIX F: Interview questions PHASE III (Chapter 8)
Background information project

Company description
Reasons for starting project
Client
Location
Project team size
Team Building
1.1 Can you tell me something about the project team?
1.2 How was the team composed?
1.2.1 How did you apply team design?
1.2.2 What exactly has been done during these activities?
1.2.3 Would you perform these activities again?
1.2.4 Would you perform these activities in a different situation?
1.2.5 How did team building influence the project results?
1.3 Which negative impacts of team building on project success can you mention?
1.4 Did any conflicts appear during Front-End Development phase between the team members?
1.4.1 What conflicts appeared in the Front-End Development phase between the team
members?
1.4.2 How where the initial conflicts between the team members influencing the rest
of the project?
Goal-setting
2.1 What were the most important goals in the project?
2.2 How were these goals set?
2.2.1 Which goal setting activities did you use?
2.2.2 Which two goal setting activities consider you to be most important?
2.2.6 How did team building influence the project results?
2.3 By whom were the goals of the project set?
2.3.1 What are benefits if the goals are self set?
2.4 Were these goals complicated to achieve or do-your-best goals?
2.4.1 Do you think that difficult goals led to a higher performance?
2.5 Were these goals perceived to be important contributors to the project success?
2.6 Did you monitor the project goals?
2.6.1 How did you monitor the project goals?
External Benchmarking
3.1 Did you perform benchmarking activities?
3.1.1 Which benchmarking activities did you use?
3.1.2 Which two benchmarking activities consider you to be most important?
3.1.6 How did benchmarking influence the project results?
3.2 Various benchmarking processes exist. Which process did you use?
Risk Management
4.1 Did you perform risk management?
4.2 When did you apply risk management?
296
Appendix F: Interview questions (Chapter 8)
4.3 Who were involved in risk management?

4.3.1 Which risk management activities did you use?
4.3.2 Which two risk management activities consider you to be most important?
4.3.6 How did risk management influence the project results?
4.4 What systematic risk identification methods were performed during the Front-End
Development Phase?
4.5 How did you assess the risk of the project?
4.6 How did you reduce the probability and consequences of adverse risks to an acceptable
threshold?
4.7 Were risks actively monitored?
4.7.1 How were risks actively monitored?
4.7.2 Was there a person responsible for risk management?
Operations Implementation planning

5.1 Did you perform Operations Implementation Planning?
5.2 When did you perform OIP
5.3 Who were involved in OIP?
Project success
6.1 Who defined the critical success factors?
6.2 How were the critical success factors defined?
6.3 What were the critical success factors of the project?
6.4 How was success measured?
6.5 Were these critical success factors reached?
General questions
7.1 Which FED activities was the most import?
7.2 Which activity had the most attention in your project?
7.3 Which activity was most effective in terms of invested time and results in the project outcome?
7.4 Which FED activity is not dependent on the context it is executed and has a strong relation to
project success?
297
298
APPENDIX G: Internet survey PHASE IV (Chapter 9)
299
300
Appendix G: Survey questions (Chapter 9)
301
302
Appendix G: Survey questions (Chapter 9)
303
APPENDIX H: Elements most/least contributing to project
complexity PHASE IV (Chapter 9)
Most contributing to complexity

0% 20% 40% 60% 80%
Number of project goals
Non-alignment of project goals
Unclarity of project goals
Uncertainties in scope
Strict quality requirements
Project duration
Size in CAPEX
Number of locations
Lack of experience with technology
Number of tasks
Variety of tasks
Dependencies between tasks
Uncertainty in methods
Involvement of different technical…
Conflicting norms and standards
Technical risks
High project schedule drive
Lack of resourse&skill availability
Lack of experience with parties…
Lack of HSSE awareness
Interfaces between different…
Number of financial sources
Number of contracts
Number of different nationalities
Number of different languages
Presence JV partner
Involvement of different time-zones
Size of project team
Incompatibility between different…
Lack of trust in project team
Number of external stakeholders
Variety of stakeholders perspectives
Dependencies on external…
Political influence
Lack company internal support
Required local content (forced…
Interference with existing site
Weather conditions
Lack of experience in the country
Company internal strategic pressure
Level of competition
Risks from environment
304
Managing Project Complexity Appendices
Least contributing to complexity

0% 20% 40% 60% 80%
Number of project goals
Non-alignment of project goals
Unclarity of project goals
Uncertainties in scope
Strict quality requirements
Project duration
Size in CAPEX
Number of locations
Lack of experience with technology
Number of tasks
Variety of tasks
Dependencies between tasks
Uncertainty in methods
Involvement of different technical…
Conflicting norms and standards
Technical risks
High project schedule drive
Lack of resourse&skill availability
Lack of experience with parties…
Lack of HSSE awareness
Interfaces between different…
Number of financial sources
Number of contracts
Number of different nationalities
Number of different languages
Presence JV partner
Involvement of different time-zones
Size of project team
Incompatibility between different…
Lack of trust in project team
Number of external stakeholders
Variety of stakeholders perspectives
Dependencies on external…
Political influence
Lack company internal support
Required local content (forced…
Interference with existing site
Weather conditions
Lack of experience in the country
Company internal strategic pressure
Level of competition
Risks from environment
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 project’s
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 project’s 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 respondent’s 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:
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 project’s 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 beïnvloedt. De tweede doelstelling is om te onderzoeken hoe de front-end
activiteiten kunnen worden aangepast aan de projectcomplexiteit en hoe dit de
projectprestaties beïnvloedt. 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 enquête (fase II - hoofdstukken 5, 6 en 7); verklarende casestudies (fase III -
hoofdstuk 8) en een toetsende enquête (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 NAP-
netwerk met een zeer gestructureerde projectmanagementaanpak. Door te kiezen voor
verschillende projecten binnen één bedrijf bleef variatie in uitgevoerde standaard front-end
313
activiteiten beperkt - alle projecten waren immers uitgevoerd volgens dezelfde
projectmanagementstandaard. Er zijn 6 casussen onderzocht, waarbij elke casus een
afgerond project betrof. Binnen een casus zijn de voornoemde bouwstenen onderzocht:
projectcomplexiteit, de activiteiten in de front-end fase en de projectprestaties. Per casus
zijn semi-gestructureerde interviews gehouden met drie personen die bij (de ontwikkeling
van) het project betrokken waren. Deze drie geïnterviewde personen waren de
projectmanager, een teamlid en een lijnverantwoordelijke.
Uit de verkennende casestudies (hoofdstuk 3), is geconcludeerd dat vooral organisatorische

complexiteit werd benoemd door de geïnterviewden, vaker dan externe complexiteit en
technische complexiteit. Werken met een joint venture partner zorgde voor hogere
organisatorische complexiteit. Aspecten van technische, organisatorische en externe
complexiteit werden door de meerderheid van de geïnterviewden zeer verschillend
gescoord per project, hetgeen duidt op het belang en het nut van het meten van
projectcomplexiteit in meerdere dimensies. Projectcomplexiteit bleek een zeer subjectief
begrip te zijn, met een zeer dynamisch karakter. Beide bevindingen hebben gevolgen: bij
het bepalen van projectcomplexiteit is een dialoog tussen alle betrokken partijen een
vereiste en de verandering van de projectcomplexiteit moet regelmatig worden getoetst. Uit
de verkennende casestudies is geconcludeerd dat projectcomplexiteit vaak niet was
onderkend in de front-end fase van het project, en daarmee niet (goed) was gemanaged. Een
gebrek aan gedegen front-end ontwikkeling vergrootte de projectcomplexiteit, volgens de
geïnterviewden. Nadere analyse van de interviews toonde het belang aan van een aantal
front-end activiteiten: teambuilding, het definiëren van doelen en scope, risicomanagement,
governance, contractstrategie en interactie met de contractors (aannemers). Men vond
teamintegratie cruciaal om interfacecomplexiteit tegen te gaan.
Met behulp van de resultaten van de verkennende casestudies en het literatuuronderzoek is

een raamwerk ontwikkeld om projectcomplexiteit in kaart te brengen (hoofdstuk 4). Er zijn
vele verschillende elementen gevonden die kunnen bijdragen aan projectcomplexiteit. Op
basis van het literatuuronderzoek zijn de mogelijke oorzaken voor projectcomplexiteit
geclusterd in drie dimensies: technische complexiteit (inhoud en scope gerelateerd),
organisatorische complexiteit (gerelateerd aan projectteam, vertrouwen, resources) en
externe complexiteit (organisatorische complexiteit door externe factoren: stakeholders,
marktomstandigheden etc.). Samen resulteren ze in het TOE complexiteitsraamwerk. De
term "externe" complexiteit vervangt de oorspronkelijk gebruikte term
"omgevingscomplexiteit", vanwege verwarring met de ecologische betekenis in de Engelse
taal. Omdat risico’s en projectcomplexiteit onlosmakelijk met elkaar zijn verbonden, zijn in
het TOE raamwerk in elk van de categorieën specifieke elementen voor het benoemen van
risico’s opgenomen.
In fase II van het onderzoek is een kwantitatieve enquête uitgevoerd onder leden van het
NAP-netwerk (hoofdstuk 5) om het ontwikkelde complexiteitsraamwerk verder te
evalueren (hoofdstuk 6) en de relaties tussen projectcomplexiteit, front-end activiteiten en
projectprestaties te onderzoeken (hoofdstuk 7).
De enquête bevatte vragen over de (gepercipieerde) projectcomplexiteit, gemeten voor de

drie dimensies (technisch, organisatorisch, extern), de projectprestaties (opleveren van het
project met voldoende kwaliteit, binnen 10% van de afgesproken tijd en budget) en de
front-end activiteiten. Front-end activiteiten waren op twee manieren geoperationaliseerd:
ten eerste door de relevante front-end activiteiten uit de casestudies van hoofdstuk 3 en ten
tweede door twaalf zogenoemde “Value Improving Practices” (VIPs). Deze VIPs zijn
314
Managing Project Complexity Samenvatting
waarde toevoegende activiteiten, bekend in de procesindustrie. In totaal zijn 67 ingevulde

enquêtes ontvangen van respondenten uit meer dan 25 bedrijven in het NAP-netwerk. Dit
resulteerde in veel waardevolle informatie. De respondenten hadden voornamelijk een
technische achtergrond, op HBO of academisch niveau. De projecten in de dataset
varieerden qua geplande investeringen en geplande tijdsduur. Met uitzondering van twee
projecten waren alle projecten ontwerp-, engineering- en bouwprojecten, uitgevoerd door
bedrijven in de Nederlandse procesindustrie. Het percentage succesvolle projecten
(geleverd met voldoende kwaliteit, binnen 10% van de geplande kosten en geplande
tijdsduur), was 37%.
In hoofdstuk 6 is geconcludeerd dat projectcomplexiteit (onderverdeeld naar technische,

organisatorische en externe oorzaken) inderdaad een significant negatieve invloed heeft op
projectprestaties. De sterkste correlaties tussen elementen die projectcomplexiteit bepalen
en projectprestaties, werden gevonden voor doelen en scope, onzekerheid in methoden,
incompatibiliteit van PM methoden, schaarste van resources, interfaces tussen verschillende
disciplines en een gebrek aan interne ondersteuning.
Een aantal significante relaties is ook gevonden tussen de elementen die projectcomplexiteit
bepalen en de perceptie van de respondent van technische, organisatorische en externe
complexiteit. Waarschijnlijk werd de perceptie van de respondenten echter vaak gevoed
door de implicaties of gevolgen van projectcomplexiteit, terwijl wij zochten naar de
oorzaken van projectcomplexiteit. De respondenten waren het grotendeels eens met onze
intenties voor het gebruik van het TOE complexiteitsraamwerk: als ondersteuning van het
projectmanagement, om bewustzijn te creëren bij de betrokken stakeholders en, gezien de
dynamiek van projectcomplexiteit, voor het herhaald gebruik gedurende het hele project, te
beginnen tijdens de front-end fase. Tot slot is in hoofdstuk 6 het bewijs geleverd dat
projectcomplexiteit inderdaad uit vele verschillende componenten bestaat en dat het nuttig
is deze te onderscheiden.
In hoofdstuk 7 zijn de relaties tussen projectcomplexiteit, front-end activiteiten en

projectprestaties onderzocht. Door het gebruik van analyses op verschillende detailniveaus
is inzicht verkregen in deze relaties. Een 2x2 verdeling van de data (weinig / veel effort in
front-end activiteiten en lage / hoge complexiteit) toonde aan dat het toepassen van front-
end activiteiten een positieve invloed had op de projectprestaties. Om uit te zoeken welke
front-end activiteiten specifiek een positieve invloed hadden, is de data in detail
geanalyseerd. Hieruit bleek het belang van:
- Afstemmen van projectdoelstelling tussen de business en het projectteam,
- Toepassen van operationele implementatie-planning,
- Toepassen van externe benchmarking,
- Adequate contractvorm in samenwerking met (onder)aannemers.
Deze activiteiten bleken belangrijk voor de projectprestaties, ongeacht de
projectcomplexiteit. Enkele andere front-end-activiteiten toonden ook een relatie met
(verschillende dimensies van) projectcomplexiteit, naast een relatie met projectprestaties:
- Actieve monitoring van doelstellingen (vooral van belang bij technische
complexiteit),
- Het definiëren en afstemmen van projectdoelstellingen (vooral van belang bij
technische en organisatorische complexiteit),
- Tijdige betrokkenheid van partijen bij het project (vooral van belang bij technische
en organisatorische complexiteit),
315
- Toepassen van teambuilding (vooral van belang bij organisatorische en externe
complexiteit).
Het toepassen van contingentietheorie resulteerde in één gemodereerde relatie: het
toepassen van risicomanagement beïnvloedde projectprestaties, afhankelijk van de
technische en externe complexiteit van het project. De significante relaties tussen
projectcomplexiteit, front-end activiteiten en projectprestaties werden samengevat in Figuur
7.3.
In hoofdstuk 7 is ook onderzocht of de mening van de respondenten werd beïnvloed door

hun verschillende rollen. Belangrijke verschillen voor de perspectieven werden gevonden
tussen projectmanagers, teamleden en verantwoordelijken vanuit de business, vooral op het
gebied van het definiëren en afstemmen van projectdoelstellingen, teamsamenhang en
selectie van de projectmanager. Tussen de projecteigenaren en de aannemers werd een
belangrijk verschil van mening gevonden: de gepercipieerde waarde van het toepassen van
operationele implementatie-planning. Deze VIP werd als nuttiger ervaren door
projecteigenaren dan door de aannemers.
Na verkenning van de relaties tussen projectcomplexiteit, front-end activiteiten en project-

prestaties in fase II is in fase III door middel van een diepgravende case studie onderzocht
op welke manier bepaalde front-end activiteiten hadden bijgedragen aan de
projectprestaties (hoofdstuk 8). Uit de dataset van fase II zijn vier cases geselecteerd. Om
verschil in perspectief tussen projecteigenaren en aannemers te onderzoeken is een vijfde
casus aan de data toegevoegd, wederom uit een bedrijf aangesloten bij het NAP. Elke casus
betrof een afgesloten project. Fase III had een verklarend karakter en een kwalitatieve
inslag; er zijn 11 interviews gehouden met projectmanagers en teamleden van de vijf cases.
In hoofdstuk 8 is geconcludeerd dat de manier waarop bepaalde VIPs (teamsamenstelling;

definitie, afstemmen en monitoren van projectdoelen; risicomanagement; externe
benchmarking en operationele implementatie-planning) werden toegepast, en met wie,
relevant is. De rol van geïntegreerde teams bleek cruciaal. Van belang was integratie door
het betrekken van alle relevante partijen in het projectteam (eigenaar én aannemer, maar
ook mensen uit verschillende afdelingen binnen een bedrijf). Van belang was ook integratie
door het waarborgen van continuïteit van projectmedewerkers in de gehele
projectlevenscyclus (zowel onderzoekers, als ook de mensen van de productieafdeling, die
later met het projectresultaat moeten werken). Gezamenlijke inspanning, bijvoorbeeld door
gezamenlijk toepassen van VIPs bleek positief bij te dragen aan projectprestaties.
Geïntegreerde teams hadden korte communicatielijnen, waardoor bijvoorbeeld efficiënte
besluitvorming mogelijk was en waardoor (late) ingrijpende veranderingen in het project
voorkomen konden worden.
Fase IV, tenslotte, had een validerend karakter: er is nagegaan in welke mate de
verschillende aspecten van complexiteit, zoals beschreven in het complexiteitsraamwerk
(ontwikkeld in fase I en II) inderdaad bijdragen aan projectcomplexiteit en hoe het TOE
complexiteitsraamwerk zou kunnen helpen bij het verbeteren van projectprestaties in
toekomstige projecten (hoofdstuk 9). De vragen in dit deel van het onderzoek waren niet
projectspecifiek, maar sectorspecifiek om de validiteit van het onderzoek te vergroten. De
enquête is verstuurd naar twee eigenaarsbedrijven en twee aannemersbedrijven, alle vier
actieve leden van het NAP netwerk. In totaal zijn 64 ingevulde reacties ontvangen. Het
onderzoek in deze afsluitende fase was deels kwantitatief en deels kwalitatief. Kwantitatief
voor wat betreft de mate waarin elk van de elementen van het complexiteitsraamwerk zou
316
Managing Project Complexity 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 déze 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
definiëren 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 geïntegreerde 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 geïdentificeerde 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 geïntegreerde 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
geïntegreerde 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 front-
end fase, om beter met de geïdentificeerde 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 industriële sectoren, uitbreiding van de focus van de front-end
fase naar de projectuitvoeringsfase en verdere operationalisering van het gebruik van
geïntegreerde 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 master’s 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 Master’s thesis she received the KIVI-Oost/UT-
award 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

Final Dissertation Bosch-Rekveldt

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Final Dissertation Bosch-Rekveldt

Uploaded by

Copyright:

Available Formats

Managing project complexity

A study into adapting early project phases to improve project

A study into adapting early project phases to improve project

ter verkrijging van de graad van doctor

Maria Gerridina Catharina BOSCH-REKVELDT

Copromotor: Dr. ir. H.G. Mooi

©2011 M.G.C. Bosch-Rekveldt, The Hague, the Netherlands.

Printed by Ipskamp Drukkers BV.

Delft Centre for Project Management

CHAPTER 6 ..................................................................................................................... 109

CHAPTER 7 ..................................................................................................................... 137

CHAPTER 8 ..................................................................................................................... 171

CHAPTER 9 ..................................................................................................................... 189

CHAPTER 10 ................................................................................................................... 217

FIGURE 1.1: THE WHEEL OF SCIENCE (WALLACE, 1971) ................................................................... 6

ACAT Acquisition Categorisation Framework

projects are characterized by uncertainties, whereas “the traditional, formal approach to

1.2 Research objective, research questions and scope

The main research question to be answered is:

More specifically, this research is focused on technologically complex engineering projects

1.3 Research approach

1.3.1 Research in social science

To investigate the management of complex projects, a pure positivist research approach

Figure 1.1: The Wheel of Science (Wallace, 1971)

1.3.2 Methods applied in this research

Figure 1.2: Model project complexity / front-end activities / project performance

The constructivist character of the research consists of the appreciation of different

Figure 1.3: Overview of the empirical part of the research

1.4 Scientific and social relevance

1.5 Dissertation outline

In Chapter 5 we describe how quantitative data is gathered by means of a survey study

Finally, Chapter 10 provides the discussion as well as the conclusions and

Figure 1.5: Overview of the dissertation

Throughout this dissertation, we focus on engineering projects: projects that create a

2.1 What is a project?

“A project is an endeavor in which human, financial and material resources are

“A project is a temporary organization to which resources are assigned to do

PRINCE2, a well-known, structured project management method, gives a similar definition

“A project is a temporary organization that is created for the purpose of

2.2 The development of project management

developments in management science. The traditional project management, concerned with

Pryke and Smyth summarize the development of conceptual approaches in project

process approach. These approaches illustrate the broadening perspective on project

The UK research network “Rethinking project management” (Winter, Smith, Cooke-

In the development of project management, handbooks and bodies of knowledge are

3. P2M by the Japanese Engineering Advancement Association of Japan and the

As stated earlier, in project management literature a distinction is made between project

2.3 Trends in project management research

Kloppenborg and Opfer provide a detailed overview of project management research

Smyth and Morris investigated methodological issues in project management research

Focusing on this contingency school: several researchers suggested a contingency approach

2.4 How to assess project performance?

2.4.1 Project success dimensions

2.4.2 Operationalization of project success

Table 2.2: Success measures (Shenhar et al., 2001)

Based on subjective definitions of successful performance, Menches and Hanna developed

2.4.3 Critical success factors

Table 2.3: Critical success factors, different literature sources

2.5 A closer look into project front-end development

Figure 2.1: The influence of front-end development (Phase 1, 2, 3) on the value of a

Table 2.4: Names for typical FED phases

Table 2.5: Standard recommended front-end activities in the process industry:

Table 2.6: Value improving practices as identified by IPA and CII