Project success within agile project management

environment:
Discovering it’s potential in infrastructure projects.

Sebastian Solis Vuurmans

Construction Management and Engineering
MSc Thesis
Delft University of Technology

https://t.me/PrMaB
___________________________________________________________________________

© Copyright 2015 by S. Solis Vuurmans, TU Delft and Grontmij Nederland B.V.

All rights reserved. No part of the material protected by this copyright notice may be reproduced or utilized in
any way or by any means, electronic or mechanical, including photocopying, recording or by any information
storage and retrieval system, without the prior permission from the author.

https://t.me/PrMaB
 COLOPHON
Research Title Project success within agile project management environment: Discovering
it’s potential in infrastructure projects.
Document Type Graduation Thesis
Date November 2015

Author Sebastian Solís Vuurmans

Hopakker 35
3514 BT Utrecht
(+31) (0) 6 37 42 19 17
sebastian.solis.vuurmans@gmail.com
Student number 4243455

University Delft University of Technology

Faculty Civil Engineering and Geosciences
Master Track Construction Management and Engineering
Graduation Committee
Prof.dr.ir. M.J.C.M. Hertogh CEG, TU Delft
Ir. Y. J. Cuperus BK, TU Delft
Ir. A. Jalali Sohi CEG, TU Delft
Ing. M.B.J. de Kroon Grontmij, Nederland
Ir. S. Laaper Grontmij, Nederland

Grontmij Nederland B.V.

De Holle Bilt 22
3732 HM, De Bilt

Delft University of Technology

Faculty of Civil Engineering and Geosciences
Stevinweg 1
2628, CN, Delft

https://t.me/PrMaB
 To my parents and brother.

For their unconditional support and love.

iv
S Solis Vuurmans
https://t.me/PrMaB
 ACKNOWLEDGMENT
With this thesis I conclude my time in Delft/Utrecht and finish my master program Construction
Management and Engineering. It all started almost one year ago when I was introduced to Afshin
Jalali Sohi and we talked about his PhD research. So began the journey into the field of project
management success, success factors and agile. It was a bumpy ride to get a hard-headed man as
myself to view this project through an academic perspective, but I assure you that scrum will be used
in my future endeavours.
I would like to thank my graduation committee. Marcel Hertogh, always bringing focus at key
moments of my research. Ype Cuperus, for helping get into the mantra of ‘maximizing value and
banishing waste’. Stephan Laaper, for always reminding me that mistakes are part of the experience.
Maurice de Kroon, for helping me through the process and always finding the positive side in it all.
And especially Afshin, I might not be the best student, but I’m thankful for all the time you have
invested in me for discussions and feedback, and most of all, thanks for your patience, I wish you lots
of luck with finishing your own research.
Lastly I would like to thank the people of Grontmij that helped me throughout the whole research
period. They gave me time of their day for the many interviews and always assured me that I had the
door open if I needed any extra help. It was a great experience of meeting all types of people, with
different roles and projects. I guess it is always a good icebreaker to say you are a Costa Rican that
speaks a little bit of Dutch.
Personally it was a great challenge; moving to a new city, experiencing cultural differences and
going through major decisions in my life. I am grateful that I had the opportunity to work with an
amazing group of people that made it all easier; we had our laughs, our work discussions, and
multiple coffee breaks for which I will be eternally grateful. Thank you team ‘Projects’ for helping me
in every step of the way, you are awesome.

Sebastian Solis Vuurmans

Utrecht, 2015

v
S Solis Vuurmans
https://t.me/PrMaB
 SUMMARY
Infrastructure projects have been experiencing cost overruns and delays, these are not new, for
infrastructure projects are these days more of a rule than exception (Bent Flyvbjerg, Holm, & Buhl,
2002). This has incentivized the construction activity towards a more organized way of handling their
projects (Björnfot & Stehn, 2004), there have been improvements in very different areas like design,
production and management (Koskela, 2003). The existence of this cost overruns and late deliveries is
also experienced in Dutch infrastructure projects (Cantarelli, 2009), and a study by Flyvbjerg et al.
(2003) indicates that in 86% of the projects under consideration there are cost overruns, have an
average overrun of 28%. Since success has been continuously linked to criteria like time, cost and
scope (Toor & Ogunlana, 2010) there is a relation between the way a project is managed during the
process and the final outcome (Li, Akintoye, Edwards, & Hardcastle, 2005).
There has been research done on why infrastructure projects are continuously failing. Authors as
Munns and Bjeirmi (1996) make a connection between the project success and the management
methodology used. Several different project management methodologies exist now days, most
commonly known are PMBOK and PRINCE2. But in the ICT industry a new way of managing arise
called Agile Project Management (APM).
There is plenty research done on Critical Success Factors (CSF) of infrastructure projects (Belassi
& Tukel, 1996; Chin, Chan, & Lam, 2008; Cooke-Davies, 2002; de Wit, 1988; Munns & Bjeirmi,
1996; Pinto & Covin, 1989; Pinto & Slevin, 1988; Toor & Ogunlana, 2008; Turner, 2014). And the
past years, since the implementation of agile in the ICT industry there has been some research done
on success in this industry (Chow & Cao, 2008; de Souza Bermejo et al., 2014; Misra, Kumar, &
Kumar, 2009; Stankovic, Nikolic, Djordjevic, & Cao, 2013). But there is no existing research done on
the success of agile infrastructure projects by Critical Success Factors (CSF).
Therefore this thesis was aimed at determining which success factors were most critical to the
perceived success of projects managed in an agile environment. To gain knowledge about the way
these factors were secured, to be able to exploit these success factors in future projects by using the
following research question:
• How is the engineering company able to assess success of infrastructure projects in
agile managed environment?

To be able to generate the required data to answer the research question, Q-methodology research
was performed on 31 persons with three distinguishable background groups: (i) people from ICT with
scrum experience, (ii) people from infrastructure with scum experience and (iii) people from
infrastructure with traditional experience. Based
To come to a clear answer to this research question four sub-questions were composed:
SQ1: How to define success in Agile Project Management (APM) environment?
SQ2: What is the best framework to assess success of projects handled in APM?
SQ3: What are the most influential factors for success?
SQ4: How can this information be useful within the company?
Theoretical background
In the theoretical framework an answer to sub-questions on the subject of process success,
performance measurements (Critical Success Factors) and Agile Project Management was done.

vi
S Solis Vuurmans
https://t.me/PrMaB
Definition of success
Since our goal is to identify opportunities to improve the process success, and we believe a good way
to define it is by the word ‘happiness’ by the three major parties involved: the client, the company and
the engineers involved. The study of success was done only on the point of view of the project
personnel.
Proposed success framework based on CSF
In order to determine our framework of success specialized on APM projects a list of 16 different
articles were reviewed, that included articles focused on the construction sector as well as the ICT
industry. More than 300 CSF were combined and reduced to clear 38 different CSF grouped on eight
major clusters: related to (a.) Project manager. (b.) Team members, (c.) Project characteristics, (d.)
Organization, (e.) Client, (f.) Resources, (g.) Tools of APM and (h.) External factors.
Defined perspectives

The factor analysis resulted in identifying a total

of four main perspectives. Each perspective
represents a point of view on the CSF in order to
reach for success by a group of respondents. To
each of the four perspectives is assigned a name.
Below these names can be found alongside the
amount of respondents who are associated with
this perspective.
1. Perspective one: “Collaboration with client to
maximize value”
2. Perspective two: “Strong leader”
3. Perspective three: “Team empowerment”
4. Perspective four: “Capacity to respond to
change”

Implementation of agile mentality

It was considered very useful by the Grontmij Company to analyse their actual implementation
processes of infrastructure projects and to compare their experiences with the findings from literature
review about APM. As an important product of the interviews a list of positive factors and challenges
of the implementation of scrum were identified. A list of seven main actions is proposed with the
objective to maximize the effect of the positive CSF identified in the research.
Based on the research a three step process was recommended: (i) Identification of 38 CSF, (ii)
Incentivize CSF based on agile perspectives and (iii) Recommended actions.

vii
S Solis Vuurmans
https://t.me/PrMaB
 ABBREVIATIONS
APM Agile Project Management

CM Contract Manager

CME Construction Management and Engineering

CPM Critical Path Method

CSF Critical Success Factors

DoD Definition of Done

DSU Daily Stand Ups

GIS Geographic Information System

ICT Information and Communication Technology

IPM Integral Project Management

KPI Key Performance Indicators

LPS Last Planner System

OM ‘Omgevings Manager’ - Environment Manager

PCA Principal Component Analysis

PES Performance Enhancement Strategy

PL Project Leader

PM Project Manager
PMBOK Project Management Body of Knowledge

PMI Project Management Institute

PO Product Owner

PPP Public and Private Partnerships

PQMethod Analysis software specifically for Q Methodology

PRINCE2 Projects in Controlled Environments

PSIs Potentially Shippable Increments

RWS ‘Rijkswaterstaat’ – Ministry of Infrastructure and the Environment

SC Success Criteria

TM Team Member

TM* Technical Manager

WBS Work Breakdown Structure

WBS Work Breakdown Structure

WIP Work In Progress

viii
S Solis Vuurmans
https://t.me/PrMaB
 GLOSSARY
Agile Project APM is an iterative and incremental project management methodology, Page 18
Management originally used in software development. It is based on empowerment of the
development team and includes continuous deliverables and feedback from
client.

Burn down chart The burn down chart is the way for the team to track progress and provide Page 26
visibility. The scrum master updates it at the end of each sprint. The
horizontal axis of the release burn down chart shows the sprints; the vertical
axis shows the amount of work remaining at the start of each sprint. You can
see what the team has completed as well as how scope changed.

Critical Path CMP is a project-management technique related to the waterfall model. It Page 28
Method lays out all the activities needed to complete a task, the time it will take to
complete each activity and the relationships between the activities. The
sequence of activities that have no buffer in order to finish the project on
time, are called the critical path.

Critical success These are the outcomes of a project or achievements of an organization that Page 18
criteria are needed to consider the project a success or to esteem the organization
successful (outcome oriented). Success criteria are defined with the
objectives and may be quantified by Key Performance Indicators (KPIs).

Critical success A set of conditions, characteristics or variables that must go well in order to Page 14
factors ensure success for a project or organization and that must be given special
and continual attention to bring about high performance (process oriented).

Daily Stand Ups DSU is a tool of the ‘scrum’ methodology and consists of daily meetings of Page 25
the team of about 15 minutes where the team discusses three points per team
member: What was done yesterday? What will be done today? And
problems encountered.

Definition of done DoD is crucial to a highly functioning Scrum team and is an agreed list of Page 22
criteria that should be met for each Product Backlog Item.

Development team A cross-functional group of people responsible for delivering potentially Page 23
shippable increments of product at the end of every sprint.

Factor or The result given by the Q methodology states different ‘factors’ or Page 59
perspective ‘perspectives’ depending on the level of importance of the various
statements (in this research was used Critical Success Factors).

Failure costs All additional and avoidable costs incurred by unnecessarily or inefficient Page 19
procedures, as well as additional costs when the final product does not meet
the agreed quality, is inadequate or defective and need to be repaired or
replaced.

ix
S Solis Vuurmans
https://t.me/PrMaB
ICT Scrum A specific named group of respondents for this research. They consist in Page 54
engineers with experience in ICT projects with a vast use of scrum.

Infra Scrum A specific named group of respondents for this research. They consist in Page 54
engineers with experience in infrastructure projects in a traditional manner
as well as infrastructure projects managed with scrum.

A specific named group of respondents for this research. They consist in

Infra Trad Page 54
engineers with experience in infrastructure projects in a traditional manner.
Don’t have any scrum experience.

Key Performance Indicators that evaluate the achievement or success of an organization or of a Page 16
Indicators particular activity in which it engages. Often success is the repeated,
periodic achievement of some levels of the operational goal, and generally
success is defined in terms of making progress toward strategic goals that are
fixed at the start of the project.

Planning poker Planning poker is a consensus-based, technique for estimating, mostly used Page 27
to estimate effort or relative size of tasks

PQMethod Software used to analyse data specifically for Q-methodology Page 33

Product Backlog The product backlog in scrum comprises an ordered and prioritized feature Page 25
list, of all things that needs to be done within the project.

Product owner The responsible in scrum project management methodology that represents Page 23
the client’s requests for developing for each sprint.

Project leader In traditional project management, a project leader is the person in charge of Page 23
directing the course of the project. He works together with a team and is
responsible for cost and time management.

Q-methodology Q Methodology is a research method aimed to systematically study the Page 33

participant’s viewpoints. This methodology is used to investigate the
perspectives of the participants by asking them to rank and sort a series of
statements related to a specific issue.

Scrum A tool of Agile Project Management (APM), being an iterative and Page 33
incremental process for managing product development.

Scrum master Is the facilitator for a product development team that uses scrum, and allows Page 23
a team to self-organize and make changes quickly. The scrum master does
anything possible to help the team perform at their highest level, which
involves removing any impediments to progress and facilitating meetings to
make sure the product backlog is in good shape and ready for the next sprint.

x
S Solis Vuurmans
https://t.me/PrMaB
Scrum team A scrum team consists of: product owner, scrum master and development Page 23
team.

Sprint A scrum sprint is a regular, repeatable work cycle during which work is Page 25
completed and made ready for review. Scrum sprints are basic units of
development in the scrum methodology and are, generally, in unit of weeks.

Success In project management there is not just one definition. Mostly common used Page 11
is the iron triangle, which includes: project in budget, in time, within scope.

Velocity in scrum The total effort a team is capable of in a sprint (hours of work per sprint). Page 26
Evaluating the work completed from the last sprint’s backlog items, a
velocity of the team is presented. The collection of historical velocity data is
a guideline for assisting the team in understanding how much work they can
do in a future sprint.

Waterfall model The waterfall model is a sequential design process, in which progress is seen Page 27
as flowing steadily downwards (like a waterfall) through the phases of
conception, initiation, pre-design, design, contracting, tendering,
construction, operation and maintenance.

Work breakdown A chart in which the critical work elements against time. It is used to show Page 29
structure the amount of work done and still pending to reach the sprint goal.

xi
S Solis Vuurmans
https://t.me/PrMaB
 TABLE OF CONTENTS
COLOPHON III
ACKNOWLEDGMENT V
SUMMARY VI
ABBREVIATIONS VIII
GLOSSARY IX
TABLE OF CONTENTS XII
LIST OF TABLES XV
LIST OF FIGURES XVII
CHAPTER I 1
1 INTRODUCTION 1
1.1 Problem statement 2
1.1.1 Problems faced by the infrastructure sector 3
1.1.2 The importance of success and how to achieve it 3
1.1.3 The need felt by Grontmij to count with a success framework. 3
1.2 Objective of the research 5
1.2.1 Research question 5
1.3 Research methodology 6
1.4 Scope of the research 7
1.5 Thesis outline 8
1.6 Discussion 9
CHAPTER II 11
2 THEORETICAL FRAMEWORK 11
2.1 Definition of project success 11
2.1.1 Success of the final result vs. success of the process 13
2.1.2 Research’s definition of success 13
2.2 Project performance measurements 14
2.2.1 Critical Success Factors (CSF) 15
2.2.2 Key Performance Indicators 17
2.2.3 Success Criteria 18
2.2.4 Failure costs 19
2.2.5 Discussion 20
2.3 The Agile Project Management Methodology 22
2.3.1 What is Agile? 22
2.3.2 Core principles of APM 23
2.3.3 Different roles in Scrum 23
2.3.4 Description of the scrum process 25
2.3.5 Different tools in Scrum 26
2.4 Traditional project management or Waterfall model 27
2.4.1 Critical Path Method in the Gantt chart 28
2.4.2 Work Breakdown Structure (WBS) 29
2.4.3 How is it different from Agile Project Management (Scrum)? 29
2.5 Discussion of project management methodologies 31
2.6 Q methodology 33
2.6.1 Step by step of the Q methodology 33
CHAPTER III 36

xii
S Solis Vuurmans
https://t.me/PrMaB
3 THE RESEARCH 36
3.1 information gathering procedure with key informants 36
3.2 Overview of Critical Success Factors 37
3.2.1 The infrastructure CSF 38
3.2.2 The ICT CSF 39
3.3 Definition of the Q set 40
3.3.1 Factor group related to project manager 42
3.3.2 Factor group related to team members 43
3.3.3 Factor group related to characteristics of the project 44
3.3.4 Factor group related to the organization 46
3.3.5 Factor group related to the client 47
3.3.6 Factor group related to the resources 48
3.3.7 Factor group related to the project management techniques 48
3.3.8 Factor group related to external environment 49
3.4 Definition of the P set 50
3.5 The questionnaire 51
3.6 Discussion 53
CHAPTER IV 54
4 ANALYSIS AND RESULTS 54
4.1 The respondents of the Q sorting research 54
4.1.1 Group: Infrastructure traditional 56
4.1.2 Group: Infrastructure with experience in scrum 57
4.1.3 Group: ICT experienced with scrum 57
4.2 PQMethod process 58
4.3 Defining the perspectives 59
4.3.1 Perspective one: “Collaboration with client to maximize value” 61
4.3.2 Perspective two: “Strong leader” 66
4.3.3 Perspective three: “Team empowerment” 71
4.3.4 Perspective four: “Capacity to respond to changes” 75
4.4 Comparing the perspectives 79
4.4.1 Consensus elements 79
4.4.2 Disagreement elements 81
4.5 Analysis of only experience in agile 82
4.6 Discussion 86
CHAPTER V 90
5 OPORTUNITIES FOR AGILE WITHIN GRONTMIJ 90
5.1 How has Agile been used in Grontmij? 90
5.1.1 Scrum projects 91
5.1.2 Level of usage 92
5.1.3 Overall opinion about scrum 97
5.2 Areas of improvement 99
5.2.1 Relation of scrum and important CSF 99
5.2.2 Going more agile 102
5.3 Discussion 105
CHAPTER VI 108
6 CONCLUSIONS AND RECOMMENDATIONS 108
6.1 Conclusions 109
6.1.1 Conclusions about the literature research 109
6.1.2 Conclusions about the perspectives on success 110
6.2 Recommendations 113
6.2.1 Recommendations of the research 113
6.2.2 Recommendations for the company 113

xiii
S Solis Vuurmans
https://t.me/PrMaB
 6.2.3 Recommendations for further research 115
REFERENCES 117
APPENDIX 122
A. Quick overview of other waterfall model project management methodologies 123
B. Statistical analisys of Q-methodology 127
C. Interviews database 129
D. Interviews protocol 131
E. Overview of CSF in literature 133
F. Clustering of CSF to define Q-set 140
G. Q sorting questionnaire 141
H. Q sort factor Results for the four perspectives 144
I. Analisis with agile sample 148

xiv
S Solis Vuurmans
https://t.me/PrMaB
 LIST OF TABLES
Table 2-1 | Advantages and disadvantages of methodologies ........................................................................ 32
Table 3-1 | Literature used for the definition of Q set .................................................................................... 37
Table 3-2 | Cluster CSF related to project manager ........................................................................................ 42
Table 3-3 | Cluster CSF related to team members .......................................................................................... 44
Table 3-4 | Cluster CSF related to characteristics of the project .................................................................... 45
Table 3-5 | Cluster CSF related to the organization ........................................................................................ 47
Table 3-6 | Cluster CSF related to the client ................................................................................................... 47
Table 3-7 | Cluster CSF related to the resources............................................................................................. 48
Table 3-8 | Cluster CSF related to the project management techniques ......................................................... 49
Table 3-9 | Cluster CSF related to external environment ............................................................................... 50
Table 3-10 | Summary of respondents characteristics .................................................................................... 51
Table 4-1 | Step by step in order to use PQMethod in order to obtain factors................................................ 58
Table 4-2 | Correlation between perspectives according to PQMethod software ........................................... 61
Table 4-3 | Special characteristics of the respondents perspective one. ......................................................... 63
Table 4-4 | Distinguishing elements perspective one ..................................................................................... 65
Table 4-5 | Extra characteristics respondents perspective two. ...................................................................... 67
Table 4-6| Distinguishing elements perspective two ...................................................................................... 70
Table 4-7 | Extra characteristics respondents perspective three. .................................................................... 72
Table 4-8 | Distinguishing elements perspective three ................................................................................... 74
Table 4-9 | Extra characteristics respondents perspective four ....................................................................... 76
Table 4-10 | Distinguishing elements perspective four................................................................................... 78
Table 4-11 | Consensus elements .................................................................................................................... 80
Table 4-12 | Disagreement elements ............................................................................................................... 82
Table 4-13 | Extra characteristics respondents with only agile experience .................................................... 84
Table 4-14 | Agile experience sample perspective choosing .......................................................................... 84
Table 5-1 | Summary of project Maximabrug characteristics ......................................................................... 91
Table 5-2 | Summary of project Rijnlandroute characteristics ....................................................................... 91
Table 5-3 | Summary of project HOV Hilversum characteristics ................................................................... 92
Table 5-4 | Summary of project Dijkversterking Marken characteristics ....................................................... 92
Table 5-5 | Detail of scrum process in literature and in Grontmij practice..................................................... 95
Table 5-6 | Improvement actions .................................................................................................................. 102
Table 5-7 | Recommended duration of scrum meetings adapted from de Boer et al. (2015) ....................... 105
Table 6-1 | Correlation matrix between sorts ................................................................................................ 144
Table 6-2 | Un rotated factor matrix ............................................................................................................. 145
Table 6-3 | Cumulative communalities matrix.............................................................................................. 146
Table 6-4 | Factor matrix with an X indicating defining sort ....................................................................... 147
Table 6-5 | Factor matrix with an X indicating defining sort for two perspectives ...................................... 148

xv
S Solis Vuurmans
https://t.me/PrMaB
Table 6-6 | Correlation for two perspectives................................................................................................. 148
Table 6-7 | Factor matrix with an X indicating defining sort for three perspectives .................................... 149
Table 6-8 | Correlation for three perspectives............................................................................................... 149

xvi
S Solis Vuurmans
https://t.me/PrMaB
 LIST OF FIGURES
Figure 1-1 | Iron triangle based on Pinto & Slevin (1988) ............................................................................... 3
Figure 1-2 | Conceptualization of problem ....................................................................................................... 4
Figure 1-3 | Conceptualization of methodology ............................................................................................... 7
Figure 1-4 | Company’s simplified organizational structure by Grontmij (2015) ............................................ 7
Figure 1-5 | Project life cycle where Grontmij is involved ............................................................................... 8
Figure 1-6 | Thesis document outline................................................................................................................ 9
Figure 2-1 | Project excellence by Westerveld (2003) .................................................................................... 13
Figure 2-2 | Focus on success through project personnel based on Westerveld (2003) ................................. 14
Figure 2-3 | KPIs for project success according to Weber and Thomas (2005) ............................................. 18
Figure 2-4 | Comparison of waterfall and APM deliverables based on Smith (2015). ................................... 22
Figure 2-5 | Conceptual model of the maximization of value ........................................................................ 23
Figure 2-6 | Detailed scrum process flow ....................................................................................................... 25
Figure 2-7 | Example of scrum board ............................................................................................................. 26
Figure 2-8 | Example of burn down chart and its respective velocity ............................................................ 27
Figure 2-9 | Project phases in waterfall model................................................................................................ 28
Figure 2-10 | Example of Gantt chart used during planning ........................................................................... 28
Figure 2-11 | Example of a WBS which has three levels ............................................................................... 29
Figure 2-12 | Comparison between scrum Vs. traditional value in time by de Boer et al. (2015) ................. 30
Figure 3-1 | Conceptual map of 38 CSF based on clusters by Belassi & Tukel (1996) ................................. 41
Figure 3-2 |Pictures of gathering of respondents ............................................................................................ 52
Figure 3-3 | Step three of questionnaire: the quantification of importance. ................................................... 52
Figure 4-1 | Characteristics total respondents Q sorting ................................................................................. 56
Figure 4-2 | Characteristics respondents of group Infra Trad. ........................................................................ 56
Figure 4-3 | Characteristics respondents of group Infra Scrum ...................................................................... 57
Figure 4-4 | Characteristics respondents of group ICT Scrum ....................................................................... 57
Figure 4-5 | Conceptual model of the definition of the perspectives .............................................................. 60
Figure 4-6 | General characteristics respondents perspective one .................................................................. 62
Figure 4-7 | Assessment perspective one: “Collaboration with client to maximize value” ............................ 64
Figure 4-8 | General characteristics respondents perspective two .................................................................. 67
Figure 4-9 | Assessment perspective two: “Strong leader” ............................................................................. 68
Figure 4-10 | General characteristics respondents perspective three .............................................................. 71
Figure 4-11 | Assessment perspective three: “Team empowerment” ............................................................. 73
Figure 4-12 | General characteristics respondents perspective four ............................................................... 75
Figure 4-13 | Assessment perspective four: “Capacity to respond to change” ............................................... 77
Figure 4-14 | Consensus elements................................................................................................................... 79
Figure 4-15 | Disagreement elements ............................................................................................................. 81
Figure 4-16 | General characteristics respondents with only agile experience ............................................... 83

xvii
S Solis Vuurmans
https://t.me/PrMaB
Figure 4-17 | Assessment respondents with agile experience ......................................................................... 85
Figure 4-18 | Agile adaptation based on positive CSF ................................................................................... 86
Figure 5-1 | Existing scrum process diagram based on Jeukens (2014) ......................................................... 94
Figure 5-2 | IPM organizational structure ....................................................................................................... 97
Figure 5-3 | Relationship between the agile manifesto core elements and the research perspectives .......... 100
Figure 5-4 | Recommendation of scrum team distribution ........................................................................... 104
Figure 5-5 | Relation Agile principles, perspectives and CSF ...................................................................... 106
Figure 6-1 | Perspective of success analysed ................................................................................................ 109
Figure 6-2 | Conclusion summary on CSF by methodology......................................................................... 111
Figure 6-3 | Recommendation summary ....................................................................................................... 114
Figure 6-4 | Structure of PRINCE2 by Axelos, 2014 ................................................................................... 123
Figure 6-5 | Use of PRINCE2 processes through the project life cycle........................................................ 124
Figure 6-6 | Process groups in phases of project by PMI (2013) .................................................................. 125
Figure 6-7 | Knowledge areas according to PMBOK ................................................................................... 126
Figure 6-8 | Step one of questionnaire: the profiling .................................................................................... 141
Figure 6-9 | Step two of questionnaire: the overview of 38 CSF.................................................................. 142
Figure 6-10 | Step three of questionnaire: the quantification of importance. ............................................... 143

xviii
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER I
“The journey of a thousand miles begins with a single step” (Chinese
philosopher Laozi)

The research is focused on a study of the application of Agile Project Management (APM), in
infrastructure projects success, based on project performance indicators, specifically Critical
Success Factors (CSF).
The main objective is to present a success assessment framework in infrastructure projects where
scrum has been used. The thesis is based on literature review and the findings obtained by
questionnaires and in-depth interviews, in which the elaboration of a Critical Success Factors
(CSF) framework will be developed to suit this new style of management (APM).

1 INTRODUCTION
During the last decades the construction industry sector has faced big changes: the level of
complexity of infrastructure project has increased, as well as the demand of high quality of the
projects to be developed (Björnfot & Stehn, 2004). This is pushing this sector towards a need of
managing projects in a more industrialized way with the objective to reduce cost overruns, late
deliveries and to increase quality of the product (ibid). There has been also a tendency towards the
concept of value and the importance of the acceptance of a project as being successful (Stabell &
Fjeldstad, 1998).
There exist different methodologies, tools and techniques that help to tackle that level of
complexity in the construction sector (J. Thomas & Mengel, 2008). The performance of a project is
related to the management methodology used (Hertogh & Westerveld, 2010). Most of these project
management methodologies were created to adapt a ‘waterfall model1’ where project’s life cycles
have a distinct beginning and an end (Schwaber, 1997).
However, in the past years, the Information and Communication Technology (ICT) industry has
come up with what is called Agile Project Management2 (APM) (Layton, 2012), which presents a
significant shift from the ‘waterfall model’ to a ‘iterative/incremental object-oriented development
cycle’ (Schwaber, 1997).
Its application in the construction industry is relatively new, the appeal comes out its ability of
handle changes in scope, maximize value, great client’s involvement and reducing uncertainty (Yllén
Johansson, 2012).
Our aim is to investigate how this project management methodology has influenced the level of
project success, and to analyse its potential to be applied in the infrastructure industry. For this we
will proceed to:

1
Waterfall model will be further explained in page 36.
2
Agile project management, also known as scrum in by Grontmij, will be further explained in page 31.

1
S Solis Vuurmans
https://t.me/PrMaB
 (1) Literature review (related to topics like: performance measurement, key performance
indicators, success factors, success criteria, traditional and dynamic project management);
(2) Design of a framework of success (through extensive literature of Critical Success Factors
used both in Infrastructure and ICT projects)
(3) Use of questionnaires and in-depth interviews to identify the added value of using APM, in
order to display possible areas of improvement.
It is important to comment in this regard that the present thesis research is laterally related to a
current PhD research project3, which is focused on “Flexible project management methodology to
cope with dynamics in project context”, based on the problem statement that current project
management methodologies seem to underestimate the influence of the dynamics of project context.
Furthermore, an important stakeholder to make mention of and that has been involved during the
whole process of elaboration of the present thesis research providing all the facilities to make it
possible, is the engineering and consultancy company Grontmij, which is actually one of the leading
firms of innovation in the field of using the methodology APM, or scrum, in their developing projects.
The valuable experiences of persons employed by the company have formed an important input for
the design of the framework of success.

1.1 PROBLEM STATEMENT

There is a constant pursuit for success in infrastructure projects, so firms have been trying to find
methods and tools that maximize their success potential. Although APM or scrum is recognized being
one of the possible options, there is still no real research done to assess its effect in the project overall
result.
In short:

There is plenty research done on Critical Success Factors (CSF) of infrastructure projects (Belassi
& Tukel, 1996; Chin, Chan, & Lam, 2008; Cooke-Davies, 2002; de Wit, 1988; Munns & Bjeirmi,
1996; Pinto & Covin, 1989; Pinto & Slevin, 1988; Toor & Ogunlana, 2008; Turner, 2014). And
the past years, since the implementation of agile in the ICT industry there has been some research
done on success in this industry (Chow & Cao, 2008; de Souza Bermejo et al., 2014; Misra,
Kumar, & Kumar, 2009; Stankovic, Nikolic, Djordjevic, & Cao, 2013).
There is no existing research done on the success of agile infrastructure projects by Critical
Success Factors (CSF).

The vision of Grontmij as an engineering company is to resolve the client’s pain through its
knowledge determining the client’s happiness as its main goal. So as company Grontmij is always
trying to improve its way of maximizing this feature with high clients acceptance as one of their main
objectives.
There is a need for a success framework in infrastructure projects with scrum and the idea is that
the present thesis research will identify new success criteria perhaps overlooked in previous studies, to
be converted into useful tools to be dispersed further within the industry.
The description of the problem as presented below is divided into three major parts: (i) overview
of the main problems faced by the construction industry, (ii) the definition of “success” and (iii) the
need felt by Grontmij and its interest in this research.

3
By Afshin Jalali Sohi, Delft University of Technology, Civil Engineering Faculty.

2
S Solis Vuurmans
https://t.me/PrMaB
1.1.1 Problems faced by the infrastructure sector
Infrastructure projects have been experiencing cost overruns and delays, these are not new, for
infrastructure projects are these days more of a rule than exception (Bent Flyvbjerg et al., 2002). This
has incentivized the construction activity towards a more organized way of handling their projects
(Björnfot & Stehn, 2004), there have been improvements in very different areas like design,
production and management (Koskela, 2003). The existence of this cost overruns and late deliveries is
also experienced in Dutch infrastructure projects (Cantarelli, 2009), and a study by Flyvbjerg et al.
(2003) indicates that in 86% of the projects under consideration there are cost overruns, have an
average overrun of 28%. This data was gathered by Flyvbjerg and he states the importance of case
studies above theoretical research (2006).
The problem is not only the financial situation that the project faces, but also the reputation of a
company can be damaged by handling projects known by their cost overruns and delays (Wijnen &
Storm, 2011). Therefore there is an impulse for construction companies to continuously search
improvement in order to obtain more ‘successful’ projects.

1.1.2 The importance of success and how to achieve it

There is a constant need of companies for successful projects, but the concept of success has also
changed because there has been an increase in complexity in projects (Chan & Chan, 2004). The most
conventional definition of project success is that a project is considered to be successful when it has
met its proposed time schedule, and the planned budget and performance goals, also called the iron
triangle (Pinto & Slevin, 1988).

But according to Chan (2004) success is

more than just the aforementioned three
factors. He states that the level of success
can be further measured through the
identification and analysis of the success
factors. This is one of the reasons why many
researchers (Baker, Murphy, & Fisher, 2008;
de Wit, 1988; Shenhar, Dvir, Levy, & Maltz,
2001) looked for different measures of
project success. One of the ways the industry
is aiming to improve success is by means of
the application of project management
methodologies (Munns & Bjeirmi, 1996).
Figure 1-1 | Iron triangle based on Pinto & Slevin (1988) The most known are PRINCE2 (PRojects IN
Controlled Environments), PMBOK (Project
Management Body of Knowledge) and Lean construction4. There has been done considerable research
on all of them, even direct comparisons between them (Wideman, 2002). But lately a new
development showed up, called Agile Project Management (APM), whose focus is on embracing
change, continuously updating the base schedule, budget and even the scope of the project (Karlesky
& Vander Voord, 2008). It was developed by the software industry but it has been used in different
industries being construction one of them (Layton, 2012).

1.1.3 The need felt by Grontmij to count with a success framework.

Like many other engineering firms also Grontmij is facing the problem to deal with projects that
do not proceed entirely according to the initial plan and budget. The consequently additional costs by
inefficient performance, or the need of rework are the most common obstacles (Jeukens, 2014). This
situation pushed the company to improve their management methodologies and give them an edge
against their competition. Grontmij is one of the first Dutch companies that utilize scrum or APM as a

4
Will be further develop in CHAPTER II: Theoretical framework, page 25.

3
S Solis Vuurmans
https://t.me/PrMaB
project management tool. They use it in specific parts of the project life cycle and they are looking for
developing this management tool even further if proven successful.
According to a recent research carried out by Jeukens (2014) the most common difficulties
presented in scrum projects at the start are the lack of client involvement and of effective
communication channels. In many cases, also the coordination between different teams involved in
the project was inadequate, or exists insufficient overview of the work to be carried out. Finally,
another reason of failure is that in general the focus to the client is not optimal, causing disparities
between what the customer wants and what he gets delivered by the company. In other words, the
client is not sufficiently involved in the development process in order to guarantee a successful and/or
desirable product (Jeukens, 2014).
The findings of Jeukens (2014) give an overview of scrum project performances in the
infrastructure industry in general terms, but in order to determine the success or failure of a specific
project in particular, the design of a framework of success assessment directly related to the project in
question and its characteristics is needed.
Before entering in the exercise itself of the assessment of the success of a selected case study, first
a framework of success will be presented (based on literature study of previous researches done in
both infrastructure and ICT). So in order to present any recommendations in the project management
methods we need this personalized success framework.

Figure 1-2 | Conceptualization of problem

The main concept of the present research project is schematically shown in the above Figure
(Conceptualization of problem). Since the scrum methodology has recently been introduced in the
infrastructure sector there is no research done in order to visualize if it helps in any way the usual
project process. By proposing a success framework there could be a sort of relation between the
project management methodology and Critical Success Factors that could help to identify the potential
of this methodology in the infrastructure sector.

4
S Solis Vuurmans
https://t.me/PrMaB
 In the overall construction industry we will focus on the tool of the success framework by using
research already done extensively in Critical Success Factors (CSF) in the infrastructure sector as well
as in the recent research in ICT with scrum. We will validate this framework by means of a
questionnaire based on the Q methodology5 that will provide valuable information from people
involved in projects about the significance of the proposed CSF, as well as a ranking and correlation
factor. This outcome will be used as support and justification for the recommendations to be provided
to the company.
The knowledge of performance measurement for success has been investigated in a broad scope
of projects. The use of APM has not yet been fully established in the construction industry and there
are still some benefits and limitations to be discovered and to be confirmed (Layton, 2012).
We want to focus our research in Agile Project Managed projects, for which the main reasons for
success will be analysed though performance measurement criteria in order to present a framework of
assessment of success of infrastructure projects.

1.2 OBJECTIVE OF THE RESEARCH

The main objective of the present thesis research is formulated as follows:
• Design a Critical Success Factors (CSF) framework in infrastructure projects managed by
Agile Project Management methodology.

1.2.1 Research question

As a means of ensuring that the research is executed to satisfaction, research questions are
formulated (Verschuren & Doorewaard, 2010). This process begins with establishing a main research
question, which will be split into a number of sub-questions.
In order to tackle the established objective, we will focus on the concepts of APM and
consequently our main research question is formulated as follows:
• How is the engineering company able to assess success of infrastructure projects in
agile managed environment?

In order to structure the research subject and to give an answer to the main research question, a set
of four sub questions are formulated, which are the following:

SQ1 How do we define success in Agile Project Management (APM) environment?

This sub question corresponds with first phase of the thesis (A. Preparation). It has been treated
Chapter 2

through an extensive literature study of areas such like Performance measurement, Success Factors,
Success Criteria, Key performance indicators and Agile Project Management (APM).

5
Q Methodology is a research method used in psychology and in social sciences to study people's subjectivity. It is further explained in
page 39.

5
S Solis Vuurmans
https://t.me/PrMaB
SQ2 What is the best framework to assess success of projects handled in APM?

This part corresponds to the second phase of the study (B. Research). After the review of project

Chapter 3
documentation, semi-structured interviews will be conducted with people involved in project
development. Initial identification of success factors will be done in order to formulate a classification
method. This will help, as a result of the research, to detect the main changes obtained by the use of
APM.

SQ3 What are the most influential factors for success?

In this phase (B. Research), we proceed to analyse the obtained data and compare it to literature and

Chapter 4
professional input. The questionnaire will provide the input needed to classify and to give a ranking to
the different Critical Success Factors (CSF).

SQ4 How can this information be useful within the company?

In this final stage of the research (C. Findings), the collected data will be reviewed within the

Chapter 5
company’s management methodology for its validation and implementation. The ways to maximize
opportunities of positive factors and minimize problems by the negative factors.

1.3 RESEARCH METHODOLOGY

In order to give an answer to the research question a work plan has been designed, which is shown
in the figure presented below.
The research started with (A. Preparation) a literature study about key concepts, such as:
definition of success, project performance indicators (with a focus on Critical Success Factors), Agile
Project Management, and the traditional waterfall model.
The main part of the recollection of information (B. Research) is done by documentation review,
personal interviews and a questionnaire. Their results and outcome allowed a ranking of the identified
CSF and the success framework per perspective has been elaborated.
Based on the research results and the obtained success framework (C. Findings) significant
opportunities of applying APM in infrastructure projects have been identified.
Finally (D. Conclusions) a set of conclusions and recommendations are formulated.

6
S Solis Vuurmans
https://t.me/PrMaB
 A. Prepara)on B. Research C. Findings D. Conclusions

• Success • Exploratory • Q sor)ng • Conclusion

• Agile project interviews • Results of Q • Recomenda)on
management • Researching the sor)ng
• Tradi)onal Cri)cal Success • Areas of
project Factors improvement
management • Defining the Q-
anor waterfall set
model

Figure 1-3 | Conceptualization of methodology

1.4 SCOPE OF THE RESEARCH

As already mentioned before, the main setting within which the most relevant information has
been collected during the A. Preparation and B. Research period (January - August 2015) has been
the engineering company of Grontmij in the Netherlands. Grontmij provides consultancy, design &
engineering and management services in a broad range of market sectors related to the built and
natural environment.
Grontmij is a leading consulting and engineering firm, focused on the principle of sustainability
by design with a wide range of projects: from infrastructure, light rail, sustainable buildings to water
management (Lavèn, 2014). The company was established in 1915 in The Netherlands. Since then
they have expanded towards other regions of Europe (Denmark, Sweden, Belgium, UK, Germany
Poland) and to the rest of the world (Turkey and China). Grontmij has approximately 6,000
professionals around the world.

The recollection of information has

been carried out in Grontmij
headquarters offices in De Bilt, where
the company had provided all the
facilities in order to be able to work on
the present thesis.
As Cobb (2011) mentions, Grontmij
does not count with a general overall
applied concrete agile management tool,
and that it requires a more personalized
management tool based on a
combination of different tools from
Figure 1-4 | Company’s simplified organizational structure by
Grontmij (2015)
different methodologies. However, it is
interesting to note that scrum has been
used in its GIS ICT Department for
some time now consistently and that it is also used in different levels of intensity in a few engineering
projects in some of their specific development stages.
The main objective of using scrum was to minimize cost and planning failures on earlier stages of
the project (Kroon, 2014). The use of scrum and the daily meetings make sure that the project team is
permanently informed about the real status of project development and that any feedback can be
treated rapidly.

7
S Solis Vuurmans
https://t.me/PrMaB
 Figure 1-5 | Project life cycle where Grontmij is involved

The Figure above shows the different project phases that take place within the Grontmij
Company. The phases where the scrum tool mainly has been used are those related to the pre design,
design, and/or contracting stage of the project.

1.5 THESIS OUTLINE

The thesis document outline is presented in the next figure, where we can see that the document is
divided into six main chapters. In Chapter I the overall description of the research is given. Chapter II
presents an overview of the theoretical background needed to fulfil the objective of the thesis
research. Chapter III is where, based on the steps of the Q methodology, we first make a proposal of
the Q set based on literature (using Critical Success Factors - CSF), we define the type of background
of our respondents (P set) and gather their results. In Chapter IV the research results are analysed and
– with the use of the PQMethod software - quantifiable data are obtained. Based on the results, in
Chapter V, the particularities of the use of scrum are described specifically in Grontmij where after
final conclusions and recommendations in a more general context are presented (Chapter VI).

8
S Solis Vuurmans
https://t.me/PrMaB
 Chapter 1: Introduc)on
• Problem
• Objec)ve
• Research ques)on
• Research methodology
• Scope
Chapter 2: Theore)cal framework
• Defini)on of success
• Project performance measurements
• Agile project management (Scrum)
• Tradi)onal Project Management
• Q methodology
Chapter 3: Research
• Exploratory interviews
• CSF in literature
• Defini)on of Q set
• Defini)on of P set
• Ques)onnaire
Chapter 4: Analysis and results
• Respondents of ques)onnaire
• PQMethod soUware process
• Defining the perspec)ves
• Comparing the perspec)ves
Chapter 5: Recommenda)on Grontmij
• How has scrum been used?
• Areas of improvement
Chapter 6: Conclusions and Recommenda)ons
• Conclusion
• Recomenda)ons

Figure 1-6 | Thesis document outline

1.6 DISCUSSION
As mentioned earlier in this chapter, the complexity of the construction industry has enormously
increased during the last decades. On the other hand, changing circumstances and certain internal
factors during the construction phase can lead to situations where the project does not proceed
according to the initial plan and budget, which may seriously affect the company’s image. After all,
construction companies are looking for quality and success in order to maintain its competitive
position; and in order to maintain its competitive position appropriate management is required.
Traditionally, success was measured by three factors of scope, time and cost (the so-called “Iron
triangle”), but because of the increasing complexity of the infrastructure sector, also the concept of
success has changed and is viewed within a much broader context. The engineering and consultancy
company, Grontmij, which has been an important stakeholder in the present thesis research, has done
a lot of efforts to design methods and tools to maximize its success factor, where one of the crucial

9
S Solis Vuurmans
https://t.me/PrMaB
success factors is considered to be the client´s satisfaction. However, there are also other success
factors, which may play a critical role in determining a project being successful or not.
It is also important to mention that Grontmij is one of the first Dutch companies that apply Scrum
(or also called Agile Project Management - APM) as a project management methodology, which is a
flexible, iterative and incremental project management methodology based on continuous deliverables
and feedback. Scrum is supposed to be one of the management methodologies that are best adapted to
dynamics and changes in the project context. And in general, the more complex the infrastructure
projects are, the more difficult it is to cope with changes in the context.
So taking into consideration the above, the objective of the thesis research is formulated as
follows: To design a success framework using Critical Success Factors (CSF) in infrastructure
projects managed by Agile Project Management methodology (Scrum). The research question is
directed to the inquiry how the engineering company is able to assess success of infrastructure
projects in agile managed environment, and is split up into four sub questions (SQ), which are:
SQ1: How to define success in Agile Project Management (APM) environment?
SQ2: What is the best framework to assess success of projects handled in APM?
SQ3: What are the most influential factors for success? (CSF)
SQ4: How can this information be useful within the company?

10
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER II
“Success is not final, failure is not fatal: is the courage to continue that
counts” (Winston Churchill)

In this chapter the first part of the theoretical framework will be set up. First a definition of project
success will be given (2.1). Next the different performance measurements used in projects are
explained (2.2), especially the Critical Success Factors (2.2.1) since these are the ones we will use
in our further research as basis of our success framework, followed by a brief explanation of the
Agile Project Management methodology or ‘scrum’ (2.3) but also the more traditionally used
methodology, the so called ‘Waterfall model’ will be treated in this chapter (2.4). Additionally
there will be an explanation of the Q-Methodology used in this research (2.5) and the conclusions
based on the theoretical framework presented (2.6).

2 THEORETICAL FRAMEWORK
In this paragraph the theoretical framework will be discussed. The discussion of the three
cornerstones of this research (project success, project performance and scrum) will provide an answer
to the following research sub question.

SQ1: How do we define success in Agile Project Management (APM) environment?

Answer SQ1 summary: The first step in order to judge success in a project is
The success in projects managed in an agile to define the concept of ‘success’. We will proceed to
environment is concentrated in the process. make a literature research of this concept and try to link it
And in order to be able to give an answer to
with the project management methods involved in the
the question about ‘What influences
success?’, the most appropriate tool for this
process of the project. In this way we may be able to
purpose is the identification of a framework identify the factor that influence the end result when a
of Critical Success Factors (CSF). non-traditional methodology, in this case scrum, is used.
We will base this research by using Q-Methodology,
which will quantify subjective data of the respondents in
order to obtain different perspectives, or factors. These points of view of success will help us validate
the success framework proposed as well as point out the possibilities of agile in the construction
industry.

2.1 DEFINITION OF PROJECT SUCCESS

For many years, authors have tried to define project success and found this a very complex issue
(de Wit 1988; Alzahrani and Emsley 2013). Fact is that project success can have a different meaning

11
S Solis Vuurmans
https://t.me/PrMaB
to each one of the stakeholders involved in a project. Tabish and Jha (2011) state the following about
this issue: “…what makes it difficult to assess whether a project has achieved success or has failed is
the lack of an universally accepted definition of project success and the fact that the concept of
success remains vague among stakeholders”.
So first of all it is important to identify clearly what you understand by “success”. When it is
unclear what project success means, it will be of course difficult to measure the success of a project
by means of success criteria or to improve success with the help of success factors. It is also important
to highlight that project success may have different meanings to different people. A project that is
successful in the opinion of a client is not necessarily also a success in the eyes of a contractor and
vice versa. And even if these two parties both experience a project being successful there might be
other stakeholders who think differently about it.
Many authors have tried to define what project success means. In general, all of them use a
combination of criteria, which as a whole indicates the success of a project. The Iron Triangle (in
time, without cost overruns and in accordance with specifications) is the set of criteria that is mostly
mentioned in scientific literature, although there are also authors who say that using just these three
factors is not enough.
De Wit (1988) in his definition does not mention two out of three Iron Triangle criteria, and he
states that: “The project is considered an overall success if the project meets the technical
performance specifications and/or missions to be performed, and if there is a high level of satisfaction
concerning the project outcome among: key people in the parent organization, key people in the
project team, and key users or clientele of the project effort.”
Lam, Chan et al. (2008) who did research on the determinants of successful Design and Build
projects also do not directly mention the Iron Triangle but state that the performance of Design &
Build projects are a success when the client’s criteria are met. Although it is not unlikely that a client
would aim for criteria like in time, under budget and good quality.
Atkinson (1999) on the other hand, maintains the Iron Triangle as a starting point, but he also tries
to initiate a discussion about the possibility that we have been using the Iron Triangle criteria for years
without being sure that these are the one and only criteria to measure project success. Therefore he
recommends to consider and to apply new additional criteria. This view is shared by many other
authors like Tabish and Jha (2011), who mention success criteria like safety performance, satisfaction
of stakeholders and the status of any dispute(s) as important additional success criteria.
Gudiene, Banaitis et al. (2013) stress the importance of examining project success from a more
holistic perspective instead of just limiting to the three criteria of the iron triangle. However they do
not give their own definition of project success, according to them, there is no list that would be
completely comprehensive. Westerveld (2003) agrees that it is not possible to make a universal
checklist of success criteria that is applicable to all kinds of projects. In his Project Excellence Model
he makes a clustering of criteria that “…together had to cover the whole issue of project success in
the broadest sense”. This set is called the result area of the Project Excellence Model and contains a
clustering of criteria that all together define project success. Not only the iron triangle (or golden
triangle according to Westerveld) but several other criteria that focus on the satisfaction of different
parties involved in the realization of a project are included into this model. These criteria and their
explanation are displayed in the figure below. With the Project Excellence Model, Westerveld (2003)
distinguishes himself from other authors by combining success criteria and success factors into one
model where others solely focus on one of these aspects.

12
S Solis Vuurmans
https://t.me/PrMaB
 Figure 2-1 | Project excellence by Westerveld (2003)

2.1.1 Success of the final result vs. success of the process

An extra dimension that needs to be added to the discussion about the concept of “success” is that
several authors (de Wit 1988; Munns and Bjeirmi 1996; Collins and Baccarini 2004) indicate that
success can be related to two different approaches namely: project success (also called product
success) and project management success.
Project success, or product success, covers the full lifecycle of a project. This includes the very
first idea of starting a project up to the day of the project closedown. Overall project success focuses
on the impact of the project’s final product, where the satisfaction of the end-user is considered to be
the most important criterion (Collins and Baccarini 2004). On the other hand, project management
success comprises a shorter period of time, which can best be described as the realization phase of a
project. During this phase contractors are working on the project. During this period, the ‘Iron
Triangle’ criteria are most important together with the satisfaction of project stakeholders like the
client and the project team.
In other words, the perception of success not only depends on whose perspective one looks, but
also on which moment of a project’s lifecycle is considered. This makes that projects, which are over
budget or have suffered delays can still become successful projects. Although the other way around -
project management success resulting in a project failure - is also possible. Even though good project
management cannot prevent a project failure later in time, project management can still influence the
success of a project, while the reverse is not possible (Collins and Baccarini 2004).

2.1.2 Research’s definition of success

The success is a concept that we need to define in order have a goal to aim for the research. Since
the key question of the questionnaire is ‘what are the factors that influenced the success in the
project?’ The respondent needs to know our concept of success since it is still a subjective perception.

13
S Solis Vuurmans
https://t.me/PrMaB
 But what is exactly what we are trying to replicate? Since our goal is to identify opportunities to
improve the process success, and we believe a good way to define it is by the word ‘happiness’ by the
three major parties involved: the client, the company and the engineers involved.

Figure 2-2 | Focus on success through project personnel based on Westerveld (2003)

We will proceed to define it as following:

• Happiness of the client: Where the client accepts the product delivered in a favourable
manner. And there is high possibility to continue to do business with him in further stages
of the project and/or is more inclined to continue to give work to the company in future
projects.
• Happiness of the company: Any company is healthy if they make a profit out of their
work.
• Happiness of the people involved: This was the most difficult to define, since the project
process differs from project to project since they could be managed differently.

Our objective of establishing a success framework for projects managed in scrum environment
it’s imperative to identify what is the success we are aiming for. With the research methodology of
using the questionnaire of Q-Methodology we will be able to identify the major Critical Success
Factors that influence success.

2.2 PROJECT PERFORMANCE MEASUREMENTS

The purpose of performance measurement is to help organizations to understand how decision-
making processes or practices have led to success or failure in the past and how this understanding
can lead to future improvements.

14
S Solis Vuurmans
https://t.me/PrMaB
 Project management performance metrics helps in building predictability, improving
organization’s decision making ability, and lays out what is working and what is not working within
the organization and helps to guide the management focus in the right direction (Institute, 2013),
thanks to the fact that it enables Project Managers to:
• Assess status of on-going project in terms of schedule, cost and profitability.
• Foresee any potential risks.
• Nail down the problems much before they become severe.
• Keep a check on project profitability.
• Assess productivity of team.
• Assess quality of work products to be delivered.

There exist different project management metrics, whose use and application depends on the
complexity and nature of each project. The Critical Success Factors describe the impacts of this
factors in project performance (Belassi & Tukel, 1996) is one of those metrics, and will be described
into detail in the following chapter.
Additionally we name other commonly used project performance measurements, which are: Key
Performance Indicators (KPI), Success Criteria, and Failure Costs.
KPIs are general indicators of performance that focus on critical aspects of outputs or outcomes
(BREAM, 2014). Success Criteria are the most common way of defining a project, as being
successful, most known are: time, cost and scope (Atkinson, 1999). And the last one that we will
overview is failure costs which are extra costs of the process related to unconformity of the
requirements and present a quantifiable data of the impact of errors during the process (Barber,
Graves, Hall, Sheath, & Tomkins, 2000).

2.2.1 Critical Success Factors (CSF)

One of the first authors who mentioned the term “critical success factors” was Rockart (1982). He
defined critical success factor (CSF) as: “...the limited number of areas in which results, if they are
satisfactory, will ensure successful competitive performance for the organization”. As Rockart (1978)
mentions, critical success factors (CSF) are, for any business, the few key areas where ‘things must go
right’ for the business to flourish. Some years later, de Wit (1988) describes success factors as the
combination of inputs and circumstances that directly or indirectly influence the success of a project.
In this study it is assumed that success factors are the input to enhance a successful outcome of a
construction project; in other words, the elements that are needed to steer a project towards success.
Another definition by Hofer and Schendel (1979) is that CSF are those variables that the
management can influence through its decisions affecting the overall competitiveness of the company.
The factors usually vary from industry to industry.
According to (Freund, 1988) the characteristics of the CSFs in order to achieve overall corporate
goals and objectives, must be:
• Important to achieving overall corporate goals and objectives,
• Measurable and controllable by the organization to which they apply.
• Relatively few in number—not everything can be critical.
• Expressed as things that must be done—not the end point of the process.
• Applicable to all companies in the industry with similar objectives and strategies.
• Hierarchical in nature—some CSFs will pertain to the overall company, while others will be more
narrowly focused in one functional area.

In summary, we can say that during the last decades many authors have tried to identify the
concept of CSF and to highlight its importance in order to increase the successful outcome of a
project. The present thesis research and the definition of our final set of CSF to be used, is based on a
review of articles and graduation projects that are focused on the identification of the most critical

15
S Solis Vuurmans
https://t.me/PrMaB
success factors and which have been selected because they aimed especially at construction projects
and ICT projects.
Further below every publication will be reviewed shortly. The review is focused on the way the
authors categorize success factors and which factors they appoint as most critical to project success.
The aim of the review is to determine which success factors are cited the most; these factors will be
adopted into the thesis research.
Pinto and Slevin (1987) performed a survey research among managers in the engineering field.
The respondents were asked to generate success factors that were, in their eyes, crucial to successful
project implementation. Nine factors that were indicated by both the survey respondents and the
literature were used in a quasi-sequential framework. The main factors involved were: ‘Clearly
defined goals’, ‘Competent project manager’, ‘Top management support’, ‘Competent project team
members’, ‘Sufficient resource allocation’, ‘Adequate communication channels’, ‘Control
mechanisms’, ‘Feedback capabilities’ and ‘Responsiveness to clients’, which were incorporated into
the literature study.
Pinto and Covin (1989) also indicate different types of factors. They mention ten critical success
factors that can be influenced by the project team and four external factors that can have a significant
influence on the success of a project, but which are often not under control of the team. These
fourteen factors are all incorporated into the literature study. The publication is very representative for
construction projects because it is based on the responses of 408 project managers in this particular
field.
Chua, Kog et al. (1999) mention 67 success-related factors divided into four different project
categories (project characteristics, contractual agreements, project participants, interactive processes).
By means of a questionnaire among senior managers in construction companies the success factors
were ranked for different project objectives. All the success-related factors of this publication were
used in this thesis.
As stated already in section 2.1, Westerveld (2003) links success criteria to success factors in his
‘Project Excellence Model’. The latter is called the result area, which consists of six categories of
success factors, namely: Leadership & Team, Policy & Strategy, Stakeholder management,
Resources, Contracting and Project management. The success factors mentioned in this publication
were integrally adopted in this thesis.
Phua and Rowlingson (2004) performed research on the question how important cooperation is to
construction project success. Data obtained from 29 interviews indicated that there is a causal link
between cooperation and project success. During the interview sessions factors were suggested that
previously did not show up in literature like, ‘Personal friendships between project participants’, and
‘Good site protection against theft’. With the help of a component analysis a large group of success
factors was clustered into five distinct categories including: ‘Cooperation’, ‘Micro project
environment’, ‘Contractual characteristics’, ‘Site conditions’, and ‘Political and economic stability’.
The factors mentioned in this publication were very relevant for this research since there is focus on
collaboration and cooperation.
Fortune and White (2006) performed a literature study in which 63 publications were included. It
concerned researches that studied successful and unsuccessful projects. They looked which factors
appeared most in the work of these other authors. The outcomes were used to build a so called
‘Formal systems model’ that can be used to determine if a project is a success or a failure. For this
research only the input of this study, the 26 mentioned success factors were used. ‘Support from the
senior manager’ was cited most (39 times), followed by ‘Clear, realistic objectives’ (31 times) and
‘Strong/detailed plan kept up to date’ (29 times). Five of the authors mentioned by Fortune and White
(2006) were also used in this very research, namely: Pinto and Slevin (1986), Munns and Bjeirmi
(1996), Belassi and Tukel (1996), Cooke-Davies (2001) and, Westerveld (2002). The literature study
performed in the publication served as a rough model for the literature study of this thesis.
Lam, Chan et al. (2008) focused on factors that are important for Design & Build projects (DBM).
With the aid of a multiple regression analysis twelve categories of factors are constructed. The highest
16
S Solis Vuurmans
https://t.me/PrMaB
scores are amongst ‘Competency of client body’, ‘competency of construction team leader’ and
‘effectiveness of project management action’. This publication was the only in its sort that specifically
aimed at Design & Build projects, which made the publication extra relevant for the project since this
is a DBM project. All the success factors mentioned in the publication were used in this literature
study.
Tabish and Jha (2011) used the data of 105 respondents to perform a factor analysis on 36 success
factors derived from other publications resulting in four main categories. ‘Awareness of and
compliance with rules and regulations’ is appointed as most important category. Followed by ‘Pre-
project planning’ and ‘Clarity in scope’, and ‘Effective partnering among project participants’. A
similar research was performed by Alzahrani and Emsley (2013). In this case 164 clients, contractors
and consultants participated. Resulting in the distribution of 29 success factors into nine different
clusters. Including, ‘Past performance’, ‘Resources’ and ‘Environment’.
This publication distinguished itself because it is focused solely on the impact of the contractors’
attributes on project success. Gudiene, Banaitis et al. (2013) composed a conceptual model which
included seven clusters of critical success factors. The seven clusters are: ‘External factors’,
‘Institutional factors’, ‘Internal factors’, ‘Project related factors’, ‘Project management/team member
related factors’, ‘Contractor related factors’, ‘Client related factors and Stakeholders’. Just like in this
thesis, this publication is looking at the differences in success factors between contractors and clients.
From these three researches only the input regarding success factors was used in the literature study.
The different categories resulting from the factor analysis did not seem to fit with the outcomes of the
literature study performed in this thesis.
Out of these publications a list of approximately 300 success factors was selected (see Appendix
D, page 133). Since every author used slightly different descriptions of the factors, firstly the success
factors were grouped into different clusters (for instance, project related, external, contract related) to
make a rough division in factors6. Within the clusters, factors with (almost) the same meaning were
merged into one factor, while at the same time the authors that appointed this combined factor were
registered. The final product is a list of 38 success factors that will be the base of our Q-set (see page
40).

2.2.2 Key Performance Indicators

The purpose of the Key Performance Indicators (KPIs) is to enable measurement of project and
organizational performance throughout the construction industry (The KPI Working Group, 2000).
Collin (2002) advocates that the process of developing KPIs involved the consideration of the
following factors:
• KPIs are general indicators of performance that focus on critical aspects of outputs or
outcomes.
• Only a limited, manageable number of KPIs is maintainable for regular use.
• Having too many (and too complex) KPIs can be time/resource consuming.
• The systematic use of KPIs is essential as the value of KPIs is almost completely derived
from their consistent use over a number of projects.
• Data collection must be made as simple as possible.
• A large sample size is required to reduce the impact of project specific variables.
• For performance measurement to be effective, the measures or indicators must be
accepted, understood and owned across the organisation.
• KPIs will need to evolve and it is likely that a set of KPIs will be subject to change and
refinement.
• Graphic displays of KPIs need to be simple in design, easy to update and accessible.

6
The description of each CSF defined in this research will be further explained in detail in chapter III, paragraph 3.2, page 46.

17
S Solis Vuurmans
https://t.me/PrMaB
 With these factors in mind,
a set of KPIs including
objective indicators and
subjective ones is developed to
measure the performance of a
construction project. With
reference made to Chan’s
(1996, 1997) and Naoum’s
(1994) earlier research, each
KPI will be discussed into
detail and practical approaches
to measure these KPIs will be
introduced. The calculation
methods of the proposed KPIs
are divided into two groups.
The first group uses
mathematical formulae to
calculate the respective values.
Formulae will be presented
after the detailed explanation of
each KPI, such as time, cost,
value, safety and
environmental performance.
Figure 2-3 | KPIs for project success according to Weber and Thomas The other group uses subjective
(2005) opinions and personal
judgement of the stakeholders.
This group includes the quality, functionality of building and the satisfaction level of various
stakeholders. A seven-point scale scoring system is adopted to measure these KPIs. As will be
discussed in the following paragraphs, there are nine KPI categories in total; each KPI may include
one or more measuring methods. Webber and Thomas (2005) have developed a figure that differs
objective and subjective KPIs (see Figure above).
It is a performance tool that it is used to measure success (Chan & Chan, 2004). But the only way
of knowing whether those goals are being delivered is by identifying indicators of their success and
using them to keep an eye on the way the project is performing.
It is used in order to benchmark businesses and/or projects against each other. Benchmarking
provides a 'yardstick' by which you can judge your performance. For example it can be used in: client
satisfaction, defects, construction time and cost, productivity, profitability, health, safety, employee
satisfaction, staff turnover, sickness absence, working hours, qualifications & skills, impact on
environment, whole life performance, waste, commercial vehicle movements, etc. (BREAM, 2014).

2.2.3 Success Criteria

Success criteria should not be confused with success factors; the first are outcomes of a project or
achievements of an organization that are needed to consider the project a success or to esteem the
organization successful (outcome oriented), while success factors are a set of conditions,
characteristics or variables that must go well during the project execution in order to ensure success
for a project or organization and that must be given special and continual attention to bring about high
performance (process oriented).
Also known as terms of acceptability by the Institute of Project Management (United States). The
Association of Project Managers (UK) defines it as a way to measure success by the stakeholders,
while it is identified at the start of the project (Management, 2006).
In mainstream project management practice, project success is traditionally conceptualized and
operationalized based on the iron triangle of time, cost and quality (Pinto & Slevin, 1988). The

18
S Solis Vuurmans
https://t.me/PrMaB
conventional practice is that these output-based measures are only assessed at the end of a project
(Dainty, Cheng, & Moore, 2003). The reason why these measures are so popular is that they are
simple to apply and also largely objective, particularly for time and cost (Latham, Fay, & Saari, 1979;
Pinto & Slevin, 1988). However, in recent times, there has been an acknowledgement that limiting the
success criteria to these traditional measures excludes the long-term satisfaction of the relevant
stakeholders (de Wit, 1988). Thus, in recent times, the contemporary ideology is to view success
criteria as both measures of the success of the production system in terms of time, cost and quality and
the benefit to stakeholders (de Wit, 1988).
In view of this, numerous project management researchers have developed alternative project
success frameworks. While these various frameworks conceptualize the success criteria against the
traditional measures, they also include criteria that represent the interests of other stakeholders.
Subsequently, new and emerging criteria such as health and safety, technology, environmental
friendliness, risk containment, client satisfaction and stakeholder’s satisfaction have become an
accepted part of these emerging frameworks.
The framework developed by Pinto and Slevin (1988) has been the driver behind a number of
studies aimed at identifying project success criteria (de Wit, 1988; Lim & Mohamed, 1999; Morris,
Patel, & Wearne, 2000). This framework is based on the premise that the key factors in the
implementation of successful projects incorporate three criteria: technical validity, organizational
validity and organizational effectiveness. Technical validity is the first hurdle in identifying success
criteria and this is assessed in the context of whether the project after completion performs as intended
(Pinto & Slevin, 1988). With respect to organizational validity, an important consideration is that the
project must be acceptable for the clients for whom it is intended. Furthermore, an important
condition about organizational effectiveness is that the project manager must be involved in making
sure that the ‘‘right’’ project is delivered to the client and/or user (Pinto & Slevin, 1988). Thus,
organizational effectiveness is how well the accepted project makes a positive impact on the user.
Success criteria are defined and agreed upon before beginning the project, and they are used to
evaluate the success at the end of the project. In summary, the key characteristics of these indicators
can be described as follows:
• Determined in the beginning of the project.
• Related directly to goals of the projects.
• Used to make trade-off decisions during the execution.
• Most relevant measures to acceptability, also known as product approval requirements.
They give a clear view on how the project will be managed and measured. Might be explicitly
stated on the Project Charter or Scope statement (Institute, 2013).

2.2.4 Failure costs

The variations in opinion about what is meant by failure costs is to a great extent caused by the
differences in focal point that exist under the group of researchers.
According to Hegazy et al. (2011) and Love et al. (2009) the definition of failure costs is based on
having to repeat completed activities that did not meet the requirements (rework). Their research is
focused on the execution of a construction project and they appoint failure costs being the costs as a
result of "the energy invested in the re-run of a process or activity, which initially was not adequately
implemented". They describe this rework as a result of the complex environment in which "several
activities are carried out simultaneously, making mistakes and misunderstandings take place"
(Hegazy et al, 2011; Love et al., 2009).
Josephson (1998) also looks at the implementation stage of a building project but focuses on
emergent defects. Defects are defined as non-fulfillment of the intended use requirements as a result
of unclear or lack of these requirements. Then, the defect rate is defined as: "the value of the use of
resources for rework which occurs as a result of defects" (Josephson, 1998).

19
S Solis Vuurmans
https://t.me/PrMaB
 Both definitions focus on the failure of the product, while it is not looking at the process that leads
to this product. The study of Avendano Castillo et al (2010) also focuses on the costs of failure in the
implementation phase of a project and defines failure costs as "all unnecessary and avoidable costs
that occur during the project, by both product and process variations, which show themselves as cost
overruns, delays and low quality”.
While these definitions are formulated on the basis of rework (repairs), the definition of the
Building Research Foundation focuses on a broader failure costs spectrum. They define as: "Failure
costs are all costs that are caused by the construction process is unnecessarily inefficient expired, or
the final product did not meet the agreed quality or because of things that were flawed or inadequate
had to be repaired or replaced" (Building Research Foundation, 2005).
Like the definition of Avendano Castillo et al. (2010) describes this definition both the situations
where the product is indeed approved, but more efficiently could have been developed, as well as
situations where the product is not approved and should therefore be improved. Unlike Castillo
Avendano et al. (2010) they do not focus only on projects in the actual construction phase, but their
definition also applies to activities of, for example, architects and engineering companies.
Love and Irani (2003) note that prevention and evaluation costs never are avoidable, but that
failure costs, in principle, are " avoidable because most of these are caused by ineffective management
techniques" (Love & Irani, 2003).
When the different definitions are placed next to each other, it can first of all be noted that almost
all of these definitions have been formulated for the execution phase of a construction project. What is
remarkable is that no definitions are found in the literature that look specifically at the preparatory
phase of a project, and that all the definitions relate to the implementation phase of a project.
As a resume, and based on the definitions found in the literature placed within the context of this
thesis research, failure costs are defined according to Building Research Foundation and Avendano
Castillo et al. (2010) as a combination of failure in the process as well as failure in the product. The
definition, which will be further applied in the study, is as follows:
Failure costs are all additional and avoidable costs incurred by unnecessarily or inefficient
procedures, as well as additional costs when the final product does not meet the agreed quality, is
inadequate or defective and need to be repaired or replaced.

2.2.5 Discussion
Since around the eighties a lot of literature has been published, in which authors have tried to
define what they understand by project success. Although there exist lots of variety between them
about its definition, all of them agree that success comprises a combination of criteria that together as
a whole indicates the success of a project. The most traditional combination is the “Iron Triangle”,
which consists of three criteria (in time, without cost overruns and in accordance with specifications).
But other authors, who stress the importance to look at project success from a more holistic point of
view, argue that new and/or additional criteria have to be considered.
It is widely known that measuring project performance is important and that it provides the
company with a clear picture of the health of its projects. The usefulness of measuring project
performance is evident and they are important contributors to company´s success. For the thesis
research, four project performance metrics were identified that cover the most crucial aspects of a
project to be measured during its implementation, which are the followings:
1. Critical Success Factors (CSF) that are a set of conditions, characteristics, or variables that
must go well in order to ensure success for a project or organization and that must be given
special attention to bring about high performance (process oriented);
2. Key Performance Indicators (KPI) that evaluate the achievement or success of a project and
generally success is defined in terms of making progress towards goals that are fixed at the
start of the project;

20
S Solis Vuurmans
https://t.me/PrMaB
 3. Success Criteria that should not be confused with CSF. Success Criteria are outcomes of a
project that are needed to consider the project a success (outcome oriented) and are defined
with the objectives and may be quantified by Key Performance Indicators.
4. Failure Costs are all additional and avoidable costs incurred by unnecessarily or inefficient
procedure, as well as additional costs when the product does not meet the agreed quality, is
inadequate or defective and need to be repaired or replaced.
Since the thesis research is focused on a process-oriented management methodology, the most
appropriate project performance measurement metric selected for further research has been the one
centred to the identification of the most appropriate combination of Critical Success Factors (CSF).
Based on an extensive literature review, in which a wide range of critical success factors has been
identified, finally a combination of 38 critical success factors was selected for the purpose of the
present thesis research taking into consideration the frequency and priority ranking given to the
criteria identified in literature and that the present research is specially oriented to infrastructure
projects. The description of this process will be detailed in chapter 3: The research.

21
S Solis Vuurmans
https://t.me/PrMaB
2.3 THE AGILE PROJECT MANAGEMENT
METHODOLOGY
2.3.1 What is Agile?
Agile Project Management
(APM), with Scrum being its main
tool, is considered a relatively new
project methodology and is focused
on iterative and incremental products.
APM initiated in the ICT industry but
in the past years it has evolved into
other areas such as the construction
industry (Layton, 2012).
APMis a methodology for
managing product development. It
defines a flexible, holistic product
development strategy where a team
works as a unit to reach a common
goal (Beck et al., 2001). It challenges
assumptions of the traditional,
sequential approach to development,
and enables teams to self-organize by
Figure 2-4 | Comparison of waterfall and APM deliverables based encouraging physical co-location or
on Smith (2015). close online collaboration of all team
members, as well as daily face-to-
face communication among all team members and disciplines in the project.
A key principle of scrum is its recognition that during a project the customers can change their
minds about what they want and need, and that unpredicted challenges cannot be easily addressed in a
traditional predictive or planned manner. The agile philosophy comprises delivering as rapidly as
possible high value products. It also ensures that within a fixed time the greatest value in terms of the
functionality as prioritized by the client is delivered. The shift for both the organization and the
project manager is one from the delivery of a project to schedule and budget to one of delivery of the
highest value within the time and other constraints set (Lester, 2006).
The whole definition of the concept of ‘Agile’ cannot be contained only by the use of ‘scrum’ and
the avoidance of use of the ‘waterfall processes within the project. As Cobb (2011) mentioned, APM
presents many advantages “…some businesses requires a balance of control and agility, which may be
suited to a hybrid approach.” (Cobb, 2011, p. 1)
So, as shown in the following figure, the idea behind APM lays in the change of the
straightforward and rigid goal mentality towards a more iterative and evolving one. The initial
waterfall model has been perceived as heavily burdened with documentation, cumbersome, ineffective
and extremely bureaucratic (Cobb, 2011) giving almost to none space for reflection or revision. The
Agile model is more of an iterative life cycle where the product is shown, feedback and improved
before final deployment.

22
S Solis Vuurmans
https://t.me/PrMaB
2.3.2 Core principles of APM
In the Agile manifesto (Beck et al., 2001) the following core principles of Scrum are highlighted:
“Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.”
It also mentions that even though they also recognize the importance of items like: processes,
tools, documentation, contract and a Plan. The emphasis is: team empowerment, collaboration, client
involvement and adapting to change.
The agile principle is to maximize the value to the end user (Sutherland, 2014). It relies on
flexibility in order to achieve it. A relation can be given between: the value for the client, the price of
the contract and the budget of the company (Ridder, 2011). According to Sutherland (2014) the idea
of scrum as a project management methodology is to welcome flexibility in order to increase the
value for the client. As shown in the following figure, a small change in the cost of the project might
result in an important increase in value for the customer.

Figure 2-5 | Conceptual model of the maximization of value

2.3.3 Different roles in Scrum

Scrum will be one of our major focuses in this report as nowadays it is gaining increasing
importance and becoming a widely accepted tool of the agile methodology, which is best adapted to
dynamic project context.
“Scrum is an agile development model based on multiple small teams working in an
intensive and interdependent manner. The term is named for the scrum (or scrummage)

23
S Solis Vuurmans
https://t.me/PrMaB
 formation in rugby, which is used to restart the game after an event that causes play to stop,
such as an infringement. Scrum employs real-time decision making processes based on actual
events and information. This requires well-trained and specialized teams capable of self-
management, communication and decision-making. The teams in the organization work
together while constantly focusing on their common interests” (Cobb, 2011)
We can identify different predefined roles in scrum, which are: (i) the scrum master, (ii) the
product owner, and (iii) the team.

2.3.3.1 Scrum master

The scrum master is responsible to facilitate the scrum process. He is accountable for removing
impediments in order to make it possible to the team to deliver adequately the product goals and
deliverables. The scrum master is not a traditional team lead or project manager, but acts as a buffer
between the team and any distracting influences. The scrum master ensures that the scrum process is
used as intended. The scrum master helps to ensure that the team follows the agreed scrum processes,
often facilitates key sessions, and encourages the team to improve. The role has also been referred to
as a team facilitator (Leybourn, 2013) or servant-leader to reinforce these dual perspectives.
According to the (Alliance, 2013) the core responsibilities of a scrum master include, but are not
limited to:
• Helping the product owner maintain the product backlog in a way that ensures the project is
well defined and the team can continually advance forward on the project at any given time
• Helping the team to determine the definition of done for the product, with input from key
stakeholders
• Coaching the team, within the scrum principles, in order to deliver quality valuable features
for their product
• Promoting self-organization within the team
• Helping the scrum team to avoid or remove impediments to their progress, whether internal or
external to the team
• Facilitating team events to ensure regular progress
• Educating key stakeholders in the product on scrum principles

One of the ways in which the scrum master role differs from that of a project manager is that the
latter may have people management responsibilities while the scrum master does not. Scrum does not
formally recognize the role of project manager (Deemer, Benefield, Larman, & Vodde, 2010), as
traditional command and control tendencies would cause difficulties, however, it is possible for scrum
teams to work effectively with agile project managers, especially on large-scale programs (Mike Cohn
& Ford, 2003).

2.3.3.2 Product owner

Communication is a main function of the product owner. The ability to convey priorities and
empathize with team members and stakeholders are vital to steer the project in the right direction.
Product owners bridge the communication gap between the team and their stakeholders. They serve as
a proxy stakeholder to the development team and as a project team representative to the overall
stakeholder community (Pichler, 2010).
As the face of the team to the stakeholders, the following are some of the communication tasks of
the product owner to the stakeholders:
• Demonstrates the solution to key stakeholders who were not present in a normal iteration
demo
• Announces releases
• Communicates team status
• Organizes milestone reviews
• Educates stakeholders in the development process

24
S Solis Vuurmans
https://t.me/PrMaB
 • Negotiates priorities, scope, funding, and schedule
• Ensures that the product backlog is visible, transparent, and clear
Empathy is a key attribute for a product owner to have – the ability to put oneself in another’s
shoes. A product owner will be conversing with different stakeholders in the project – different
people, with a variety of backgrounds, job roles, and objectives. A product owner needs to be able to
see from these different points of view. To be effective, it would also be wise for a product owner to
know the level of detail the audience needs from him or her. The development team would need
thorough feedback and specifications so that they can build a product up to expectation, while an
executive sponsor may just need summaries of progress. Providing more information than necessary
may lose stakeholder´s interest and waste time. There is also significant evidence that face-to-face
communication around a shared sketching environment is the most effective way to communicate
information instead of written documentation. A direct means of communication is then most
preferred by seasoned agile product owners.
A product owner’s ability to communicate effectively is also enhanced by being skilled in
techniques that identify stakeholder needs, negotiate priorities between stakeholder interests, and
collaborate with developers to ensure effective implementation of requirements.

2.3.3.3 The development team.

The development team is responsible for delivering Potentially Shippable Increments (PSIs) of
product at the end of each sprint (the sprint goal). An ideal team is made up of 3–9 individuals who do
the actual work (analyse, design, develop, test, technical communication, document, etc.).
Development teams are cross-functional, with all of the skills as a team necessary to create a product
increment. The development team in scrum is self-organizing.

2.3.4 Description of the scrum process

The project management methodology is based on an iterative approach of breaking up the
development process into releases and iterations, which are called “sprints”. These are characterized
by two to four week periods, in which the team creates a solid deliverable. These features come out
the product backlog, which is a prioritized set of high-level requirements of work to be done. These
are determined and agreed upon during the planning meeting prior to the start of the first sprint.

Figure 2-6 | Detailed scrum process flow

25
S Solis Vuurmans
https://t.me/PrMaB
 In the figure above we see the conceptual process occurring in scrum. It consists seven steps
where all the major parties are involved.
1. First the product owner defines the product backlog (a list of items with all the required
features).
2. Prior to each release, a release-planning meeting is held. Where they define a high level plan
for the iterations and sprints ahead.
3. There is a sprint kick-off meeting, in which the team defines the sprint backlog (extracted
from the product backlog).
4. During each sprint, the team has daily meetings. Those meetings are short and normally
limited to 15 minutes. Each member is asked three questions: What have you accomplished
since the last Daily Stand Up (DSU)? What will you do before the next DSM? Is there
anything that is impeding your progress (remedies are discussed)?
5. Scrum relies primarily on verbal communication across all team members.
6. The goal of each sprint is to finish the established deliverables.
7. At the end of each sprint there is a sprint review where the finished products are checked.
There is also a sprint retrospective, where they see what worked and what needs
improvement, and apply the adjustments necessary for the next sprint.

2.3.5 Different tools in Scrum

APM presents some new ideas and tools into the project management environment: the most
outstanding are the scrum board, planning poker and the burn down chart.

2.3.5.1 Scrum board

Each row on the Scrum board is a user

story, which is the unit of work we
encourage teams to use for their product
backlog. During the sprint planning
meeting, the team selects the product
backlog items they can complete during the
coming sprint. Each product backlog item
is turned into multiple sprint backlog items.
Each of these is represented by one task
card that is placed on the Scrum board.
Each task card starts on the Scrum task
board in the “To Do” column. The columns
we generally use on a task board are:
• Story: The story description (“As a
user we want to…”) shown on that row.
• To Do: Place for all cards that are
not in the “Done” or “In Process” columns
for the current sprint.
• Work In Process (WIP): Any
card being worked on goes here. The
programmer who chooses to work on it
moves it over when she's ready to start the
task. Often, this happens during the daily
scrum when someone says, “I'm going to
Figure 2-7 | Example of scrum board
work on X task today.”
• To Verify (Review): A lot of tasks have corresponding test task cards.

26
S Solis Vuurmans
https://t.me/PrMaB
 • Done: Cards pile up over here when they're done. They're removed at the end of the sprint.
Sometimes we remove some or all during a sprint if there are a lot of cards.

2.3.5.2 Planning poker

Planning poker is a consensus-based, technique for estimating, mostly used to estimate effort or
relative size of tasks. In planning poker, members of the group make estimates by playing numbered
cards facedown to the table, instead of speaking them aloud. The cards are revealed, and the estimates
are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of
anchoring, where the first number spoken aloud sets a precedent for subsequent estimates (M. Cohn,
2005).
The reason to use Planning poker is to avoid the influence of the other participants. If a number is
spoken, it can sound like a suggestion and influence the other participants' sizing. Planning poker
should force people to think independently and propose their numbers simultaneously. This is
accomplished by requiring that all participants show their card at the same time.

2.3.5.3 Burn down chart and velocity

Progress on a
Scrum project can be
tracked by means of a
release burn down
chart. The Scrum
Master should update
the release burn down
chart at the end of
each sprint.
The horizontal
axis of the sprint burn
down chart shows the
sprints; the vertical
axis shows the amount
of work remaining at
Figure 2-8 | Example of burn down chart and its respective velocity
the start of each sprint.
Work remaining can
be shown in whatever unit the team prefers -- story points, ideal days, team days and so on.
This type of release burn down chart works very well in many situations and for many teams.
However, on projects with lots of changing requirements, you may want to look at an alternative
release burn down chart as a way of keeping your agile project on track.
The burn down chart is an essential part of any agile project and is a way for the team to clearly
see what is happening and how progress is being made during each sprint.

2.4 TRADITIONAL PROJECT MANAGEMENT OR

WATERFALL MODEL
Although the present thesis research is focused on the APM methodology (or also called “scrum”
by a lot of companies like Grontmij), we consider it important to give also – as comparison – a short
overview of the traditional project management methodology the “Waterfall model”.
The waterfall model is a sequential design process, used in development processes, in which
progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception,
initiation, analysis, design, tendering, construction, operation and maintenance.

27
S Solis Vuurmans
https://t.me/PrMaB
 Design -
Ini)a)on Pre-design Engineering Contrac)ng Tendering Construct

Figure 2-9 | Project phases in waterfall model

2.4.1 Critical Path Method in the Gantt chart

CPM or Critical Path Method is a
mathematical algorithm of the events used to
monitor the progress of a multitasked project in
an organization. It is also used to estimate time
required for the completion of the project. It is
usually designed in graphics or chart form to
facilitate easy tracking of the tasks, human
resources and finances.
These charts are called Gantt charts, after
Henry Gantt, who developed them. With the
advent of personal computers in the 1980s
Figure 2-10 | Example of Gantt chart used during
planning making it easy to create these intricate charts—
and to make them really complex—they have
become works of art. Every single step in a
project is laid out into detail. These charts truly are impressive to behold. According to (Sutherland,
2014) the only problem with them is that they always change throughout the project.

28
S Solis Vuurmans
https://t.me/PrMaB
2.4.2 Work Breakdown Structure (WBS)
WBS is a hierarchical and incremental
decomposition of the project into phases,
deliverables and work packages. It is a tree
structure, which shows a subdivision of
effort required to achieve an objective
(Servello & Evans, 2002). In a project or
contract, the WBS is developed by starting
with the end objective and successively
subdividing it into manageable components
in terms of size, duration, and responsibility
(e.g., systems, subsystems, components,
tasks, subtasks, and work packages), which
include all steps necessary to achieve the
objective.
The work breakdown structure provides
a common framework for the natural
development of the overall planning and
control of a contract and is the basis for
dividing work into definable increments
from which the statement of work can be
developed and technical, schedule, cost, and
labor hour reporting can be established
(Golany & Shtub).
A work breakdown structure permits
summing of subordinate costs for tasks,
Figure 2-11 | Example of a WBS which has three levels materials, etc., into their successively
higher-level parent tasks, materials, etc. For
each element of the work breakdown structure, a description of the task to be performed is generated.
This technique (sometimes called a system breakdown structure (Clark, 2009)) is used to define and
organize the total scope of the project .

2.4.3 How is it different from Agile Project Management (Scrum)?

In the planning of Scrum all project team members are involved in the planning process. During
the Sprint Planning meeting a Sprint Backlog is formed based on the Product Backlog, which
comprises an ordered and prioritized feature list of all things that needs to be done within the project.
In the Sprint Backlog all tasks which will be worked on in the coming one to four weeks are included.
In the Sprint Backlog tasks are not yet assigned to team members and there is also not yet decided on
a sequence of performance. During the Daily Scrum Meetings a more detailed planning is made, since
during these meetings team members assign tasks to themselves, which they will perform during that
day. Since team members themselves assign task, thus due to the self-organizing character, more
commitment to the planning is created. Also the fact that during the Daily Stand Up (DSU) each team
member has to report on his or her progress creates commitment.
For the control during the project agile, due to the self-organizing character of the teams,
information can flow more freely between the different specialists. Due to the daily meetings, which
are both part of the agile principles as well as the practices of Scrum, information is shared more
frequently and not only once complete. Flow is also created by the early and continuous delivery of
value and the corresponding recurrent feedback loops. Which was apparent in the first and the third
principle of Agile. The Value principle is advocated by the agile approach in the second and the tenth
principle. The Value principle is also present in Scrum in forms of the Product Backlog. The customer
can put all his requirements in this Product Backlog and can prioritize them. But the Scrum approach

29
S Solis Vuurmans
https://t.me/PrMaB
also recognizes that it is not possible for the customer to formulate all his requirements at the
beginning of the process. The Scrum process leaves room for the customer to change his requirements
corresponding new insights and ideas during the process (Koskela & Howell, 2002). In conventional
project management it is assumed that the customer sets the scope for the project at the beginning of
the process and does not change the scope throughout the process as variances from the predetermined
scope, or thus changes of the scope, are considered highly undesirable (Koppenjan et al., 2010). Thus
the scope is fixed and the time and resources, costs, can vary in order to cope with problems. In
contrast with the agile approach, in which the scope can vary, corresponding new insights and ideas of
the customer, and the resources and time are fixed. Change is seen as something positive, as it
provides for opportunities to improve and maximize the costumer's value.
In Scrum the Sprint progress is measured each day, based on what is actually done and what
should have been done. The progress and performance of the total project is measured at the end of
each Sprint, during the Sprint Review meeting (Sutherland & Schwaber, 2013). Performance is
monitored and controlled by means of the Daily Scrum Meetings. During the Daily Scrum Meetings
the team members are presumed to address problems or impediments they have encountered and to
report on the progress of their performed tasks (Koskela & Howell, 2002). This also makes that
problems can be detected as soon as possible, instead of at the end of the process and since problems
or impediments are announced during the Daily Scrum Meetings, at which all team members are
present, all team members are involved in the problem solving and decision making processes.
In Scrum, team members decide what will be done the coming day and also decide themselves
what they individually will do. In order to keep the project manageable the team members must work
together on a daily basis and communication must happen face-to-face. The Agile approach also
emphasizes the need for team reflection in order to assess what could and should be improved.
The following figure presents a conceptual model of the comparison of the two types of project
management methodologies. Where in scrum there are periodic deliverables, the traditional waterfall
method there is no feedback until the final delivery.

Figure 2-12 | Comparison between scrum Vs. traditional value in time by de

Boer et al. (2015)

30
S Solis Vuurmans
https://t.me/PrMaB
2.5 DISCUSSION OF PROJECT MANAGEMENT
METHODOLOGIES
As mentioned in the paragraphs before, we can distinguish two main classes of approaches to
project management: the more rigid traditional waterfall-based ones, including the Critical Path
Method (CPM), and the relatively new and more flexible agile-based one, like Scrum. Some basic
differences between Waterfall and Scrum process are:
− Waterfall uses stages when Scrum uses iterations
− Waterfall is controlled by a Project Manager when Scrum is facilitated by a Scrum Master
− In Waterfall we cannot go back at previous step when we do this in Scrum
− Developer does not interact with product owner during every stage when in Scrum developer
always connects with the product owner.
In the area of traditional waterfall project management methodologies two stand out: PRINCE2
and PMBOK. Because of their similarities the research won’t focus on detailing them, in contrary, we
will focus on a general view of ‘traditional waterfall’ where the planning, hierarchy and distinctive
phases play a major role instead of going in detail into the processes of each methodology. A general
overview of those methodologies is given in Appendix A, page 123.
In literature lots of discussions are found about which approach is considered to be the most
suitable and successful one. The most frequently cited advantages and disadvantages of each method
are the following:
Reviewing the table, we may conclude that the Scrum method better cope with dynamics and
changes in the project context than the Waterfall method; but that a competent facilitating role of the
Scrum Master and the experience and motivation of the team members are considered crucial for
successful project completion.

31
S Solis Vuurmans
https://t.me/PrMaB
 Table 2-1 | Advantages and disadvantages of methodologies
Advantages
Waterfall Goals and objectives are clearly defined
which allows easy forwards planning and
implementation.
Each phase of development proceeds in strict
order, without any overlapping or iterative
steps.
Tangible output at the end of each stage,
which provides a baseline to move forward
on.
Ability to visually see and communicate a
target delivery / end date based on scope
agreed.
Scrum Insists on frequent updating of the progress in
work through regular meetings, which
contributes to a clear visibility of the project
development.
It is a way to improve communication
between teams and provide for an open
approach to tackling a project.
Due to short sprints and constant feedback, it
becomes easier to cope with the changes.
Issues are identified well in advance through
the daily meetings and hence can be resolved
in speedily.
Daily meetings make it possible to measure
individual productivity. This leads to the
improvement in the productivity of each of
the team members.
Is customer oriented and takes into account
it´s needs.
S Solis Vuurmans
https://t.me/PrMaB
Disadvantages
It is rigid method, which does not entertain
any change in requirements; this makes any
subsequent functionality changes required
extremely difficult and expensive to
implement.
In reality, projects rarely follow the sequential
flow and iterations in this model are handled
indirectly. Changes in scope can cause
confusion as the project proceeds and
seriously impact time/ cost/ quality.
If tasks aren't done properly in each phase and
essentially identified at a later stage, the entire
project can be severely impacted.
If the project has internal or external
dependencies, delays can occur as the "plan"
has already been written.
It can be difficult for the Scrum master to
plan, structure and organize a project that
lacks a clear definition.
Inexperienced team members or lack of
adequate direction can mean that projects,
which utilise Scrum run a far higher risk of
not completing or simply failing.
Frequent changes, frequent product delivery
and uncertainty regarding the precise nature
of the finished product makes it sometimes
difficult for everyone involved keeping up
their motivation.
A successful project depends on the maturity
and dedication of all participants, and their
ability to maintain consistently high levels of
communication through each backlog and
review.
It is good for small, fast moving projects as it
works well only with small teams.
32
2.6 Q METHODOLOGY
In order to collect information, within the context of the present thesis research, of people´s
perception about the advantages and disadvantages of scrum/APM methodology and about the
success factors they consider most crucial, a special methodology has been applied, called the Q
methodology.
The Q methodology provides the foundation for a systematic study of subjectivity, a person’s
viewpoint, opinion, beliefs, attitude, and the like (Brown, 1993). Typically, in a Q methodological
study people are presented with a sample of statements about some topic, called the Q-set.
Respondents, called the P-set, are asked to rank-order the statements from their individual point of
view, according to some preference, judgement or feeling about them, mostly using a quasi-normal
distribution. By Q sorting people give their subjective meaning to the statements, and by doing so
reveal their subjective viewpoint (Smith, 2001) or personal profile (Brouwer, 1999).
The results of a Q methodological study can be used to describe a population of viewpoints and
not, like in R, a population of people (Risdon, Eccleston, Crombez, & McCracken, 2003)). In this
way, Q can be very helpful in exploring tastes, preferences, sentiments, motives and goals, the part of
personality that is of great influence on behaviour but that often remains largely unexplored. Another
considerable difference between Q and R is that ‘Q does not need large numbers of subjects as does
R, for it can reveal a characteristic independently of the distribution of that characteristic relative to
other characteristics’ (Smith, 2001).
Because Q is a small sample investigation of human subjectivity based on sorting of items of
unknown reliability, results from Q methodological studies have often been criticized for their
reliability and hence the possibility for generalization (D. B. Thomas & Baas, 1992)

2.6.1 Step by step of the Q methodology

Performing a Q methodological study involves the following steps: (1) definition of the
concourse; (2) development of the Q sample; (3) selection of the P set; (4) Q sorting; and (5) analysis
and interpretation. A comprehensive discussion of each step will be presented in the following
chapters.

2.6.1.1 Definition of the concourse

In the Q methodology, concourse is a technical concept for the collection of all the possible
statements the respondents can make about the subject at hand. The concourse is thus supposed to
contain all the relevant aspects of all the discourses. It is up to the researcher to draw a representative
sample from the concourse at hand. The concourse may consist of self-referent statements (i.e.,
opinions, not facts), objects, pictures, et cetera. A verbal concourse, to which we will restrict
ourselves here, may be obtained in a number of ways: interviewing people; participant observation;
popular literature, like media reports, newspapers, magazines, novels; and scientific literature, like
papers, essays, and books.

2.6.1.2 Development of the Q set

On the basis of the concourse, a set of statements is developed that will be presented to the
participants. This is called the Q set (or Q sample) and often consists of 40 to 50 statements, but less
or more statements are certainly also possible (van Eeten, 1999). According to Brown (1980), the
selection of statements from the concourse for inclusion in the Q set is of crucial importance, but
remains ‘more an art than a science’: the researcher uses a structure for selection of a representative
miniature of the concourse. A Q statement can be interpreted in different ways by different sorters
(Brown, 1970).

33
S Solis Vuurmans
https://t.me/PrMaB
 A good Q statement is salient, in other words it is meaningful to the people doing the Q sorts. It
must be understandable, but it need not be narrow. It is acceptable and even desirable for Q
statements to have “excess meaning,” which means that they can be interpreted in slightly different
ways by different people. Above all, Q statements must be something that people are likely to have
an opinion about (Webler, Danielson, & Tuler, 2009).

2.6.1.3 Selection of the P set

The P set is the group of participants. This P set usually is smaller than the Q set (Brouwer, 1999).
The aim is to have four or five persons defining each anticipated viewpoint, which are often two to
four, and rarely more than six. The P set is not random. It is a structured sample of respondents who
are theoretically relevant to the problem under consideration; for instance, persons who are expected
to have a clear and distinct viewpoint regarding the problem and, in that quality, may define a factor
(Brown, 1980). Eventually, the number of persons associated with a factor is of less importance than
who they are; in the total population the prevalence may be much higher (Brown, 1978).
Determining the right number of Q participants means finding the right balance between two
competing rules of thumb as Webler, Danielson and Tuler (2009) established in their research. On the
one hand, it is good to have a certain amount of redundancy among the Q participants. Normally a Q
study will result in 2-5 social perspectives. For each perspective, it is sufficient to have four to six
individuals who “define” a perspective, although plenty of studies involve many more people.
According to this criterion, the number of Q participants should be between eight (2 factors x 4 people
defining each factor) and 30 (5 factors x 6 people defining each factor). However, it is impossible to
know who will determine which factor, therefore, in practice, it is necessary to include more people
than this.
On the other hand, it is important to have fewer Q participants than Q statements. Normally a
ratio of 3:1 is used. For a study with 45 Q statements, the ideal number of Q participants would be
15. The highest ratio that should be used is 2. Many Q studies involve between 12 and 20 Q
participants (Webler et al., 2009). Also with talks with Koops (2015) and Suprapto (2015), both with
experience with Q methodology established that the number of participants should be between 20 and
40 people.
2.5.1.4 Q sorting
The general procedure of Q sorting is that the Q set with the statements is given to the
participants, who are asked to rank each statement according to a score sheet of a continuum ranging
with “most agree” (or likes, finds important, etc.) on the one and “most disagree” (not important,
don´t like) on the other extreme, with those statements in between about which the respondent is
neutral, doubtful or undecided. It is recommended to have the Q sort followed by an interview.

2.6.1.4 Analysis and results

The analysis of the Q sorts is a purely technical, objective procedure – and is therefore sometimes
referred to as the scientific base of Q. The analysis could be done with a statistical program like SPSS
but the most common software to use is PQMethod (Van Exel & de Graaf, 2005).
First, the correlation matrix of all Q sorts is calculated. This represents the level of (dis)agreement
between the individual sorts, that is, the degree of (dis)similarity in points of view between the
individual Q sorters. Next, this correlation matrix is subject to factor analysis, with the objective to
identify the number of natural groupings of Q sorts by virtue of being similar or dissimilar to one
another, that is, to examine how many basically different Q sorts are in evidence(Brown, 1980, 1993).
People with similar views on the topic will share the same factor. A factor loading is determined for
each Q sort, expressing the extent to which each Q sort is associated with each factor. The number of
factors in the final set depends on the variability in the elicited Q sorts. It is however recommended to
take along more than the number of factors that is anticipated in the next step of the analysis – factor
rotation – to preserve as much of the variance as possible.

34
S Solis Vuurmans
https://t.me/PrMaB
 When a respondent’s factor loading exceeds a certain limit (usually: p < 0.01), this called a
defining variate (or variable). The difference score is the magnitude of difference between a
statement’s score on any two factors that is required for it to be statistically significant. When a
statement’s score on two factors exceeds this difference score, it is called a distinguishing (or
distinctive) statement. A statement that is not distinguishing between any of the identified factors is
called a consensus statement (Van Exel & de Graaf, 2005).
A more detailed explanation of the statistical analysis methodology and its formulas are further
explained in Appendix B, page 123.

35
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER III
“You learn something every day if you pay attention” (Ray LeBlond)

In this chapter the methodology of the research will be described step by step. First the objective
of the exploratory interviews will be explained (3.1). Then the work done in order to make a
proposal of the success framework based on CSF of literature (from construction industry as well
as ICT) and the interviews realized (3.2). The definition of our Q-set of 38 CSF with their
explanation (3.3). And finalizing with the list of people, or P-set, that the official questionnaire
was collected (3.4).

3 THE RESEARCH
In this paragraph the research methodology will be discussed. The results will provide an answer
to the following research sub question.

SQ2: What is the best framework to assess success of projects handled in APM?

Answer SQ2 summary: The process of designing a success framework

Based on an extended literature review, a proposal for scrum in infrastructure went through
shortlist of 38 different Critical Success different phases, starting from a literature review in
Factors (CSF) grouped into 8 clusters is
which the most frequently used CSF and/or those
proposed. Thereafter, these 38 identified CSF
have been verified through questionnaires and
considered to be most appropriate have been identified
interviews with 31 persons from different in order to get a final list of 38 critical success factors,
roles and industry experiences using Q- where after these factors have been validated and
Methodology as research tool. described with the use of exploratory interviews with
experts involved in projects handled in scrum
methodology.
Having a proposed number of CSF (named Q-set), we then proceeded to identify the group of
respondents needed in order to rank their importance (named P-set) by means of a questionnaire and
follow-up questions especially designed for this purpose (Q methodology). According to the proposed
research methodology, several perspectives of importance of said CSF have been obtained which will
be further analysed and discussed in Chapter 4.

3.1 INFORMATION GATHERING PROCEDURE WITH KEY

INFORMANTS
All the main key informants for this research have been Grontmij employees. Exploratory
interviews with some of them have been important during the first stage of the research in order to

36
S Solis Vuurmans
https://t.me/PrMaB
obtain an initial viewpoint of the problem. Next, and related to the literature review focussed on the
identification of CSF, a number of exploratory interviews were scheduled in order to obtain a better
look at the situation of the projects handled with scrum. For this purpose a number of 10 interviews
were executed with engineers with several experiences in scrum, and several different roles within it,
like technical advisors, contract managers, project managers, scrum masters and product owners.
These interviews also served to identify the type of respondent needed in the future stage of the
questionnaire.
In fact, a list of the 67 potential interviewees was elaborated (see Appendix C, page 129), all of
them with different backgrounds, roles, experiences and knowledge of APM. We also wanted to
include engineers without any scrum experience in order to further validate the proposed success
framework also in traditional projects.
Finally, out of this complete list of potential interviewees, initially 40 persons were selected as a
proper sample group, from which in this research 35 of them participated in filling up the
questionnaire.
The protocol used for the interviews is shown in Appendix D, page 131.

3.2 OVERVIEW OF CRITICAL SUCCESS FACTORS

In order to determine our framework of success specialized on APM projects a list of 16 different
articles were reviewed (see also Chapter 2.2.1), that included articles focused on the construction
sector as well as the ICT industry. The overview of each CSF mentioned in each literature reference
can be reviewed in Appendix E, page 129. The most outstanding literature used for this research is
summarized in the following table.
Table 3-1 | Literature used for the definition of Q set

Industry Authors Title

Infrastructure Pinto & Slevin (1986) The project implementation profile: new tool for
project managers.

De Wit (1988) Measurement of project success

Pinto & Covin (1989) Critical factors in project implementation: a

comparison of construction and R&D projects

Munns &Bjeirmi (1996) The role of project management in achieving project

success

Belassi & Tukel (1996) A new framework for determining critical

success/failure factors in projects

Cooke-Davies (2001) The “real” success factors on projects

Toor and Ogunlana (2006) Construction professionals' perception of critical

success factors for large‐scale construction projects

Turner (2007) The influence of project managers on project success

criteria and project success by type of project

Lam et al. (2008) Identifying and prioritizing critical success factors for
competition strategy

37
S Solis Vuurmans
https://t.me/PrMaB
 Van Loenhout (2013) Public project manager's perspective on project
success: a research into success determination of
construction projects by project managers of the
public party

Coman (2014) Public project management in western Europe:

perspectives on project success

Wagner (2014) Is it project success a coincidence or can it be

enforced? a Comparative study on the critical success
factors of the Stadsbrug Nijmegen project and similar
civil engineering projects in The Netherland

ICT Chow & Cao (2007) A survey study of critical success factors in agile
software projects

Misra et al. (2009) Identifying some important success factors in

adopting agile software development practices

Stankovic (2013) A survey study of critical success factors in agile

software projects in former Yugoslavia IT companies

Bermejo et al. (2014) Agile Principles and Achievement of Success in

Software Development: A Quantitative Study in
Brazilian Organizations

3.2.1 The infrastructure CSF

Pinto & Slevin (1986) have a list of ten different success factors which include: mission
definition, competent project manager, top management support, competent team members, sufficient
resource allocation, communication, control mechanisms, feedback capabilities and responsiveness to
the clients. They focus on helping the manager to assess ‘softer’ side of project management and
during the process to help to determine the status of the project in relation to these human elements.
They call this the Project Implementation Profile (PIP) and they also present the rankings of their
proposed factors having client consultation and acceptance the highest score.
De Wit (1988) presents a division of macro and micro factors, each of them comprised of four
factors. Macro factors, like ‘Realistic and thorough definition of a project’ and ‘Comprehension of the
project environment’, lie mostly in the domain of the client. Micro factors, like ‘Selection of key
personnel’ and ‘Efficient and dynamic management controls’, are most of the time influenced by
contractors. The author has a broader perspective on what the project’s success should be measured,
since is one of the first to include a project life cycle analysis. Those factors give an interesting feed to
this research since they are also established from a management perspective.
Pinto & Covin (1989) is one of the firsts more extensive articles done based on 408 responses.
They identify 14 different factors that include some that where establish in previous articles, but new
factors that stand out are: the characteristics of project leader, politics and urgency. They focused in
construction projects and research and development projects (R&D). An interesting outcome of this
research is that they saw similarities of importance of factors between this two industries, but also
major differences.
Munns and Bjeirmi (1996) make a distinction between project success factors and project
management success factors but look also at factors, which can cause failure. These failure factors
like, ‘Wrong person as project manager’ and ‘Unsupportive top management’ give the impression to
be reversed success factors. This research is particularly interesting because it was focused on civil
projects. The success factors of other authors collected in this publication were used in this thesis. The
success factors of de Wit (1988) are also mentioned in the publication of Munns and Bjeirmi (1996).

38
S Solis Vuurmans
https://t.me/PrMaB
 Belassi & Tukel (1996) describe a survey research with the involvement of 91 project managers in
which they proposed on clustering the factors in order to see their interdependencies. It consists in
nine major groups: related to project manager, related to team members, related to project, related to
organization, related to the job performance, related to resources, and related to external environment.
This type of clustering will be also used in this research in order to facilitate the analysis of the
factors, even though their interdependencies wont be further analysed.
Cooke-Davies (2001) performed an empirical research among 70 large multinational and national
organizations to find the ‘real’ success factors on projects. After analyzing the data he remains with
twelve factors including, ‘Effective means of learning from experience on projects’ and ‘Allowing
changes to scope only through a mature scope change control process’. All the twelve factors
mentioned in this publication were added to the literature study of this thesis.
Turner (2007) is based on 959 responses on success factors and criteria on different industries,
project complexity and characteristics of the project manager. In this research ten factors of this
research were used. Even though their links with characteristics of the project, type of contract and
project manager were omitted in this research.
Toor and Ogunlana (2006) have 39 different of success factors named in their research. The study
did not consider any specific procurement methods under which project was being developed. The
goal is to produce a Performance Enhancement Strategy (PES) based on the CSF identified for
different types of large-scale construction projects.
Lam et al. (2008) based on a literature review and expert interviews following the analytic
hierarchy process, they identify and prioritize seven critical success factors and 17 critical success
sub factors comprising three success factor categories: management commitment, relationship
development, and communication management. It was the first one to name ‘safety’ as a factor for
success.
Coman (2014) focuses more on success criteria in a western Private Public Partnerships (PPPs).
Throughout her research she does uses the same 19 CSF of Van Loenhout (2013). The focus is more
on the public sector and identifies new factors that where not initially mentioned by any of the
previous literature.
Wagner (2014) made an analysis of an specific project, the Stadsbrug Nijmegen, here she
identified 36 different CSF and based her research in obtaining respondents from different major
stakeholder: the client, and the contractor. The significant detail of each factor was broke down in
very detail, for example the differentiation between communication between leader and client as well
as vice versa.
The previous 11 literature references of the construction industry were the most important ones
taken for account in the proposal of the success framework. Since Agile Project Management (APM)
comes from ICT, we believe it is important to review literature specific from this industry in order to
get a better overview of maybe new factors to consider.

3.2.2 The ICT CSF

Chow & Cao (2007) conducted a survey among agile professionals, gathering survey data from
109 Agile projects from 25 countries across the world. Multiple regression techniques were used, both
at the full regression model and at the optimized regression model via the stepwise screening
procedure. They established 12 possible CSF in which the organizational structure was the most
noticeable since a ‘change’ in project methodology faces friction in the organization.
Bermejo et al. (2014) made a quantitative study with professionals from the software industry in
Brazil. Data were collected through structured questionnaires and analysed using technical descriptive
analysis, factor analysis and cluster analysis. Based on the categorization of factors, three software
organizations profiles have been obtained regarding the use of agile principles and the scope of
success in producing software. Six most noticeable factors were the mention of the team size and

39
S Solis Vuurmans
https://t.me/PrMaB
culture of the members since Agile requires a high level of collaboration that might clash with cultural
stigmas.
Misra et al. (2009) conducted a study using an unprecedentedly large-scale survey-based
methodology, consisting of respondents who practice scrum and who had experience practicing plan-
driven software development in the past. The study indicates that nine of the 14 hypothesized factors
have statistically significant relationship with “Success”. The important success factors that were
found are: customer satisfaction, customer collaboration, customer commitment, decision time,
corporate culture, control, personal characteristics, societal culture, and training and learning.
Stankovic (2013) presents the results of empirical study for determining critical factors that
influence the success of agile software projects which we conducted among senior developers and
project managers from IT companies located in the former Yugoslavia countries within south eastern
Europe region. The interesting part is that uses the same CSF as Chow & Cao (2007) but replicates it
in another cultural environment.
During the literature review, a list of approximately 300 success factors have been identified and
put in a matrix (Appendix E, page 133) in order to be able to visualize the reference of each of the 38
CSF that are finally proposed in this research and to corroborate its respective back up by previous
researchers.
The big number of success factors that were identified in the literature has been split into different
groups of factors that have more or less the same meaning. The final result is a list of 38 success
factors (subdivided into ten clusters), that has been reviewed through exploratory interviews with a
number of Grontmij employees and that finally forms the basis for the Q-set.

3.3 DEFINITION OF THE Q SET

By means of a questionnaire the Q set is given to the respondent in the form of a pack of
randomly numbered cards, each card containing one of the statements from the Q set. The respondent
is instructed to rank the statements according to some rule, the condition of instruction, typically the
person’s point of view regarding the issue, and is provided with a score sheet and a suggested
distribution for the Q sorting task (see Annex E: Questionnaire with the reverse pyramid to valuing
the importance of each CSF). The range of the distribution depends on the number of statements and
its kurtosis: according to Brown (1980), nowadays most Q sets contain 40 to 50 statements and
employ a relatively flattened distribution with a range of -5 to +5.
The Q sort is followed by an interview (“follow-up questions”), in which the Q sorter is invited to
explain into more detail her/his point of view, especially focussed on the most salient statements – in
other words, those placed at both extreme ends of the continuum on the score sheet. This information
is helpful for the interpretation of factors later on (Van Exel & de Graaf, 2005).
The following conceptual diagram resumes the 38 Critical Success Factors (CSF) in eight
different clusters.

40
S Solis Vuurmans
https://t.me/PrMaB
 Figure 3-1 | Conceptual map of 38 CSF based on clusters by Belassi & Tukel (1996)

By this we see eight major clusters: related to (a.) Project manager. (b.) Team members, (c.)
Project characteristics, (d.) Organization, (e.) Client, (f.) Resources, (g.) Tools of APM and (h.)
External factors.
The explanation of each of the eight CSF clusters and their related Success Factors will be given
in Chapter 3.3.1. In this sense, for each of the 38 CSF a definition of the related statement is given.
The information gathered by the exploratory interviews has been an important input for reviewing and
defining the statement of each of the identified 38 CSF.
Afterwards, in the proposed success framework has also been identified what we will call ‘type of
element’. This consist in three different groups: (i) Agile element, (ii) traditional element and (iii)
Merged element.
The fist one consists of factors that the scrum methodology handles in a more structured manner
since there is a process already established in order to tackle the specific factor, this separation was
done by assumption of the researcher with the objective to have a more visual representation of an
‘agile perspective’ in the results chapter.
The traditional element is determined in factors that go against agile principles and in order to
adapt to those factors the methodology of scrum can’t handle it correctly.
The third group that consists of merged elements are the ones that both agile and traditional
methodologies fit well in order to improve success factors.
As mentioned before, this separation was made in order to have a better representation of the
impact of scrum in the perspectives obtained in further chapters.
The matrix where the analysis was made in order to determine the final 38 Critical Success
Factors (CSF) and their clusters can be reviewed in Appendix F, page 140. Here each proposed factors
were based on the 16 reviewed articles and linked to a previous factor and/or factors. Some of them
were mentioned in a way by all references and some by just one, but through the exploratory
interviews it was determined which factor was presented as significant.

41
S Solis Vuurmans
https://t.me/PrMaB
3.3.1 Factor group related to project manager
In the next table, we can see that to the first cluster, related to project manager, are linked three
success factors, which are:
1. Soft skills of project manager;
2. Commitment of project manager; and
3. Technical background of project manager.

Table 3-2 | Cluster CSF related to project manager

Type of
CSF Statement
element

1. Soft skills of project The Project Manager has incorporated a leadership style that pays Agile
manager attention to human factors like: team motivation, incentives, personal element
involvement and flexibility.
Reference literature:
Pinto & Slevin (1986), de Wit (1998), Munns & Bjeirmi (1996),
Belassi & Tukel (1996), Turner (2007), Toor and Ogunlana (2006),
Misra et al. (2009), Stankovic (2013), Wagner (2014)
2. Commitment of The project manager guarantee into delivering the best result possible Merged
project manager to the client.
Reference literature:
de Wit (1998), Munns & Bjeirmi (1996), Misra et al. (2009), Wagner
(2014)
3. Technical The project manager has the technical background that is needed to Traditional
background of Project fulfil its role, knowledge about the development of the product. element
Manager
Reference literature:
Pinto & Covin (1989), Munns & Bjeirmi (1996), Stankovic (2013)
The factor of ‘soft skills of project manager’ is mentioned in most of the researched literature (10
out of 16), both in infrastructure and also ICT industries. This particular factor mostly focuses on the
motivation the leadership style gives to the team, how they handle negotiations and the personal skills
of the person in charge. In an agile environment the role of Product Owner (PO) is played by the
traditional project leader. This distinction was not made explicit since a part of the respondents are not
involved in scrum projects. The fact that soft skills is intrinsic a very subjective characteristic, and
depends entirely on the point of view of the respondent. This is why during the interview attention
will be given to their description of this CSF in order to corroborate the ‘perspective’ obtained by the
PQMethod software.
The second factor about ‘Commitment of project manager’ is explicitly mentioned by de Wit
(1998), Munns and Bjeirmi (1996) in the infrastructure sector as well as by Misra et al. (2009) in the
ICT sector. They agree that commitment is related to motivation, and especially the leader, the project
manager, with a high level of commitment can have a big influence on the process and end result of
the project.
The last factor in this cluster, called ‘technical background of the project manager’, is mentioned
in articles by Pinto and Clovin (1989) and Munns and Bjeirmi (1996). This factor may affect the
success but, as they mention, it varies greatly from project to project which is directly related to the
third cluster.

42
S Solis Vuurmans
https://t.me/PrMaB
3.3.2 Factor group related to team members
The second cluster related to team members counts with five success factors, which involves its
level of collaboration and commitment, its technical background, the degree in which they are self-
guided, and its actual size.
With respect to the first three factors – ‘Collaborative team members’, ‘Commitment of the team
members’ and ‘Technical background’, it is considered important to count with skilled and committed
team members with social and professional skills in order to work efficiently, to perform their duties
properly and to produce the best results possible.
Referring to the fourth factor, ‘Self-guided teams’, it is supposed that empowered teams with a
high level of responsibility and confidence in their capacity to implement a project will lead to
successful projects (Sutherland, 2014).
Of course the ‘Size of team’, being the fifth factor, has a big influence on the success of a project.
The team must be big enough to be able to cope with their responsibilities as a whole and to guarantee
the needed professional input, but small enough to enable fluent communication and permanent feed
back.

43
S Solis Vuurmans
https://t.me/PrMaB
 Table 3-3 | Cluster CSF related to team members

Type of
CSF Statement
element

4. Collaborative The team members have the skills to work together efficiently, Agile
team members communicating their ideas and problems. element
Reference literature:
Pinto & Slevin (1986), de Wit (1998), Pinto & Covin (1989), Munns &
Bjeirmi (1996), Belassi & Tukel (1996), Turner (2007), Toor and
Ogunlana (2006), Chow & Cao (2007), Misra et al. (2009), Stankovic
(2013), Wagner (2014)
5. Commitment of The team member's commitment in delivering the best result possible to Merged
the team members the client. element
Reference literature:
de Wit (1998), Munns & Bjeirmi (1996), Chow & Cao (2007), Misra et
al. (2009), Stankovic (2013), Wagner (2014)
6. Technical The team members have the technical background that is needed to Traditional
background of team fulfill its role. element
members
Reference literature:
Toor and Ogunlana (2006), Stankovic (2013)

7. Self-guided teams The team members have more responsibility, control and freedom to Agile
guide the project. They feel happy and empowered by it. element
Reference literature:
Toor and Ogunlana (2006), Misra et al. (2009), Stankovic (2013)

8. Size of team The team is not too small to become overworked and not too big to lack Agile
interaction. element
Reference literature:
BERMEJO et al. (2014), Misra et al. (2009), Stankovic (2013)

3.3.3 Factor group related to characteristics of the project

The third group related to the project counts with the highest number of success factors. The first
three factors are considered to be important since all projects normally count with a scope, budget and
schedule. What we want to emphasize regarding to these factors is the level of flexibility that exists
related to these factors in order to maximize the end value of the final product and to the introduction
of periodic reviews and system of feed backs during the whole project cycle, which involves
implicitly a level a flexibility during the whole period of project implementation. The fourth factor
about the definition of the end value is associated directly to what the client considers being important
as final product of the project.
The fifth (adequate communication) and sixth (adequate control) factor are process-oriented
factors, since communication channels and control mechanisms during the whole execution process of
the project are important elements in order to check its periodical advancements and to be able to
apply in time the adjustments that are considered important in order to ensure high value final
product.

44
S Solis Vuurmans
https://t.me/PrMaB
 The seventh and eight factor about safety and risk management are considered important factors
since infrastructure projects, because of its special characteristics, normally involve high accidental
risks and count with many contingencies.
Normally a well conduction and administration of the documentation of the procedures (ninth
factor) helps to register and visualize the steps and decisions taken during the whole process and
allows to register important lessons learned to be taken into account in future projects.
The former factor is related to the level of knowledge interchange capacity, monitoring and feed
back capacity and adequate trouble-shooting capacity, considering them being factors which facilitate
early detection of obstacles so that they can be handled immediately and in time.
Finally the last factor that belongs to this cluster, is a factor related to the fact that has to do with
ability to cope with urgent and unexpected problems that arise during the project implementation.
Table 3-4 | Cluster CSF related to characteristics of the project

Type of
CSF Statement
element

9. Flexibility on the The flexibility of the scope throughout the process helps including Agile
definition of scope the ideas of the team, especially, which increases the end value of the element
product.
Reference literature:
Pinto & Slevin (1986), de Wit (1998), Pinto & Covin (1989), Munns
& Bjeirmi (1996), Belassi & Tukel (1996), Turner (2007), Toor and
Ogunlana (2006), Lam et al. (2008), Wagner (2014)

10. Flexibility on the The flexibility of the budget in the beginning of the project helps to Agile
definition of budget shape the product to maximize the value. element
Reference literature:
Munns & Bjeirmi (1996), Belassi & Tukel (1996), Lam et al. (2008),
Coman (2014), Loenhout (2014), Wagner (2014)

11. Flexibility on the The flexible the schedule helps to have freedom to deliver periodic Agile
definition of schedule reviews and feedback. element
Reference literature:
de Wit (1998), Pinto & Covin (1989), Toor and Ogunlana (2006),
Lam et al. (2008), , Chow & Cao (2007), Misra et al. (2009),
Stankovic (2013), Coman (2014), Loenhout (2014)

12. Definition of value The flexibility of goals, budget and schedule serves to maximize the Agile
value of the project, being value the main objective of the client. element
Reference literature:
Lam et al. (2008), Coman (2014), Loenhout (2014)

13. Adequate The project has continuous and appropriate communication channels Agile
communication within the team and other parties. element
Reference literature:
Pinto & Slevin (1986), Pinto & Covin (1989), Turner (2007), Toor
and Ogunlana (2006), Misra et al. (2009), Stankovic (2013), Wagner
(2014)

45
S Solis Vuurmans
https://t.me/PrMaB
14. Adequate control The proper control mechanisms during the process. For example Merged
using milestones during the project to check advancement.
Reference literature:
Pinto & Slevin (1986), de Wit (1998), Toor and Ogunlana (2006),
Misra et al. (2009), Wagner (2014)

15. Safety Having a safety program to reduce human accidents. Merged

Reference literature:
Lam et al. (2008), Coman (2014), Loenhout (2014)

16. Risk management Actively identifying and managing (mitigating) risks with for Merged
example the help of a risk management plan.
Reference literature:
Cooke- Davies (2001), Stankovic (2013), Wagner (2014)

17. Documentation of Proper documentation of all the processes. Documentation of lessons Traditional
procedures learned. element
Reference literature:
de Wit (1998), Cooke- Davies (2001), Stankovic (2013), Wagner
(2014)

18. Interchange of The good integration/feedback of knowledge between team members, Agile
knowledge as well as other persons of the supply chain. element
Reference literature:
Cooke- Davies (2001), Misra et al. (2009), Wagner (2014)

19. Adequate The continuous feedback capabilities of the system, early detection of Agile
monitoring and obstacles. element
feedback
Reference literature:
Pinto & Slevin (1986), Pinto & Covin (1989), Turner (2007), Toor
and Ogunlana (2006)

20. Adequate trouble- There is efficient conflict management when problems arise. Soon Agile
shooting detected and soon handled. element
Reference literature:
Pinto & Covin (1989), Turner (2007), Toor and Ogunlana (2006),
Lam et al. (2008)

21. Urgency The problem of having to work of urgent task instead of the ones Merged
planned (putting out fires).
Reference literature:
Pinto & Covin (1989),

3.3.4 Factor group related to the organization

The fourth cluster, related to the organization, includes only two success factors, which are: top
management support and organizational structure. Nevertheless, these factors are important in the
sense that the responsible project team must count with the support of the Company about the
methodology to be applied during the project implementation, with the Company´s human resources

46
S Solis Vuurmans
https://t.me/PrMaB
selection politics and decision about office space use and must fit with the, by the Company
established, management techniques.
Table 3-5 | Cluster CSF related to the organization

CSF Statement Type of

element

22. Top management There is support of the Company into the project about the management Merged
support methodologies, use of office space and human resources.
Reference literature:
Pinto & Slevin (1986), Pinto & Covin (1989), Toor and Ogunlana
(2006), Chow & Cao (2007), Stankovic (2013), Wagner (2014)

23. Organizational The organizational structure fits into the project complexity, and project Merged
structure management techniques.
Reference literature:
Pinto & Covin (1989), Belassi & Tukel (1996), Cooke- Davies (2001),
Chow & Cao (2007), Stankovic (2013), Wagner (2014)

3.3.5 Factor group related to the client

The fifth factor group is related to the client and is considered an important cluster since it is
finally the client who considers the project he is paying for whether it is finally being a success or not.
This involves the right and importance of its participation and involvement during the project
implementation and, finally, its satisfaction about the end result.
Table 3-6 | Cluster CSF related to the client

CSF Statement Type of

element

24. Client There is continuous client participation during the project. There is a Core agile
participation representative of the client in the work group.
Reference literature:
Pinto & Slevin (1986),Pinto & Covin (1989), Belassi & Tukel (1996), Toor and
Ogunlana (2006), Lam et al. (2008), (2007), BERMEJO et al. (2014), Misra et
al. (2009), Stankovic (2013), Wagner (2014)

25. Client The clients are satisfied by the end product and there is trust and cooperation Merged
acceptance between both parties.
Reference literature:
Pinto & Covin (1989), Munns & Bjeirmi (1996), Belassi & Tukel (1996),
Turner (2007), Toor and Ogunlana (2006), Misra et al. (2009)

26. Client The level of investment (time, presence, input, feedback) of the client during Core agile
commitment the whole process.
Reference literature:
Pinto & Covin (1989), Toor and Ogunlana (2006), Misra et al. (2009),
Stankovic (2013)

47
S Solis Vuurmans
https://t.me/PrMaB
3.3.6 Factor group related to the resources
The group related to resources refers to the efficiency of human resource allocation, resource
satisfaction and resource alignment. This means that the resources have been efficiently allocated with
a team sufficiently capable and with the appropriate experience to manage the project.
Apart from physical resources that a company needs to fulfill its role, it was also important to
make a division into team characteristics as: capacity, experience and knowledge.
Table 3-7 | Cluster CSF related to the resources

CSF Statement Type of

element

27. Efficient resource The resources are efficiently allocated. Having enough team Merged
allocation members in order to tackle the project.
Reference literature:
Belassi & Tukel (1996), Toor and Ogunlana (2006), Stankovic
(2013), Wagner (2014)

28. Efficient resource The team members have enough experience to present the best Merged
satisfaction result possible.
Reference literature:
Stankovic (2013)

29. Efficient resource The team members have the proper knowledge to be able to work Merged
alignment on the tasks presented.
Reference literature:
Stankovic (2013)

3.3.7 Factor group related to the project management techniques

The penultimate cluster refers to appropriate project management techniques and counts with five
success factors, with the first three of them being core agile factors:
1. Daily stand-ups;
2. Product backlog;
3. Retrospectives;
4. Division of roles; and
5. Required software.

The daily stands up (DSU), product backlogs and retrospectives are pure core agile factors, which
all together facilitate permanent discussion of the project advancements, the visualization and
prioritization of the intermediate tasks, and a continuous learning process from previous experiences.
A fourth success factor indicates the importance to count with a clear division of the roles of the
team members, which contributes to a better understanding of the respective responsibilities of each
of them in each phase of the project execution.
Finally, being a merged element, it is considered important to count with appropriate software to
give follow-up to the intermediate products y to register clearly the final results.

48
S Solis Vuurmans
https://t.me/PrMaB
 Table 3-8 | Cluster CSF related to the project management techniques

CSF Statement Type of

element

30. Daily stand- Having regularly meetings with team members to quickly discuss Core agile
ups advancement, work pending and problems faced.
Reference literature:
Toor and Ogunlana (2006), Stankovic (2013)

31. Product There is a clear visualization and prioritization of tasks pending, a general Core agile
backlog overview is given as well as information of what the team is working on.
Reference literature:
De Wit (1998), Toor and Ogunlana (2006), Chow & Cao (2007)

32. There is an established process to learn from previous experiences Core agile
Retrospectives
Reference literature:
Toor and Ogunlana (2006)

33. Division of There is a clear division of responsibilities. You know who is responsible of Merged
roles doing what at any point of the project.
Reference literature:
Toor and Ogunlana (2006)

34. Required There is always availability of the needed software. Merged

software
Reference literature:
Cooke- Davies (2001), Toor and Ogunlana (2006), Chow & Cao (2007)

3.3.8 Factor group related to external environment

The final cluster group related to external environment, includes four critical external factors,
which has to do with the competence of the bidding price in order to win the contract (Competition),
the economical situation at the moment of bidding and possible price fluctuations during project
implementation, and third parties that might influence in the process (for example the political
situation). The fourth, and not less important factor is considered to be the stakeholder satisfaction
through their involvement from the beginning till the end of the project.

49
S Solis Vuurmans
https://t.me/PrMaB
 Table 3-9 | Cluster CSF related to external environment

CSF Statement Type of

element

35. Competition The influence of the bidding price in order to obtain the contract. The Merged
quality of the planning in the tendering phase.
Reference literature:
Munns & Bjeirmi (1996), Belassi & Tukel (1996), Stankovic (2013)

36. Economical The influence of outside economic factors. For example the state of the Merged
infrastructure market, the price of materials, housing or real state.
Reference literature:
Belassi & Tukel (1996)

37. Third parties The influence of other parties, for example political pressure during the Merged
process.
Reference literature:
Pinto & Covin (1989), Munns & Bjeirmi (1996), Belassi & Tukel (1996),
BERMEJO et al. (2014), Coman (2014), van Loenhout (2013)

38. Stakeholder The good relation with surrounding stakeholders. There is inclusion of Merged
satisfaction their needs in an early stage and informing them in later stages.
Reference literature:
Toor and Ogunlana (2006), Lam et al. (2008), Chow & Cao (2007),
Coman (2014), van Loenhout (2013)

3.4 DEFINITION OF THE P SET

As mentioned before, employees belonging to different departments, roles, projects (in different
phases) of the Grontmij Company were included in the sample. Finally a total of 35 respondents have
participated in the questionnaire but finally the input of 31 respondents has been considered for the
analysis. In the following table we can see that the group of respondents consisted mainly of
developers and project leaders (22% each), followed by advisors (16%), scrum masters (13%) and
environment managers (9%). The rest were tender managers, heads of departments, product owners,
system engineers and technical managers (3% each). An interesting observation is that 28% of the
respondents were female.

50
S Solis Vuurmans
https://t.me/PrMaB
 Table 3-10 | Summary of respondents characteristics

It was decided to gather data from three major groups, all of them within Grontmij, identified
based on their level of experience with Scrum and degree of involvement in infrastructure projects.
The three identified groups are the following: (i) the scrum group experienced in ICT, (ii) the scrum
experienced in infrastructure and (iii) the traditional infrastructure group. The characteristics of each
group will be further detailed in (4.1) The respondents of the Q sorting research.

3.5 THE QUESTIONNAIRE

For the research an electronic and physical questionnaire has been designed whose detailed
description is presented in Appendix G, page 141. The Q-sorting questionnaire consisted of three
parts:
(i) Recollection of profiling information, related to the following nine topics:
1) Information about the interviewee
2) Interpretation of success and its relation with scrum
3) Main obstacles faced
4) Involvement in project processes
5) Kind and frequency of communication
6) Scope of the project
7) Cope with changes
8) Problems frequently faced
9) Knowledge and experience with lean and agile

(ii) Overview of the 38 CSF and marking the level of (dis) agreement with respect of each CSF;
and

51
S Solis Vuurmans
https://t.me/PrMaB
 (iii) Quantification of the importance of each FSC by use of an inverse pyramid diagram, in which
the interviewees were asked to rank the CSF according to its respective degree of importance.

Figure 3-2 |Pictures of gathering of respondents

During and after the questionnaires, follow-up question sessions were held with the respondents in
order to give them the opportunity to explain more into detail their points of view and the statements
expressed in the questionnaire.

Figure 3-3 | Step three of questionnaire: the quantification of importance.

The figure above is the inverted pyramid in which the respondents had to rank the influence of the
38 CSF given according to the question “Which factors are the most influential for success in the

52
S Solis Vuurmans
https://t.me/PrMaB
project?”. The pyramid has 38 spaces in nine columns, which rank from minus 4 to plus four; the
distribution of place in each column (1, 2, 5, 7, 8, 7, 5, 2, 1) was done together with Jalali (2015).

3.6 DISCUSSION
The Q methodology – being the research method that has been chosen in the present study for the
identification of the most appropriate success framework– is a methodology that enjoys increasing
popularity and use among scholars and students in the Netherlands (Van Exel and de Graaf, 2005). Its
main characteristics are: (i) the relative high degree of subjectivity since it is focused on the opinion
and viewpoint of each of the participating respondents and of the researcher, although also
quantitative aspects are taken into account, and (ii) the small size of the samples on which the
research is performed.
As mentioned before, the primary purpose of the Q-method is to reveal the most common
perspectives (typologies or factors) and to identify characteristics of individuals who share these
common viewpoints. The study of subjective opinions or viewpoints is considered important, since
particular attitudes may have an impact on how the project is implemented and on the value of its
final results. For the calculation of the correlation matrix and its subsequent factor analysis the
PQMethod software was applied. For the data collection different methods were used, like: (i)
literature review, (ii) exploratory interviews with key informants, and (iii) individual questionnaires
accompanied by follow-up questions.
This combination of data collection methods was important to achieve a set of interrelated
research objectives. First of all, the distinct theories developed by other authors in their respective
investigations was used as orientation for the present research and has served as important input for
the final identification of the 38 most relevant success factors (CSF) grouped into eight different
clusters related to: project manager, team members, project, organization, client, management
techniques, resources, and environment. Secondly, the opinions expressed by a special group of key
informants – all of them with extensive experience in the infrastructure and/or ICT sector – about the
proposed success factors, have been crucial to corroborate and to confirm each one of the CSF in the
list. Finally, it was considered important to direct the ranking exercise of the success factors to three
different groups, of which two groups with Scrum experience (infrastructure sector and ICT sector)
and one group without Scrum experience (infrastructure sector). The total number of respondents
counted 31 persons evenly distributed among the three different reference groups. So finally the
viewpoints of 31 persons about 38 success factors have been collected – together with information
about the profile of each respondent – through the application of a questionnaire accompanied with
follow-up questions, which in the Q-methodology is considered to be a good proportional relationship
between number of variables (CSF) and sample size.

53
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER IV
“People rarely succeed unless they have fun in what they are doing” (Dale
Carnegie)

In this chapter the final results obtained by use of the PQMethod software will be presented. In the
first part of this chapter an overview of the respondents is given (4.1), followed by a description of
the applied PQMethod software (4.2). Next, the four identified perspectives will be explained
(4.3), including a comparison of their similarities and differences (4.4). An extra analysis with the
respondents with ONLY scrum experience will be performed in order to review the general agile
perspective (4.5). The chapter ends with final discussion about the most outstanding findings of
the present research (4.6).

4 ANALYSIS AND RESULTS

In this paragraph the Q sorting research results will be discussed. The results will provide an
answer to the following research sub question.

SQ3. What are the most influential factors for success?

Answer SQ3 summary: First we needed to establish the participants of the

As result of the research we can distinguish
four outstanding perspectives on importance
of CSF, which are:
• P1: ‘Collaboration with client for
maximizing value’
• P2: ‘Strong leader’
• P3: ‘Team empowerment’
• P4: ‘Capacity to respond to changes”
Agile management has an influence in the
perspectives (P1, P3 and P4) by being directly
related to core agile principles. The P2 shows
the most ‘traditional’ point of view on
success.
questionnaire, the major focus was to obtain people
from three major groups: (i) Engineers from
infrastructure without scrum experience, (ii) Engineers
from infrastructure with scrum experience and (iii)
Engineers from ICT with scrum experience.
By using the data recollected and analysing it with
the PQMethod software we will be able to determine
which factors are the most influential for success for
four identified perspectives. The major outcome of this
chapter is not only the identification of these factors but
also how it can be linked to the project management
processes in order to maximize their potential for
success.

4.1 THE RESPONDENTS OF THE Q SORTING RESEARCH

In the following the characteristics of the respondents of the Q sorting research are shown. As
already mentioned before, the P set consisted of 67 potential respondents. Out of this group of

54
S Solis Vuurmans
https://t.me/PrMaB
potential respondents 34 persons filled out the questionnaire. Unfortunately three of them did not fill
out the questionnaire the way as was asked. Since a total of 31 respondents is a reasonable number7, it
was decided to exclude the three respondents, who did not fill out the questionnaire as asked from the
further research. Thus finally in total 31 respondents contributed to the research.
The main objective of the P set was to gather respondents belonging to three major groups
(Background of respondents) with different levels of knowledge and experience about working in a
scrum environment. They are named ‘Background of respondents’ in the figure presented below. A
quick overview of what they represent is as follows:
1. Infrastructure traditional (Infra Trad): People from the industry, who have never worked in
a project managed with scrum (sample of 10 respondents).
2. Infrastructure with scrum (Infra Scrum): People who have been, or are currently, involved
in an infrastructure project managed with scrum (sample of 11 respondents).
3. ICT with scrum (ICT Scrum): People who are used to work with scrum regularly in the ICT
sector (sample of 10 respondents).

The Departments within Grontmij are quite varied since most of their projects require a level of
multidisciplinary collaboration, so in order to have a valid representation during the analysis this was
taken into consideration.
There are several Roles that the respondents occupy within the organization structure. During the
interviews it was interesting to analyse the impact of the project management techniques throughout
the hierarchy of the project.
The Gender was not taken into account that explicitly but it is still interesting to see its
representation with 26% of the total group of respondents being female.

7
Based on talks with Suprapto, Kopps and Everaars (2015).

55
S Solis Vuurmans
https://t.me/PrMaB
 Figure 4-1 | Characteristics total respondents Q sorting

It was intended to have similar types of people within each group in order to have a comparable
view of each group’s vision. In the following sub-paragraphs a description of each of those groups
will be given.

4.1.1 Group: Infrastructure traditional

Figure 4-2 | Characteristics respondents of group Infra Trad.

This group of ten respondents is meant to represent the ‘traditional way’ to manage an
infrastructure project.
By looking at the departments we can see that ‘transport infrastructure’ had the most people
interviewed. But this should not be decisive since most projects are managed similarly in Grontmij.
In the roles distribution ‘the project leader’ was the most represented role. Even though it is
important to gather information from the different people in the project. The project leader has a better
overview of the whole status of the project, which is why their input is very valuable.

56
S Solis Vuurmans
https://t.me/PrMaB
4.1.2 Group: Infrastructure with experience in scrum

Figure 4-3 | Characteristics respondents of group Infra Scrum

This group of eleven respondents is meant to represent the ‘agile way’ to manage an infrastructure
project.
By looking at the departments we can see a distribution within the company. The level of use of
scrum differs from project to project. This will be further discussed when defining the success
perspectives.
In the roles distribution there is even a ‘head of department’ interviewed. The role of ‘scrum
master’ is introduced. The focus was also to obtain a wide distribution of roles throughout the project.

4.1.3 Group: ICT experienced with scrum

Figure 4-4 | Characteristics respondents of group ICT Scrum

The interesting part of the research was to know why ICT has decided to continuously use scrum
as a way of working. This will help us to identify the factors that helped to improve the process within
their industry and discuss the obstacles that they encountered.
All of the respondents come from the department GIS ICT of Grontmij. They have been using
scrum in several projects, and one that is currently in execution is the project Obsurv8 where 80% of
the respondent’s data was gathered through a workshop.
Most of the roles from this ITC Scrum group are called developers, or members of the scrum
team. But still each major role of scrum was taken for into account.

8
Obsurv.nl is the solution for asset management and the management of public space.

57
S Solis Vuurmans
https://t.me/PrMaB
4.2 PQMETHOD PROCESS
The procedure of analysing the data will be explained in this chapter. The PQMethod software
was facilitated by Peter Scholck in his website (http://schmolck.userweb.mwn.de/). The version used
in PQMethod 2.35.
The program runs in a DOS environment so that the data had to be typed manually after obtaining
it from the respondents. There were several runs, or analysis, done with the data in which the decision
of choosing finally the four determining perspectives was done in company of specialists in the
matter, who were Jalali and Suprapto (2015).
The step-by-step process of obtaining the number of perspectives is presented in the following
figures.
Table 4-1 | Step by step in order to use PQMethod in order to obtain factors

Step one:
First the boundaries of the research needed
to be determined. That includes
introducing the name, number of
statements and distribution of the Q
method pyramid.

Step two:
Inclusion of the statements. There are 38
CSF used and each of them had to be
typed manually.

Step three:
Including each respondent input. Using the
same pyramid distribution as established in
the questionnaire and the final 31
respondents.

58
S Solis Vuurmans
https://t.me/PrMaB
 Step four:
Run the Principal Component Analysis
factor. When the cumulative percentage is
above 50 it already has significance
(Suprapto, 2015). As seen in the figure,
three factors it surpasses the 50%. This is a
key step in the analysis since based on the
PSA we determine the number of
perspectives that will be used in the
research.
The results were discussed with expert in
several occasions 9 and are based on the
PSA and the final CSF allocations. A
number of four clearly divisible
perspectives were determined.

Step five:
This identifies which respondent is linked
to which perspective. This is done in order
to use the discussions during the
questionnaire in order to explain more into
detail each statement.

Step six:
Obtain results. The program gives us an
extensive text file with a clear description
of the number of perspectives chosen.
Their rank of CSF, correlation,
distinguishing CSF, major differences are
also included.
Those results are the ones we will explain
in the next paragraph (4.3).

More detailed information about all the used results given by the PQMethod software is presented
in Appendix H, page 144.

4.3 DEFINING THE PERSPECTIVES

In order to define the amount of points of view or perspectives, a factor analysis was performed.
The way this factor analysis was performed by the software is shown in Appendix B, page 123. And
based on several trial and error data analysis, it was concluded that the gathered sample contained four
distinctive perspectives.

9
The results were discussed with experts in the matter of Q-Methodology as Suprapto, Koops and Jalali in personal meetings (2015)

59
S Solis Vuurmans
https://t.me/PrMaB
 The factor analysis resulted in identifying a total of four main perspectives. Each perspective
represents a point of view on the CSF in order to reach for success by a group of respondents. To each
of the four perspectives is assigned a name. Below these names can be found alongside the amount of
respondents who are associated with this perspective. In the following four sub-paragraphs each of
these perspectives will be discussed.
5. Perspective one: “Collaboration with client to maximize value”
6. Perspective two: “Strong leader”
7. Perspective three: “Team empowerment”
8. Perspective four: “Capacity to respond to change”

Figure 4-5 | Conceptual model of the definition of the perspectives

The figure shown above conceptualizes the research of success. The two major sectors that where
analysed were the ICT and Infrastructure sectors. The latest was further subdivided into two groups:
persons with scrum experience, and persons without. Based on the results of the Q-methodology the
outcome inclines to identify four different perspectives on success.
The perspectives 1, 3 and 4 are a combination of respondents from all the major groups. Only
perspective 2 seems to be mainly composed by persons without any scrum experience. The link
between the respondent groups and the perspectives signifies that with or without scrum, engineers
have an agreement on which factors influence success, and through the follow up questions it was
identified which of the important factors the scrum methodology tackles is a successful manner and
which are needed to be adapted to the infrastructure industry. This will be further discussed in the
following sub-paragraph.

60
S Solis Vuurmans
https://t.me/PrMaB
 In the following table the correlation between each of the four perspectives has been calculated, in
order to determine and to highlight which perspectives are more and which perspectives are less
connected with the others.
Table 4-2 | Correlation between perspectives according to PQMethod software
Collaboration with client to

The results of the calculation of the

Capacity to respond to change

correlation between the four perspectives show
that the perspectives 1, 3 and 4 are more closely
connected between each other than perspective 2
Team empowerment with the rest of them.
maximize value

Strong leader

So the rest shows a higher level of correlation,

which means that their point of view is similar.
The respondents linked to each of those
perspectives will be discussed later on.
1 2 3 4 We consider important to present the
similarities of the perspectives quantitatively;
1 1 0.2829 0.7044 0.5572 their different ranking of factors will be further
2 0.2829 1 0.3535 0.0473 discussed in sub-paragraph 4.4 (Comparing the
perspectives).
3 0.7044 0.3535 1 0.4305

4 0.5572 0.0473 0.4305 1

4.3.1 Perspective one: “Collaboration with client to maximize value”

In the following Figure the characteristics of the respondents contributing to this first perspective
are shown. In total fourteen out of the 31 respondents (corresponding to 45%) attribute to this
perspective, which is the highest number of respondents who share the same perspective. Thus
fourteen respondents share this same point of view.

61
S Solis Vuurmans
https://t.me/PrMaB
 Figure 4-6 | General characteristics respondents perspective one

The first thing that is notable is the equal representation of all three groups of respondents, even
the ones who have never worked in scrum. There are no notable differences in comparison with the
average in the areas of Departments, Roles and Gender.
All the phases of the life cycle of the project apply for this perspective. It is interesting to see that
the tendency to include the client’s perspective is crucial in early stages as pre-design since here is
were there is a higher impact on the overall project. As respondent 17 said: “every decision, or
change, we make at the beginning of the project may save us money later, you know what they say, a
dollar now is worth a hundred later”.
The type of client plays an important role, especially in this perspective, where a division is made
between private and public clients. In general, it is easier to get private clients involved during the
implementation process and facilitate a continuous feedback with them, than with civil servants who
belong to the public sector, where normally the decision-making is more bureaucratic and the
feedback loops are not that immediate.
In the questionnaire it was asked to assess some more profile describing aspects. In the next table
the results of the first profiling questions are shown. As can be noted the averages of the respondents
attributing to perspective one are comparable to the averages of the total set of respondents. Therefore
these characteristics did not influence the interpretation of this perspective.

62
S Solis Vuurmans
https://t.me/PrMaB
 Table 4-3 | Special characteristics of the respondents perspective one.

Perspective one Average of the total

number of
Min Max Average respondents

Age 28 49 38.00 41.10

Year working experience 2 25 10.90 14.45

Years experience in APM 0 5 1.90 1.79

Number of projects with APM 0 50 6.50 4.38

Duration of the project in months 3 60 24.10 29.25

Number of team members during the project 4 30 9.40 11.90

Compared to the average of the respondents the outstanding characteristic is that this group
includes members that never have been involved in a scrum project. Even though the working
experience in average in the group is quite close to the total average.
In this group of 14 respondents, there is a big range in years of working experience (from 2 to 25
years, with an average of almost 11 years), in number of years of experience with APM (form 0 to 5
years, but with an average of hardly 1.90) and in number of projects with APM in which the
respondent has been involved (from 0 up to 50 projects, with an average of 6.50).

4.3.1.1 Assessment statements respondents perspective one

The figure below gives the average assessment of the CSF by this perspective. Interesting to
observe is the concentration of agile elements (in blue) at the upper level of the figure. The most
positive factors are ‘communication’ and ‘client acceptance’ while on the other (negative) side of the
scope we find external factors as ‘safety’ and ‘competition’.

63
S Solis Vuurmans
https://t.me/PrMaB
Figure 4-7 | Assessment perspective one: “Collaboration with client to maximize value”

We will proceed to discuss what the respondents mentioned as the most important characteristics
of a successful project. They have been grouped and generalized for this discussion.

4.3.1.2 What are the key factors for successful projects?

Generally speaking they all concurred that an adequate communication is key for success in
projects. Not only between members of the developing team, but also with the client. The most
common way to help to improve and shorten the communication channels is simply working in the
same room/building. Respondent 30 says: “It is always better to just be able to approach someone and
ask them something, that writing an email or even calling, it not only costs more time, but working
together creates an environment of collaboration”.
The client has a big influence in defining the end result. This is because factors like client
acceptance, client participation and client commitment scored positively in this perspective. As
respondent 16, 11, 17, 26 mention, there is a need of feedback of the client in order to know what you
are doing is in their best interest.
As respondent 4, 7 observe: “the biggest change using scrum is that it gives structure”. There is a
certain order to do things and here is why factors as team work of team members and self-guided
teams come into place.
It is linked to tools of scrum like daily stand ups that also rank high in this perspective. As
respondent 19 says: “the DSU are really helpful when done briefly, it gives an overview what
everybody is doing and you can put dates and responsibilities right away”. The major inconvenience

64
S Solis Vuurmans
https://t.me/PrMaB
with this is the frequency of this type of meetings, since the majority of the time people involved in
the project work in parallel projects, making it difficult to fix a regular time.

4.3.1.3 Which factors have little or no influence to success in projects?

They did not feel external factors as Urgency, economical and Safety key for success. Seems to be
a common knowledge that the responsibilities of a company like Grontmij do not seem harshly
influenced by outside parties, even though the responsibility to minimize risk is taken by the
environmental manager10 in combination with the client.
Flexibility of scope, time and budget was not recognized as important for success in this
perspective. Even in respondents with scrum experience as respondents 19, 26, 30 find it easier to
work with scrum when the tasks stay constant during the whole project. This comes as one of the most
interesting findings of the research since the ‘agile’ methodology is based in order to tackle and adapt
to change.
There is a low importance given to ‘managerial’ factors as technical knowledge of project
manager, organizational structure and top management support. Respondent 11 says: “the whole idea
of scrum is to cut out the middle men, to empower the team for it to make their own decisions since
its there where the technical knowledge resides”. And Respondent 17 says: “When a project is
decided to be done using scrum, it doesn’t matter if you have support from management or not, people
just want to do the best possible… and actually, the Integrated Planning Model (IPM) works just fine
in this methodology”.
In the next table the distinguishing factors of this first perspective compared to the other three
perspectives are shown. The Z-SCR placement will say how HIGH or LOW the CSF ranks to each
other. The distinguishing factors will be discussed more into detail later on.
Table 4-4 | Distinguishing elements perspective one

Z coefficient
Z-SCR
No Statement P1 P2 P3 P4 placement

12 Definition of value 1.18 -0.92 0.05 -0.48 High

7 Self guided teams 0.92 -0.16 0.32 0.07 High

18 Interchange of knowledge 0.49 -0.06 -0.24 -0.85 High

28 Efficient resource satisfaction 0.32 -1.06 -0.34 -0.41 High

14 Adequate control 0.20 1.17 -0.48 1.06 Mid-low

37 Third parties -0.64 -1.24 -1.53 -1.22 High

9 Flexibility on the definition of scope -0.90 -2.67 0.38 0.66 Mid-low

11 Flexibility on the definition of schedule -1.1 -1.71 -0.61 0.5 Mid-low

21 Urgency -1.37 -0.47 -0.9 -0.11 Low

Here below only the higher and lower assessed elements will be discussed, since the ‘in between’
assessed elements are less interesting for drawing conclusions about this particular perspective.

10
Also known as omgevings manager, whose role in the project is to help the Client (ex: RWS, province, municipality, water board) to
deal with different stakeholders in their behalf. And never as a unique representative of Grontmij.

65
S Solis Vuurmans
https://t.me/PrMaB
 Perspective one is considerably more positive about defining value compared to the other
perspectives. Respondent 19 responds: “in the daily meet ups we can see what has been done and
what needs to be done, assigning value to them is key in order to prioritize and deliver the best result
possible”. Also respondent 3 emphasizes the importance of determining value, not only for the team
but also by the client: “We want to satisfy the client by any means necessary, it is important for them
to let us know what they find valuable”. Respondent 31 also mentioned: “if you pay for a six, the
logical thing is to deliver a product that is also a six… the important thing is to work together with the
client in order to define what is most valuable for him and at the end he will find a more satisfying
product”.
Adequate control ranks mid-high based on respondent 1: “with scrum I know exactly what
everybody is doing at the moment, and it gives also early warnings when a problem arises”. This
version of control differs from the one in factor two (“strong leader”), since the latter has more to do
with control in hands of the project manager and delegation of tasks instead of just letting the team
work together and controlling themselves.
Another distinguishing element is third parties. This was explained by respondent 30 as: “political
pressure occurs often in large infrastructure projects, it may change characteristics of your project
along the way, the best thing you can do is to adapt”. This is why respondent 24 said: “usually in the
design phase, where we are involved, there is little to do to prevent those factors to influence the
project, we know this for a fact, so we focus on what we CAN do, so that is why other factors are
more important”.

4.3.2 Perspective two: “Strong leader”

In the following Figure the characteristics of the respondents contributing to this second
perspective are shown. In total four respondents (13%) attribute to this perspective. Thus four
respondents share this same point of view.

66
S Solis Vuurmans
https://t.me/PrMaB
 Figure 4-8 | General characteristics respondents perspective two

Three out of the four respondents belong to the background group infrastructure traditional (Infra
Trad), whose members do not have experience with projects managed with Scrum. The fourth person
who shares the same point of view with regard to the factor “Strong leader” belongs to the Infra
Scrum group. Members of the ITC group with Scrum experience seem not to associate themselves
very much with the “Strong leader” perspective.
Although the group is relatively small, we can see that the kind of departments to which its
members belong to and their roles within the organization is well distributed.
The phases of the life cycle was interesting to review, especially during the follow up questions.
The respondents related to this perspective shared the opinion that it is needed to have a totally clear
list of technical specifications from the beginning, and any change would harm their performance;
even though when they were asked whether during the project something was changed, 100%
answered positive.
The type of client related to this perspective has a similar distribution as with the other
perspectives where we can see that clients from the public sector predominate, since most of the
clients of Grontmij belong to this sector (municipalities, provincial governments, Rijkswaterstaat,
etc.). But generally the relationship with clients of the respondents belonging to this perspective
“Strong leader” differs greatly from the other respondent groups since there seems to exist a less
collaborative environment and interaction with the client.

Table 4-5 | Extra characteristics respondents perspective two.

Perspective two Average of the total

number of
Min Max Average respondents

Age 42 63 51.00 41.10

Year working experience 10 33 20.3 14.45

Years experience in APM 0 1 0.25 1.79

Number of projects with APM 0 2 0.50 4.38

Duration of the project in months 2 84 29.75 29.25

Number of team members during the project 3 60 18.50 11.90

67
S Solis Vuurmans
https://t.me/PrMaB
 Persons belonging to this perspective show the highest average age (51 years) and a high number
of years of working experience (20.3 years). This may be explained by the fact that the older engineer
inclines to maintain a traditional project management methodology.
The lack of knowledge of scrum or scrum expertise is noticeable, and we can observe that the
average in this perspective is much lower than the average of the whole sample of respondents (1.79
years of experience in APM; in an average of 4.38 projects with APM).
The big difference between numbers of team members comes out of the different stages the
responses were given. In the tender stage there was a team of three people while during execution it
expanded up to 60 persons. This high number of people makes collaboration between them quite
complex so a more hierarchical management technique usually fits best.

4.3.2.1 Assessment statements respondents perspective two

The next Figure shows the average assessment of perspective two, which is related to “Strong
leader”. Traditional elements (in red) are dominating considering them being important key factors for
obtaining successful projects. These factors, which are positively valued, are above all related to the
importance of the technical background of the Project manager and of the Team members, as well as
counting with an adequate control during the project implementation process. We might say that this
particular perspective two is the most traditional one amongst the four perspectives identified.

!3# !2.5# !2# !1.5# !1# !0.5# 0# 0.5# 1# 1.5# 2#

3.Technical#background#of#Project#Manager#
6.Technical#background#of#team#members#
1.SoA#skills#of#project#manager#
4.Team#work#of#team#members#
5.Commitment#of#the#team#members#
14.Adequate#control#
19.Adequate#monitoring#and#feedback#
25.Client#acceptance#
8.Size#of#team#
34.Required#soAware#
2.Commitment#of#project#manager#
20.Adequate#trouble!shooLng#
17.DocumentaLon#of#procedures#
32.RetrospecLves#
23.OrganizaLonal#structure#
30.Daily#stand!ups#
33.Division#of#roles#
18.Interchange#of#knowledge#
22.Top#management#support#
7.Self#guided#teams#
31.Product#backlog#
15.Safety#
36.Economical#
29.Efficient#resource#alignment#
13.Adequate#communicaLon#
27.Efficient#resource#allocaLon#
21.Urgency#
16.Risk#management#
26.Client#commitment#
10.Flexibility#on#the#definiLon#of#budget#
35.CompeLLon#
12.DefiniLon#of#value#
28.Efficient#resource#saLsfacLon#
24.Client#parLcipaLon#
Agile&element 37.Third#parLes#
Merged&element 38.Stakeholder#saLsfacLon#
Traditional&element 11.Flexibility#on#the#definiLon#of#schedule#
9.Flexibility#on#the#definiLon#of#scope#

Figure 4-9 | Assessment perspective two: “Strong leader”

We will proceed to discuss what the respondents mentioned as the most important characteristics
of a successful project. They have been grouped and generalized for this discussion.

68
S Solis Vuurmans
https://t.me/PrMaB
4.3.2.2 What are the key factors for successful projects?
In order to ensure successful projects the role of the project manager (PM) is considered to be
very important, who needs to have technical as well as soft skills. At the same time it relays very
much on the technical capacity and the ability of the team members to work in a coordinated manner.
Adequate control and feedback mechanisms play a big role as here everything goes through the PM.
Respondent 20 said: “In our projects we have what it’s called a technical manager, he is supposed to
have the technical capacity to review the work done by the advisors, without it, the project will fail”.
The technical background of both the PM and team members ranks very high in this perspective.
Success relies mostly on the quality of the end product and in order to achieve it, they require
technical skills above other softer factors. As respondent 20 mentions: “Above everything else, what
we sell to the client is engineering knowledge, without it we can not have a good product”. The
characteristics of a technical advisor in this perspective was from someone who likes to work alone on
a task handed by their supervisor for which no interaction with other people is needed. This was
mentioned by people from other perspectives as respondent 12 said: “I have worked with difficult
people, if you wanted to ask them something you had to write an email since actual face to face talk
was not very appreciated. This is what some people call autistic engineers. They are quite intelligent
people, but they are not the greatest in a team”.
The project leader (PL) in this perspective has the most influential factors. He is the end
responsible of the product to both the company and the client. So he does require the skills to guide
the team to the right direction, have the ability to motivate people and have negotiation skills. As one
of the respondent, being himself PM, says: “In my project there is a clear responsible for each task,
but at the end, I am the responsible towards the Client and Grontmij for the success of the project. So
that is why I am the one who distributes the work”.
In short, perspective two (strong leader) relies on success factors very much focused on the
responsibility of the project manager to control and give direction to its team.

4.3.2.3 Which factors have little or no influence to success in projects?

According to the results of the statement assessment, little or none importance is given to
flexibility on the scope and budget definition. The same tendency applies to factors like client
participation and stakeholder satisfaction.
The need for flexibility ranks quite low in this perspective. As respondent 23 says: “When I am
working on the tender of a project I have to know everything with the most detail possible in order to
make the best bid possible; if the offer doesn´t include a clear proposal we won’t get the work”.
During the interviews also the relation with the contractual part of the projects was mentioned, since
those usually are quite detailed and leave little room for manoeuvring. Since the contractual
agreements are fixed, there is not much use to look for flexibility, even though changes normally
occur. As mentioned by respondent 22: “We are bound to fulfil the requirements of the contract… but
of course if the client wants something extra we will provide it, but that change of scope affects
directly the planning and budget”.
Definition of value gets relegated below other more traditional criteria as cost, time and scope.
The visualization of a task or activity as adding value does not influence the success by this
perspective. Respondent 23 mentions: “Value is quite hard to put in numbers in my opinion, I prefer a
clear schedule, budget and scope”
Client participation is also not very important by this perspective, the relation between the experts
and client needs to be transparent and with a clear division of risks. Collaboration and trust are
intrinsically related to the contractual agreements. Respondent 22: “It all depends on how clear he
was in the technical specifications of the contract, if there are too many gaps of information we will
just have to ask them. But it’s not that you need to have a representative of the client working with
you, you can just call them or write them an email”.

69
S Solis Vuurmans
https://t.me/PrMaB
 In summary, perspective two (strong leader) considers irrelevant CSF as value, flexibility and
other external factors.
Next the table of distinguishing factors will be presented. Those are the factors that stand out from
this perspective compared to the other ones. The Z-SCR means how HIGH or LOW the CSF ranks to
each other and this distinguishing factor will be discussed afterwards.
Table 4-6| Distinguishing elements perspective two

Z coefficient Z-SCR
placement
No P1 P2 P3 P4

3 Technical background of Project -0.53 1.69 -0.48 -0.37 High

manager

6 Technical background of team 0.59 1.64 0.98 -0.36 High

members

1 Soft skills of project manager 1.03 1.58 0.8 -0.06 High

8 Size of team -0.76 0.79 -0.47 -0.36 High

23 Organizational structure -0.29 0.28 -1.36 -0.7 High

15 Safety -2.22 -0.22 -2.15 -1.12 High

36 Economical -1.57 -0.25 -1.4 -2.17 High

13 Adequate communication 1.87 -0.40 1.8 1.89 Low

26 Client commitment 0.36 -0.49 0.97 0.43 Low

35 Competition -1.58 -0.75 -1.86 -1.89 High

24 Client participation 1.14 -1.22 -0.01 1.25 Low

38 Stakeholder satisfaction 0.04 -1.30 -0.52 0.18 Low

11 Flexibility on the definition of -1.1 -1.71 -0.61 0.5 Low

schedule

9 Flexibility on the definition of scope -0.9 -2.67 0.38 0.66 Low

The importance of CSFs that are distinguishable high as: technical background of project
manager, technical background of team members, soft skills of project manager, size of team. All are
related to PM and TM and were discussed in the previous paragraph..
The factor safety is distinguishable high, because by this group of respondents safety was
interpreted being important during the implementation of a project., while members of the other
perspective groups looked at the safety factor related to the design phase of the project, when there
actually are no safety risks for the people involved. Respondent 23 said: “I do consider safety
important, since I don’t want anyone injured during the project. We do review it closely when we are
at the construction site, but for example when we are designing it, it doesn’t impact the success…
luckily nobody dies from too much coffee in the office”.

70
S Solis Vuurmans
https://t.me/PrMaB
4.3.3 Perspective three: “Team empowerment”
In the following Figure the characteristics of the respondents contributing to this third perspective
are shown. In total nine respondents (29%) attribute to this perspective. Thus nine respondents share
this same point of view.

Figure 4-10 | General characteristics respondents perspective three

When we look at the background group, we can observe that all of the respondents who contribute
to the third perspective: “Team empowerment” belong to the two reference groups with Scrum
experience, dominated by the Scrum ITC group. This confirms that project management based on
Scrum methodology considers good teamwork as an important key factor for success. Interesting also
is to note that from the four different perspective groups, this one related to “Team empowerment”
shows the highest degree of gender equity with 33% of the respondents being woman.
Interesting fact from this perspective come out of the division of roles. The vision of team
empowerment comes from different hierarchy levels: from advisors up to heads of departments. This

71
S Solis Vuurmans
https://t.me/PrMaB
relates to scrum closely since the methodology’s principles come out to give the team more
responsibility and power, but always it is hard to delegate this from existing project managers.
The highest percentage of respondents is located in the development phase of the project life
cycle. This is directly correlated with the fact that most of the respondents of this perspective group
come from the ICT sector and they are continuously developing the product, so there is no clear end
to the cycle. This is a very agile perspective on this manner.
In this group the private type of client is considerably higher than in the other perspectives. This
facilitates a lot the scrum process since feedback and decision-making is done in an expedite manner.
Table 4-7 | Extra characteristics respondents perspective three.

Perspective three Average of the total

number of
Min Max Average respondents

Age 27 56 39.00 41.10

Year working experience 2 33 13.55 14.45

Years experience in APM 0.5 4 2.44 1.79

Number of projects with APM 1 15 4.33 4.38

Duration of the project in months 1 48 20.00 29.25

Number of team members during the project 2 8 5.33 11.90

The age and experience of the respondents of this group is around the average of the total sample.
But the experience they have with agile projects is superior. Interesting to see that people who have
executed one or fifteen agile projects still have the same point of view of success.
The most interesting fact about this perspective is the number of team members. It is below the
average, which makes it easier to develop a self-fulfilling team and for them to organize themselves.

4.3.3.1 Assessment statements respondents perspective three

The figure below shows the average assessment of the CSF belonging to the third perspective,
which is related to “Team empowerment”. Again we can observe, although not that explicitly as with
the first perspective related to “Collaboration with client”, that the elements that score high are those
that are marked “merged” and “agile”.

72
S Solis Vuurmans
https://t.me/PrMaB
 !2.5% !2% !1.5% !1% !0.5% 0% 0.5% 1% 1.5% 2% 2.5%

5.Commitment%of%the%team%members%
13.Adequate%communica;on%
25.Client%acceptance%
4.Team%work%of%team%members%
31.Product%backlog%
6.Technical%background%of%team%members%
26.Client%commitment%
1.SoF%skills%of%project%manager%
33.Division%of%roles%
17.Documenta;on%of%procedures%
19.Adequate%monitoring%and%feedback%
34.Required%soFware%
9.Flexibility%on%the%defini;on%of%scope%
29.Efficient%resource%alignment%
32.Retrospec;ves%
7.Self%guided%teams%
2.Commitment%of%project%manager%
20.Adequate%trouble!shoo;ng%
12.Defini;on%of%value%
24.Client%par;cipa;on%
10.Flexibility%on%the%defini;on%of%budget%
27.Efficient%resource%alloca;on%
18.Interchange%of%knowledge%
28.Efficient%resource%sa;sfac;on%
30.Daily%stand!ups%
8.Size%of%team%
3.Technical%background%of%Project%Manager%
14.Adequate%control%
38.Stakeholder%sa;sfac;on%
11.Flexibility%on%the%defini;on%of%schedule%
16.Risk%management%
21.Urgency%
22.Top%management%support%
23.Organiza;onal%structure%
Agile&element 36.Economical%
Merged&element 37.Third%par;es%
Traditional&element 35.Compe;;on%
15.Safety%

Figure 4-11 | Assessment perspective three: “Team empowerment”

We will proceed to discuss what the respondents mentioned as the most important characteristics
of a successful project. They have been grouped and generalized for this discussion.

4.3.3.2 What are the key factors for successful projects?

According to the respondents who belong to this perspective group, the team members play a key
role in order to obtain successful projects. A high level of commitment and sense of responsibility,
capacity to work together with adequate communication within a technical competent team, are
considered important factors that have a positive impact on the success of projects. All these factors
finally lead to high client acceptance.
By the interviews it was asked the way the team is organized in order to fulfil this team
empowerment. And they stated as essential the fact of physically working together in the same room.
This is not only related to their commitment, but also shortens channels of communication. This
seems to have a great positive influence in the team since they feel that they work together instead of
just delivering a small part of the project on their own. Respondent 13 said: “In all my projects I
always try to book a project room if it needs more than 10 persons, if not here (in the office) we have
flexible desks, so it is great if a small team needs to work on something, they should just take their
laptops and work together”.
This perspective of the team empowerment relates to the CSF of clear division of roles. Since all
projects are multidisciplinary the amount of interfaces are high. The possibility to know exactly what
is everybody doing and their needs (inputs and outputs) makes the process go smoother than when
this decision making in laid in hands of a sole project manager. A tool from scrum called product

73
S Solis Vuurmans
https://t.me/PrMaB
backlog also scores high, and its because of the same reason, a clear overview of the project as a
whole involves the team in the decision making and also makes them as group responsible for their
tasks as well as the final result of the project. Respondent 14 mentioned: “I do like to feel involved, it
does makes a difference when I participate in the decisions about the direction in which the project is
going… instead of just having a task delivered to me with a deadline”. And with the relation with the
scrum methodology respondent 9 said: “these tools or meetings that scrum has do fulfil a purpose, the
idea is to take advantage of the knowledge the team has, this contributes to a positive impact to the
project as well as to the whole team, they like being involved”.

4.3.3.3 Which factors have little or no influence to success in projects?

The external factors (economical, third parties, competition) are not considered to be important,
by the same reasons as perspective one. Those are considered out of their influence since there are
handled by the client.
As well the organizational structure and top management support, concerning the use of scrum,
there was a clear agreement that it does not matter much if it is applied in the management team or in
one of the technical teams, the result of the team effort comes out positive either way. Top
management does have an influence but if they agree on the methodologies to be used in the initiation
of the project there is little they can influence during the actual execution. As respondent 10
mentioned: “we apply scrum or any work methodology we consider it fits best and presents the best
results. If the client is happy, the company is happy and we are happy.”
Following the table of distinguishing factors will be presented. Those are the factors that stand out
from this perspective compared to the other ones. The Z-SCR means how HIGH or LOW the CSF
ranks to each other and this distinguishing factor will be discussed afterwards.
Table 4-8 | Distinguishing elements perspective three

Z coefficient
Z-SCR
No Statement P1 P2 P3 P4 placement

31 Product backlog -0.07 -0.17 1.40 -0.46 High

33 Division of roles 0.32 0.11 0.75 -1.3 High

24 Client participation 1.14 -1.22 -0.01 1.25 Mid-low

14 Adequate control 0.2 1.17 -0.48 1.06 Low

38 Stakeholder satisfaction 0.04 -1.3 -0.52 0.18 Mid-low

11 Flexibility on the definition of schedule -1.1 -1.71 -0.61 0.5 Mid-high

22 Top management support -0.55 -0.09 -1.30 1.44 Low

23 Organizational structure -0.29 0.28 -1.36 -0.7 Low

The importance of CSFs that are distinguishable high as: product backlog, division of roles. Are
all related the capability of the team to overview the whole project and were discussed in the previous
paragraph so it is not necessary to detail them here.
The importance of CSFs that are distinguishable low as: top management support and
organizational structure. Are all related to the lack of influence they have on a team once approved
their project methodology.

74
S Solis Vuurmans
https://t.me/PrMaB
4.3.4 Perspective four: “Capacity to respond to changes”
In the following Figure the characteristics of the respondents contributing to this fourth
perspective are shown. In total four respondents (13%) attribute to this perspective. Thus four
respondents share this same point of view.

Figure 4-12 | General characteristics respondents perspective four

When we look at the background group, we can observe that most the respondents who contribute
to the fourth perspective “Capacity to respond to changes” belongs to two reference groups:
infrastructure traditional and infrastructure scrum. The fact that the highest percentage comes out of
traditional environment is interesting since they usually begin with a very strict limitation of budget,
time and scope. This relates also to the fact that the roles that belong to these factors are mostly
project leaders (with 75% of respondents). We may draw the conclusion that the respondents
belonging to this perspective are aware that changes always will occur, and that in order to obtain a
successful project it is needed to adapt to those changes by being flexible.

75
S Solis Vuurmans
https://t.me/PrMaB
 The highest percentage of respondents is working in the design/construct phase of the project life
cycle. There is a high level of uncertainty in this phase that will be coped by flexibility of the parties
involved.
The type of client is 100% public entities. For infrastructure projects they know the client needs
evolves through time and this type of projects are executed in years. The ability to deal with the
changes is what makes a project successful.
Table 4-9 | Extra characteristics respondents perspective four

Perspective four Average of the total

number of
Min Max Average respondents

Age 38 60 49.00 41.1

Year working experience 10 38 23.25 14.45

Years experience in APM 0 6 1.50 1.79

Number of projects with APM 0 4 1.00 4.38

Duration of the project in months 6 120 67.50 29.25

Number of team members during the project 5 40 28.75 11.90

This perspective includes the older people, but also the most experienced ones in the field. Their
perspective is strongly based on experience on the field by having a respondent with 38 year’s
experience.
In this group there is also one respondent with some agile experience in the role of scrum master.
He is one of the most experienced (in the area of scrum) from the sample of people interviewed. Since
adapting to change is a core principle of agile it is intriguing that not many interviewees with scrum
experience entered this perspective. During the interviews it seemed they saw opportunity with scrum
when the task were clearly established beforehand, as respondent 21 said: “changes are going to
happen in your project you want it or not, the best way to deal with them is to be prepared”.

4.3.4.1 Assessment statements respondents perspective four

The figure below shows the average assessment of the CSF belonging to the fourth perspective,
which is related to “Capacity to respond to changes”. Again we can observe, although not that
explicitly as with the first perspective related to “Collaboration with client to maximize value”, that
the elements that score high are those that are marked “merged” and “agile”. The ones considered as
“traditional” elements relate to the idea of the perspective of coping with change.

76
S Solis Vuurmans
https://t.me/PrMaB
 !2.5% !2% !1.5% !1% !0.5% 0% 0.5% 1% 1.5% 2% 2.5%

2.Commitment%of%project%manager%
13.Adequate%communica;on%
5.Commitment%of%the%team%members%
22.Top%management%support%
24.Client%par;cipa;on%
10.Flexibility%on%the%defini;on%of%budget%
14.Adequate%control%
25.Client%acceptance%
9.Flexibility%on%the%defini;on%of%scope%
11.Flexibility%on%the%defini;on%of%schedule%
26.Client%commitment%
27.Efficient%resource%alloca;on%
20.Adequate%trouble!shoo;ng%
4.Team%work%of%team%members%
19.Adequate%monitoring%and%feedback%
16.Risk%management%
38.Stakeholder%sa;sfac;on%
7.Self%guided%teams%
30.Daily%stand!ups%
1.SoQ%skills%of%project%manager%
32.Retrospec;ves%
21.Urgency%
6.Technical%background%of%team%members%
8.Size%of%team%
3.Technical%background%of%Project%Manager%
28.Efficient%resource%sa;sfac;on%
31.Product%backlog%
12.Defini;on%of%value%
29.Efficient%resource%alignment%
23.Organiza;onal%structure%
17.Documenta;on%of%procedures%
18.Interchange%of%knowledge%
15.Safety%
Agile&element 37.Third%par;es%
Merged&element 33.Division%of%roles%
Traditional&element 34.Required%soQware%
35.Compe;;on%
36.Economical%

Figure 4-13 | Assessment perspective four: “Capacity to respond to change”

We will proceed to discuss what the respondents mentioned as the most important characteristics
of a successful project. They have been grouped and generalized for this discussion.

4.3.4.2 What are the key factors for successful projects?

On top the perspective considers the CSF Commitment and Communication crucial. The need to
incentivize both PM and TM and that is why the CSF of Top management support plays a key role.
The respondents mentioned that those factors need to be intertwined as respondent 25 said: “Specially
when there is a change, approval and support from my superior is needed, because it is always a
balance between on what the project needs and what Grontmij can give… if I don’t get the approval
of my superior it is a sort of impossible to really deliver a product I could be happy with, and neither
the client”.
The client participation also plays a major role, especially when it comes to flexibility. When you
can foresee changes, the client has to be involved and take part of the decisions to make; and there is
nothing better than actually having the client working together with Grontmij representatives.
Respondent 25 and 28 worked in the same project and the way they tackled this factor was by fixing
days during which the team gathered at the client’s office and literally worked in the same room as the
client. Respondent 25 said: “I have seen this in a lot of projects, when the client locks himself in and
is unreachable it is almost impossible to deliver a product with what he will be satisfied, since there is
no way to know what he wants, so we end up having to do a lot of rework that only costs extra money
and time… we can just collaborate with the client during the process so there is constant feedback on
what we are doing bad, and of course also what we are doing good”.

77
S Solis Vuurmans
https://t.me/PrMaB
4.3.4.3 Which factors have little or no influence to success in projects?
The external factors (economical, third parties, competition) are not considered to be important,
by the same reasons as perspective one and three. Those are considered out of their influence since
there are handled through the client.
As well the technical capabilities of PM as well as TM. They mention that those do influence but
are not essential since they consider each member of the company has the technical capacity to deliver
a good project, and in case they don’t, they are able to learn it during the process. Respondent 21
mentioned: “Here in Grontmij we have the knowledge, the key is to be able to exploit it, but that is
more related to how committed they are to the project than to their technical knowledge”.
Following the table of distinguishing factors will be presented. Those are the factors that stand out
from this perspective compared to the other ones. The Z-SCR means how HIGH or LOW the CSF
ranks to each other and this distinguishing factor will be discussed afterwards.
Table 4-10 | Distinguishing elements perspective four

Z coefficient
Z-SCR
No Statement P1 P2 P3 P4 placement

2 Commitment of project manager 0.65 0.66 0.21 2.06 High

22 Top management support -0.55 -0.09 -1.3 1.44 High

10 Flexibility on the definition of budget -0.64 -0.67 -0.14 1.13 High

11 Flexibility on the definition of schedule -1.1 -1.71 -0.61 0.50 High

4 Team work of team members 1.28 1.52 1.44 0.31 Low

1 Soft skills of project manager 1.03 1.58 0.8 -0.06 Low

6 Technical background of team members 0.59 1.64 0.98 -0.36 Low

18 Interchange of knowledge 0.49 -0.06 -0.24 -0.85 Low

15 Safety -2.22 -0.22 -2.15 -1.12 Mid-high

The importance of CSFs that are distinguishable high as: commitment of project manager, top
management support and flexibility of budget and schedule. Are all related the perspective of
flexibility and how to cope with it. They were discussed in the previous paragraph so we wont
detailed them here.
The importance of CSFs that are distinguishable low as: team work of team members, technical
knowledge and soft skills of project management.
For the soft factors for the TM and PM are not considered as essential by this perspective. As
respondent 28 says: “those soft skills are sort of important but not determinant in how the project will
perform, you could say it depends from person to person, but in my case, the quality of my work is the
same if I work with someone I like or with someone I don’t, I don’t let it influence my product”.
There is more focus towards the end product than to the process.

78
S Solis Vuurmans
https://t.me/PrMaB
4.4 COMPARING THE PERSPECTIVES
For some elements all perspectives share a somewhat same point of view, whilst for other
elements the perspectives have completely different points of view. In the following the consensus
elements as well as the disagreement elements will be discussed.

4.4.1 Consensus elements

In the following figure graphic representation of the consensus elements is shown. The consensus
elements are the elements that did not add to the distinguishing of any of the perspectives. One could
say these are the elements with regard to which all respondents share the same point of view. These
elements are therefore important to discuss, since they will provide much insight in the practical
usefulness of the elements and its subsequent application. Agreement about the usefulness of an
element amongst all respondents means that the element will truly be useful and could thus also truly
help reaching success in a project. The eight consensus elements are visually shown in the following
figure, which are:
1) Commitment of the team members
2) Adequate monitoring and feedback
3) Adequate trouble-shooting
4) Client acceptance
5) Efficient resource allocation
6) Efficient resource alignment
7) Retrospectives
8) Third parties

Figure 4-14 | Consensus elements

In the next table the Z-scores assigned by the different perspectives to the consensus elements are
shown. Each of the elements will be discussed below. First the elements with a relative high average
Z-score will be discussed followed by a discussion of more neutral scored elements and ending with a
discussion of the elements with a relative low average Z-score.

79
S Solis Vuurmans
https://t.me/PrMaB
 Table 4-11 | Consensus elements

No Statement P1 P2 P3 P4 Importance

5 Commitment of the team members 1.73 1.46 1.88 1.64 High

19 Adequate monitoring and feedback 0.03 0.93 0.55 0.27 Neutral

20 Adequate trouble-shooting 0.17 0.62 0.09 0.33 Neutral

25 Client acceptance 1.73 0.84 1.66 1 High

27 Efficient resource allocation -0.2 -0.44 -0.16 0.34 Neutral

29 Efficient resource alignment 0.31 -0.32 0.38 -0.51 Neutral

32 Retrospectives -0.33 0.42 0.34 -0.09 Neutral

37 Third parties -0.64 -1.24 -1.53 -1.22 Low

The CSF commitment of the team members is once again mentioned as important for success in all
perspectives. Hereby it is important in early stages of the project to carefully select the people keeping
in mind that they are motivated to do the work needed. This factor can also be influenced by the skills
of the PM through which commitment can be improved and maintained throughout the project.
The CSF of adequate monitoring and feedback as well as adequate troubleshooting are
interrelated. During the conversations with the respondents it was mentioned that it is quite important
to know the status of the project at any moment necessary, in order to execute any needed changes,
especially if those requirements come out of the Client. The team need to be prepared to handle this
changes accordingly, that is why there needs to be a proper mechanism to early identify problems and
be able to tackle them accordingly.
The CSF of client acceptance is a general issue with all respondents, since without it a project
cannot be regarded successful. The importance of trust and collaboration has been mentioned in
relation to this factor, and ways to overcome contractual altercations and/or division of risks that
might lead to a failed project. The consensus comes out of a change of mentality: instead of thinking
about the company working FOR the client, the company should work WITH the client.
The CSF related to resources, efficient resource allocation and efficient resource alignment score
neutral in all perspectives. The respondents agree that within the company resources are not scarce
and can be arranged with proper planning.
The CSF of retrospectives is linked with scrum as an event in order to learn from previous
projects. Respondents with scrum experience as well as traditional agree that being able to have an
input in the overall management of the project is important, their knowledge could have influence in
later stages of the project. The problem in traditional projects is that there don´t exist a proper process
to learn from mistakes. The proper integration of this factor could influence greatly the early detection
problems, the commitment of the advisors, and the continuous improvement of the process.
The CSF of third parties ranks low in all perspectives. The influence on external factors, for
example political influence and others, does not influence success in the environment of Grontmij as
an engineering firm. This comes out of the establishment of the Client being the representative of the
project towards all those external stakeholders.
The identification of the consensus CSF is important in order to obtain a proper point of view of
the whole sample of respondents. Great attention should be given to commitment of the team members
and client acceptance since those ranked high in all perspectives. Its implication in the existing
management process within Grontmij will be discusses in chapter 5.

80
S Solis Vuurmans
https://t.me/PrMaB
4.4.2 Disagreement elements
In the following figure a graphic representation of the disagreement elements is shown. The
disagreement elements are the elements that distinguish the perspectives. One could say that these
elements are those by which the perspective truly differs. These elements are important to discuss,
since they show which elements show the highest disagreement. Disagreement about the usefulness of
the elements could result in a grouping of elements for each perspective in which elements will help
reaching success and which elements will little help with success, in their point of view.

Figure 4-15 | Disagreement elements

In the following table the Z-scores assigned by the different perspectives to the disagreement
elements are shown. As can be noted there are considerably more elements about which the
perspectives disagree upon, compared to the elements about which the perspectives agreed upon.
Regarding to these disagreement elements, it is interesting to see whether all perspectives show
disagreement with each other or whether there is a particular perspective standing out. In the
following table the last column the disagreeing perspectives are listed. As each of these elements has
been already explored in the individual discussion of each perspective’s distinguishing elements these
elements will not be discussed in this section.

81
S Solis Vuurmans
https://t.me/PrMaB
 Table 4-12 | Disagreement elements

Z score
No Statement Relevance
P1 P2 P3 P4

3 Technical background of Project Manager -0.53 1.69 -0.48 -0.37 P2

9 Flexibility on the definition of scope -0.90 -2.67 0.38 0.66 P4

11 Flexibility on the definition of schedule -1.10 -1.71 -0.61 0.50 P4

13 Adequate communication 1.87 -0.40 1.80 1.89 P1 P3 P4

15 Safety -2.22 -0.22 -2.15 -1.12 P2

22 Top management support -0.55 -0.09 -1.30 1.44 P4

24 Client participation 1.14 -1.22 -0.01 1.25 P1 P4

34 Required software -1.36 0.72 0.41 -1.46 P2 P3

The identification of the disagreement CSF are important in order to obtain a proper point of view
of the whole sample of respondents. Its implications on the project management methodology on each
factor need to be addressed accordingly.
Its relation to the existing management process within Grontmij will be discussed in chapter 5.

4.5 ANALYSIS OF ONLY EXPERIENCE IN AGILE

After the analysis done with all 31 respondents, the review of the most important CSF by agile
experience people has to be considered into this research. The importance of this extra step is to make
a general profile of ‘agile advisors’ in order to make an analysis of the steps that needs to be taken in
order to further incentivise the use of agile in the infrastructure industry.
In the following Figure the characteristics of the respondents contributing to only having
experience with agile projects are shown. In total 21 respondents of the total of 31 comply with this
characteristic.

82
S Solis Vuurmans
https://t.me/PrMaB
 Figure 4-16 | General characteristics respondents with only agile experience

Major part of the respondents corresponds to the ICT department, while the persons related to
infrastructure are distributed in several departments. Several roles in the process are represented in
this analysis, from the core team members (technical advisors and developers) to project directors
(Department heads and project leaders).
All projects analysed belong to an early stage of the life cycle, as initiation and pre-design. For the
ICT sector the project is called to be in development since it is in constant delivery of results,
differentiating it from the infrastructure sector.
The client differs since 38% of the respondents work together with a ‘private’ client. The
developers from ICT work in that way and that is one of the reasons the continue using agile
methodology.

83
S Solis Vuurmans
https://t.me/PrMaB
 Table 4-13 | Extra characteristics respondents with only agile experience

Perspective three

Min Max Average

Age 27 56 40.0

Year working experience 2 33 13.0

Years experience in APM 1 6 2.5

Number of projects with APM 1 50 6.5

Duration of the project in months 1 48 20.9

Number of team members during the project 2 15 6.7

It is interesting the fact that there is a high variability in the characteristics of years experience
since it goes from just two to 33, as well as the number of projects and it’s durations. The biggest
difference to the general sample including the traditional respondents is that the number of team
members goes significantly down (from a general 11.2 to a 6.7 average).

4.5.1.1 Assessment statements respondents with only agile experience

The figure below shows the average assessment of the CSF belonging to the respondents with
agile experience.
Several analyses were done with this sample size, with one perspective (presented in this
paragraph) as well as with two and three different perspectives. The later were not considered since
the differences of ranking on CSF were not diverse enough from earlier established perspectives, or a
clear combination of them.
A better representation is given in the following table.
Table 4-14 | Agile experience sample perspective choosing

Total sample (31) Agile experience sample (21)

Number of perspectives 4 3 2 1 (chosen)

Perspectives P1: Collaboration with client for value A1

A1: Strong Agile

A1
perspective

P3: Team Empowerment A2

P4: Capacity to respond to change

A3 A2
P2: Strong leader

More results of the analysis made for the agile respondents can be reviewed in Appendix I, page
148.

84
S Solis Vuurmans
https://t.me/PrMaB
 Agile&element
Merged&element
Traditional&element

Figure 4-17 | Assessment respondents with agile experience

We will proceed to discuss what the respondents mentioned as the most important characteristics
of a successful project.
They have been grouped and generalized for this discussion.
High ranked CSF: The factors as: commitment of TM, communication, client acceptance and
teamwork; play a very important role in this agile experience perspective.
Mid ranked agile CSF: Flexibility is one core characteristic of agile and also the definition of
value. Those components in this general perspective rank mid level but for the further implementation
of agile practices in the industry they need to be incentivised.
Low ranked CSF: The external factors as urgency, third parties, economical, competition and
safety ranked low in their influence for success.
In order to progress the agile adaptation in infrastructure we present a two-stage process: a first
order CSF (immediate action) and second order (factors to consider for further implementation of
agile). The following figure is not only based on the results previously presented but also in the
interviews done on the respondents, that is why some low ranked elements are defined as key for
further agile implementation.

85
S Solis Vuurmans
https://t.me/PrMaB
 Immediate CSF: The main CSF
clusters are related to client, project,
PM, TM and APM.
There where no new CSF that
appeared important in this perspective
compared to what has been discussed
before in paragraph 4.3.
Basically this perspective based
only on persons with scrum experience
are a strong combination of the
following:
• P1: Collaboration with client for
value
• P3: Team empowerment
• P4: Capacity to respond to
change

There is very little to none relation

with P2: Strong leader. This fortifies the
conclusion that P1, P3 and P4 are the
agile perspectives and P2 is the most
traditional one.

Figure 4-18 | Agile adaptation based on positive CSF Further agile implementation
CSF: Are the strong agile elements that
ranked low in the perspective. Two
major clusters: related to organization and flexibility. It appears that in for this moment their
importance for success is not considered key. But for the further implementation of agile practices
those CSF are needed to incentivise since they are related directly to the agile manifesto.

4.6 DISCUSSION
The investigation and data collection, as described in this chapter, was primarily aimed at
obtaining an answer to the question about which factors are considered to be the most influential
factors for success (SQ3) by a sample of 31 persons (P set) all employed by Grontmij. This group of
respondents was selected on basis of the kind of their working environment (infrastructure industry
sector or ICT sector) and whether they had experience with Scrum as management methodology. Also
was taken into account to ensure in the sample a well representation of most of the in Grontmij
existing departments and positions (roles). Finally, the three sub-groups of respondents were (i)
Infrastructure traditional, without experience with Scrum, (ii) Infrastructure with experience with
Scrum, and (iii) ICT with Scrum, with an equal distribution of the number of participants in each of
them. So we may conclude that although the size of the sample has not been very large, which is a
characteristic of the Q-methodology, it was considered big enough and that most of the departments
and roles of Grontmij were well represented in the sample.
The information obtained from the respondents – through questionnaires in which they gave a
ranking to the 38 success factors (Q set) – was processed with the application of the software, called
PQMethod. As a result after running the factor analysis, four important perspectives on success
were identified and given a name, which are: (P1) Collaboration with client to maximize value, (P2)
Strong leader, (P3) Team empowerment, and (P4) Capacity to respond to changes. An interesting
result of the correlation calculation is that three out of the four identified perspectives (P1, P3 and P4)

86
S Solis Vuurmans
https://t.me/PrMaB
are strongly interconnected between each other, while the second perspective (Strong leader) does not
show a high correlation with the rest.
Each of the four perspectives has been analysed into detail. Based on a review of the average
assessment of the success factors per perspective and the additional information obtained through
follow-up interviews with the respondents, the main key factors for successful projects and also the
factors that are considered to have little or no influence to success in projects have been identified and
are further described. In the analysis of the average assessment of the CSF related to each perspective,
the profiles and backgrounds of each of the corresponding respondents have been reviewed, like: its
function or role within the company, the department to which belongs, the particular phase of the
project life cycle in which is working, whether the client is public or private, and whether the
respondent is man or woman. In addition, characteristics of the group of respondents related to a
particular perspective as a whole – like its average age, working experience, experience with APM
(number of years and number of projects), duration of the project, and team size during the project –
have been compared with the average of the entire group of 31 respondents, in order to detect the
main differences in the special characteristics.
The most outstanding observations we can make about the first perspective (Collaboration with
client to maximize value) are:
− Corresponds to the group with the highest number of respondents (45% of the total
sample), in which the three different background groups are equally represented (Infra
Trad, Infra Scrum and ICT).
− Also the kind of departments, roles and gender, are well distributed in this group of
respondents.
− Domination of respondents working in the pre-design phase of the project cycle.
− A big part of the CSF that are considered being the most important is related to agile
factors, like: team work, definition of value, and client participation; but also to “merged”
success factors which are closely linked to agile environment like: adequate
communication, client acceptance, and commitment of team members.
− Little importance is given to external factors like: urgency, competition, economical and
safety.
− Neither factors related to flexibility (of scope, time and budget) are recognized to be
important for success, which results to be an interesting finding since agile methodology
is characterized by its capacity to tackle and to adapt to changes.
− One of the most distinguishing elements that is highly valued in the first perspective
compared to the other three perspectives, is the “definition of value” in order to prioritize
and deliver the best result possible with high level of satisfaction of the client.
With regard to the second perspective (Strong leader) we can say that it is the most traditional
oriented perspective. Important findings worthwhile to highlight are:
− Main part of the respondents belong to the background group that don´t have experience
with Scrum (Infra Trad) and none of the members of the ICT group is associated with this
perspective.
− The persons who belong to this perspective group have the highest average age (51 years)
and the highest average number of working experience (20 years) and, consequently, are
inclined to maintain a more traditional way of project management.
− In this group we observe, compared to the other perspectives, the highest maximum
number of team members during the project (60 members); this may indicate that with big
teams a more hierarchical management method would fit better than a horizontal
management structure.
− The CSF which are considered to be most important for obtaining successful projects are
mainly related to traditional success factors, like: adequate control and monitoring system,
and the technical background of the project manager and of the team members. But also
other factors, more related to agile environment and the merged ones are mentioned,

87
S Solis Vuurmans
https://t.me/PrMaB
 which are: team work and their level of commitment, and soft skills of the project
manager.
− Apparently the project leader has the most influential role in this perspective, since he is
considered to be the end responsible of the final product.
− Four agile elements related to flexibility (on the definition of schedule and scope of the
project), to client participation and definition of value have scored very low, considering
them of little importance to achieve project success.
− The most distinguishing element that is highly valued in the second perspective compared
to the other three perspectives is the technical background of the project manager.
The third perspective is related to Team empowerment and the main results with regard to this
perspective are the following:
− Corresponds to the group with the second highest number of respondents (29% of the
total sample), in which only members of the two background groups with Scrum
experience form part (Infra Scrum and ICT Scrum) dominating the ICT group. This
confirms the statement that Scrum considers teamwork as an important key factor for
success.
− The different departments, roles and gender are relatively well distributed in this group of
respondents, although here again we observe a high participation of ICT members (ICT
GIS and developer roles).
− Emphasis is given to a horizontal way of project management, in which the team is given
an important role (and responsibility) during the whole project cycle with main intensity
during the development phase and, although also considered important, to a lesser extent
to the pre-design phase.
− The average age and number of years of the respondents belonging to this perspective is
very similar to the average of the whole sample group, but they differ very much with
regard to the number of years of experience and number of projects with APM, which is
considerably higher in this group compared to the rest of the sample.
− A big part of the CSF that are considered being the most important success factors is
related to merged and agile factors, like: commitment of the team members, adequate
communication and teamwork, acceptance of the client and product backlog.
− The most distinguishing statement, which contributes to project success in comparison
with the other perspectives, is the importance to count with product backlogs, being a
typical scrum element, and which is related to the capability of the team to overview the
whole project in which they are involved.
With regard to the last and fourth perspective about Capacity to respond to change we can
highlight the following findings:
− The respondents of this perspective belong to the background groups related to the
infrastructure sector, with as well as without Scrum experience, while none of the
members of the ICT group is associated with this perspective.
− The highest percentage of the respondents related to this perspective comes from the
traditional environment and are project leaders. Normally they give a lot of importance to
a defined budget, time and scope already fixed from the start of the project. Nevertheless,
they are also aware that changes during project implementation always occur and that it is
necessary to adapt to these changes in order to assure project success.
− With regard to the phase of the project life cycle, most of the respondents are working in
the design and construction phase (execution) when exists a high level of uncertainty y
risks, which obliges to the project implementers to adapt certain aspects of the project to
the changed circumstances.
− The group of respondents related to this perspective consists of experts with an average
age (49 years), which is major than that of the whole sample group, as well as experts
with a high average number of years of working experience (23 years).

88
S Solis Vuurmans
https://t.me/PrMaB
 − As a result, the factors considered to be important to successful projects are related mainly
to agile and merged factors, which are: commitment of the project leader and of the team
members, adequate communication, top management support, client participation and
flexibility on the definition of the budget.
− The most distinguishing statements, which contribute to project success in comparison
with the other perspectives, are the importance to count with high commitment of the
project manager, with top management support and with a sufficient degree of flexibility
with regard to budget and schedule.
Generally speaking, by reviewing the final results we can observe that not only the methodologies
are intertwined in the majority of respondents, but also that the most important CSF identified have a
direct relation with agile project management (APM).
Only perspective two: “strong leader” has the least adaptability to an agile environment, but was
only represented by 13% of the total sample (four respondents). So we can conclude that the majority
of respondents, with or without scrum experience, would fit very well in an infrastructure project
managed in an agile environment.
In the next chapter the projects characteristics will be discussed as well as an action plan in order
to propose clear activities besides the recommended scrum process that will optimize the important
CSF established in the results.

89
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER V
“If you do what you’ve always done, you’ll get what you’ve always gotten”
(Tony Robbins)

In this chapter the use of scrum in Grontmij will be analysed and, based on the results of the
research, specific recommendations will be presented. First the actual practices with regard to the
application of scrum in the Grontmij Company will be described (5.1). Then an improvement
plan, based on the research and interviews, will be presented focussed on the potential areas of
improvement and proposals for process adaptation (5.2).

5 OPORTUNITIES FOR AGILE WITHIN

GRONTMIJ
SQ4: How can this information be useful within the company?

Answer SQ4 summary: In the first place it is important to describe the

It was considered very useful by the Grontmij projects in Grontmij that have been using scrum,
Company to analyse their actual implementation because the particular characteristics of each of the
processes of infrastructure projects and to
projects may indicate whether the use of this new
compare their experiences with the findings from
literature review about APM. As an important
project management methodology managed to
product of the interviews a list of positive factors influence the success of the project. The analysis
and challenges of the implementation of scrum will be performed in a general manner since it goes
were identified. beyond the scope of this research to enter very much
Finally, a list of seven main actions is proposed into detail; nevertheless it will give a good insight
with the objective to maximize the effect of the into the problems mentioned by the respondents
positive CSF identified in the research. during the interviews.
By identifying the most critical success factor
(CSF) in the previous chapter and the problems faced in the scrum projects of Grontmij, the
presentation of ‘areas of improvement’ will be given. Based on the standardized scrum process
described in literature, some new processes and possible adaptations of the methodology will be
explained.

5.1 HOW HAS AGILE BEEN USED IN GRONTMIJ?

Since mid-2013, the Grontmij Company started to use scrum (agile tool) in some of their
infrastructure projects. This methodology was already used within Grontmij in its ICT GIS
department and it was decided to start to apply this methodology also in some stages of certain
90
S Solis Vuurmans
https://t.me/PrMaB
infrastructure projects11. The characteristics of the projects will be reviewed here below, as well as a
description of the level of scrum used in each of those projects since during the interviews various
problems were mentioned that might be related to scrum.

5.1.1 Scrum projects

The four projects related to infrastructure, where Grontmij has been using scrum, are: (i) the
Maxima Bridge on the Old Rhine, (ii) the Rijnlandroute which connects Katwijk with the A4, (iii)
The quality network of a variety of transport services – Hoogwaardig Openbaar Vervoer Hilversum –
in the Randstad, and (iv) the dike reinforcement project in Marken.

5.1.1.1 Maximabrug
Commissioned by the municipality of Alphen aan den Rijn and the municipality Rijnwoude,
Grontmij is responsible for the Design & Construct contract, the accompaniment of the competitive
dialogue and management contract during the implementation of the new Maxima Bridge on the Old
Rhine. The bridge of 100 meter long will solve dangerous traffic situations in Koudekerk aan den Rijn
and increases the accessibility of the industry area Hoogewaard. In this project Grontmij has used the
innovative Scrum methodology, consisting of a step-by-step approach where regular daily consults
makes it possible to introduce daily adjustments. As Maurice de Kroon, Project Manager Grontmij
says that: "By using the Scrum method we put our expertise even further in the most productive and
creative way for the customer. A real win-win situation”.
Table 5-1 | Summary of project Maximabrug characteristics

Period during Number of

which Scrum has members in the Client Type of contract Project phase
been applied scrum team

≈6 months Between 6 - 12 Municipality Fixed contract Engineering and

contracting

5.1.1.2 Rijnlandroute
Commissioned by the Province of South Holland, Grontmij has been responsible for the
development of the reference design of the Rhineland Route, which connects Katwijk with the A4.
For the implementation of this order Grontmij has used the innovative Scrum methodology, which is
based on short sprints and intensive cooperation, including daily short meetings. According to
Grontmij this management methodology allows an adequate management of common areas of interest
and improves efficiency in the implementation of the project.
Table 5-2 | Summary of project Rijnlandroute characteristics

Period during Number of

which Scrum has members in the Client Type of contract Project phase
been applied scrum team

≈7 months Between 5 - 15 Province Fixed contract Pre-design

11
We will focus on four infrastructure projects since those are the ones with the most interviewees who participated in the research
stage. A total of 11 of the engineers involved in the questionnaire, while another four were interviewed separately.

91
S Solis Vuurmans
https://t.me/PrMaB
5.1.1.3 HOV Hilversum
HOV Hilversum refers to a contract of Grontmij with the Province of South Holland to draw a
recommendation for a management and maintenance plan of the R-net bus corridors, which is a high
quality network of buses, trams, subways and trains in the Randstad.
Table 5-3 | Summary of project HOV Hilversum characteristics

Period during Number of

which Scrum has members in the Client Type of contract Project phase
been applied scrum team

≈6 months Between 7 - 12 Province, ProRail, Fixed contract Pre-design

Municipality

5.1.1.4 Dijkversterking Marken

Commissioned by Rijkwaterstaat (RWS), Grontmij is designing alternatives for dike
reinforcement in Marken. Grontmij assesses the technical feasibility of the different alternatives and is
checking whether these alternatives are consistent with the wishes of local residents and stakeholders.
The results of this process constitute the basis for the selection of a most preferred alternative.
Grontmij is implementing this prestigious project with the project management method scrum since,
according to experience of Grontmij, scrum not only saves time, but also reduces omissions in the
design and thus the costs of failure.
Table 5-4 | Summary of project Dijkversterking Marken characteristics

Period during Number of

which Scrum has members in the Client Type of contract Project phase
been applied scrum team

≈4 months (on- Between 5-6 RWS Fixed contract Pre-design

going project)

In all projects scrum was used in just a part of the totality of the project cycle period, particularly
in the pre-design phase and with an average period of approximate six months. In all cases the clients
are public entities and the projects had a fixed price contract. The only on-going project using scrum
at this moment is the Dijkversterking Marken. The other projects are finished already or have finally
changed its management style into a more traditional way of working. The details of how they applied
scrum during their execution will be described next.

5.1.2 Level of usage

Taking as reference the description of the scrum process and its required meetings and roles, and
based on the interviews and conversations with Grontmij employees, a process detail of the scrum use
within the Company has been developed. The description of the process, roles and activities will be
presented next.
The intention of the company was to use scrum correctly. For that reason they focused on
informing the advisors about the process through workshops and even with the help of hired external
consultants in the function of scrum master12. During the interviews three main questions were asked:
• Which events that happened during the project were directly related to scrum?
• Who was doing what in scrum?
• And what is your opinion of scrum?

12
Based on communications with an agile coach/trainer from Xebia. And an external scrum master/coach from New management
carousel.

92
S Solis Vuurmans
https://t.me/PrMaB
 Based on the information gathered by the interviews three pieces of information have been
elaborated: (i) the company scrum process, (ii) description of the scrum team, and (iii) discussion
about the overall opinion of scrum. Those three sub-paragraphs will be discussed next.

5.1.2.1 Company’s scrum process

The applied scrum process is shown in next figure and will be generally described in table
following. For effects of this research the description will be given in a general manner, focused on
the adaptations by infrastructure and comparing them with the Agile Project Management literature.
As shown in the next figure, the process diagram is divided into three phases: preparation, design
and delivery. In the preparatory phase projects formulate stories and tasks and are aimed at the
preparation of the backlog. The implementation phase is divided into sprints. At the end, the final
stage includes the review and sprint retrospective meeting.

93
S Solis Vuurmans
https://t.me/PrMaB
 Scrum process in Grontmij
Fase
Step 1: Product
Contract Formula5on Stories backlog
of stories defini5on
Step 2a: Step 2b: session
Dura5on
Analysis of Priori5zing
of stories
dura5on / and defini5on
story of done
Product
backlog yes

Step 3a:
Step 3b: Sprint
Selec5on of More tasks
Planning no

Ini5a5on phase
work for than 5me? backlog
poker
sprint

Step 4d:
no Comple5on of Burndown
burndown chart
Step 4c: Step 4a: chart
Impediments Step 4b:
Removing yes Division of
? Daily standup Step 4e:
impediments tasks Scrum board
Complete
scrum board

the scrum methodology to infrastructure projects.

Design phase
Increment

Step 5b:
Step 5a: Incomplete
All stories
Closing of no stories in
sprint
complete? product

S Solis Vuurmans
backlog

https://t.me/PrMaB
yes
New input Step 6:

Figure 5-1 | Existing scrum process diagram based on Jeukens (2014)

based on Presen5ng
feedback results to
client

New input Step 7: Process

based on Evalua5ng improvemen
evalua5on process t

Emtpy
n

Delivery phase
product
o
backlog?

yes

Product
complete

In the next table, and related to the diagram presented above, a comparison between the process in
literature and real practices in the Grontmij Company will be described. Special emphasis will be

94
given to the later since there is a certain degree of adjustment applied by Grontmij in order to adapt
 Table 5-5 | Detail of scrum process in literature and in Grontmij practice

Phase Scrum Step Literature Scrum application by Grontmij

Initiation Backlog 1 Formulation Establishment of technical specifications of the contract in

refinement of stories tasks. They use the Work Breakdown Structure (WBS) of
the project.

2a Analysis of Determination of preliminary time estimate. These

duration of estimations are also done during the tendering procedure.
stories

2b Prioritizing Prioritize stories; Formulate DoD. Drafting product

and DoD backlog. The duration of the sprints are defined together
with the concrete needed deliverables. The PO defines
what is needed for each sprint; the deliverables are related
to complete pieces of the WBS.

Sprint 3a Selection of Selection of work for sprint. In the WBS a selection of

planning work for tasks are identified which are considered to be the most
sprint important tasks to be completed in the sprint.

3b Planning Planning poker is used, also may use the time estimations
poker used during the tender phase. Sometimes it is difficult for
a member of the team to assess properly the duration of a
task in which they don’t have any experience.

Design Sprint 4a Division of The division of tasks is done according to the background
tasks and expertise of each person involved. The characteristic
of scrum teams in infrastructure projects is that they
consist of very specific niches of knowledge. For example
in a tunnel project, the contract advisor cannot design the
walls like a geotechnical expert would, and neither vice
versa.

4b Daily stand up This is what they call the daily scrum. They are not done
daily, since the team does not work full time on the project
during the whole week (40 hours). Daily stand ups are
held around two times a week and last around 15 minutes.

4c Removing Removing impediments, which is the task of the scrum

impediments master. If the impediment has to do directly with the
Client, the PO takes the impediment to the client.
Normally this process takes longer since the client is not
physically present.

4e Complete Complete scrum board. Two different tools are used to

scrum board keep track of their work: a physical board in the project
room or software called ‘Scrum wise’. Both tools have
been somewhat underused since it does require the extra
step to maintain the boards updated. Information as
‘velocity’ of the team as well as ‘burn down charts’ might
be a better indicator of the team performance, but it
requires that the scrum master keeps updating the work
delivered.

4f Testing/ Quality review of deliverables. This is considered an

Review important step in order to assure that the task meets for
100% to the standards and may be presented to the client.

95
S Solis Vuurmans
https://t.me/PrMaB
 5a Closing of Closing of sprint.
sprint

5b Incomplete Incomplete stories in PB.

stories in PB

Extensions 5c Backlog Non existent

refinement

5d Scrum of Non existent

Scrums
It is generally known that, in the cases when several scrum
teams are working on a project, it is not always easy to
assure fluent communication between them. The use of
scrum of scrums normally is applied in projects where a
high number of team members are involved.

Delivery Sprint review 6 Presenting Presenting results to the Product Owner

results to
client

Sprint 7 Evaluation of Feedback of the results by product owner to client

retrospective process

5.1.2.2 How is the scrum team organized?

Grontmij uses in most of its projects a similar organizational structure as what RWS uses, called
the Integral Project Management or IPM. And it is in this team where the focus of scrum has been
held.
The project is directed by a Project Leader (PL), or also called main Project Manager (PM), who
is the main responsible of the results of the project to the client and to the company. He has a major
team around him consisting of:
• Technical manager: depending on the complexity of the project there could be several
managers with different areas of expertise in technical aspects.
• Environment manager: Works with the ‘stakeholder management’ team of the client to
include the desires of the stakeholders as well as dealing with the surroundings of the
project (e.g. cables and drainage pipes companies and others).
• Contract manager: Controls and/or is in charge of writing the contract, or reviewing the
contractual responsibilities.
• System engineer: Controls the process through system engineering.
• Assistant project manager: is included for more complex projects where there is a need to
help controlling budget and planning.

The IPM model can be seen in the following figure. There is a distinctive hierarchy where
managerial roles have a number of advisors helping them with their technical input to contribute to
achieve the goal of the project.

96
S Solis Vuurmans
https://t.me/PrMaB
 The adaptation of this model to a
scrum methodology will be explained.
The Product Owner (PO): For the
use of scrum the PL assumes the role
Project leader of PO. He has the most direct contact
with the client and transfers his wishes
to the team members.
Assistant project Scrum Master (SM): Outside party
System engineer management if brought in to facilitate the scrum
required process. In the case of Grontmij the
person had no previous experience
with infrastructure projects. There
Enviroment Technical were people with scrum experience
manager manager Contract manager
from the ICT GIS department, as well
as in some cases an external consultant
specialized in scrum.
Team Members (TM): The scrum
team varied from being just the people
Figure 5-2 | IPM organizational structure from the IPM group, as well as
different scrum teams that were
established according to the requirements of the project and when different niches of knowledge were
needed.
This is a general description how the scrum teams have been adapted to the infrastructure projects
in Grontmij. They have been working with this IPM model and feel that it fits well with the new
methodology.

5.1.3 Overall opinion about scrum

The quantification of the results of the scrum projects goes beyond the scope of this research.
However during the process of interviews and information gathering we were able to identify a set of
positives characteristic of the ‘new’ way of managing a project, based on the point of view of the
engineers involved, together with the challenges they faced by using scrum for the first time.
In the following subchapters the positive particulars and challenges faced by using scrum in
infrastructure projects will be further discussed.

5.1.3.1 Positive outcomes by scrumming

The impression obtained during the interviews with some of the engineers involved was that their
appreciation of the scrum process was generally very positive. In frequent occasions they expressed
that they had a positive opinion about the methodology. A list of positive situations will be discussed
next:
Structure of work: Scrum presents a very structured way of working. From the fact that the whole
project is been broken down into the product backlog and that the members of the team know exactly
the status of the project at any given moment. This in particular was considered being very important
by the team from ICT GIS13, who have been working in developing the project for four years now. As
Thyssen (2015) mentioned: “There is certain ease to know what has been done, what everybody is
doing and what needs to be done to reach our sprint goals… gives satisfaction and certainty that we
are getting stuff delivered”.
Creation of team spirit: By working together in the same room it creates for the team members an
environment of continuous motivation. When asked whether they felt happy during the process they

13
Ten members of project ‘Obsurv’ interview in a workshop held in the offices of Rotterdam July, 2015

97
S Solis Vuurmans
https://t.me/PrMaB
answered positively. They really liked to have the opportunity to work with people from other
departments as Meulblok (2015) said: “During my time with scrum I ended up working with people I
usually never see, well maybe in the cafeteria, but while working with them you sort of make a bond,
and that was new since I basically only knew the people from my own department”.
Interchange of knowledge: The mix of different specialties in the scrum teams is key in order to
achieve maximizing the value of the project, since in infrastructure projects the different niches of
knowledge (ex: geotechnical and structural design) usually are treated and developed separately. But
it is important to highlight that they do have interfaces between them that may impact greatly the end
result of the project. As Slaterus (2015) mentioned: “My responsibility is to design electro-mechanical
installations, however the problem that always happens is that when the structural engineer changes
something it affects my whole design. When I was in the scrum team I knew exactly the input I
needed from him, and I was able to give special recommendations to the structural engineer that could
help to optimize my design”.
Efficiency of work: There is a high level of intensity while working with scrum. By intensity is
meant that in average two full days per week is needed to be scheduled in order to advance with the
project, besides the fact that every task has a clear responsible which induces reliability. As Brookhuis
(2015) said: “Overall the perception about advisors is that they don’t have a problem with that
reliability, but is motivating to be able to fulfil the task in the forecast time.”
Reduce the amount of rework (early detection of problems): The daily stand-ups present a great
tool in order to detect in time if is occurring something wrong. As Sluis (2015) mentioned: “If you do
something wrong, you only loose one day”. This might be a very strong point for the use of scrum in a
project. This should be researched further and quantified in order to establish the real advantage of the
new methodology.
Client satisfaction: Since working in an agile environment does require high client participation
the project always progresses in a manner that focuses on making the client happy. There exist
procedures to quantify this outcome but the analysis of comparing the degree of satisfaction between a
scrum project and a traditional one has not been researched in the context of this thesis. As Kroon
(2015) mentions: “I believe that scrum does assure that the product we deliver to the client fulfils their
needs, since we include their feedback continuously“. It is highly recommended that this issue should
be researched further.
There are numerous characteristics out of the scrum methodology that are considered as positive.
The ones mentioned were mentioned throughout the interviews and registered by the researcher. In
order to make a definitive analysis of them, a research should be taken place in order to focus on the
outcomes of scrum projects, quantifying them and comparing them with similar traditional projects.

5.1.3.2 Challenges faced while scrumming

In this subchapter we will discuss some details of the scrum experience of Grontmij that were
perceived as dilemma, and that might have affected the result of the project. The following adversities
were mentioned during the interviews and are subject to adjustments for following scrum projects:
Multitasking of team: The advisors are constantly working in several projects at the same time.
The different work schedules of the team members collide in some cases makes it difficult to them to
be present in all the events (DSU, review meetings, etc.). In later projects this was made a priority
during the selection of personnel in the early stages of the project.
Uncertainty about the benefits of scrum: The team members were not always very certain about
the real benefits of scrum. Even though they received proper guidance throughout the project and
were provided with proper information, there was some erroneous perception about the benefits of
scrum. The most noticeable was the fact that they preferred to use scrum when the tasks are constant
in the project, while the literature states that scrum is a way to better adapt to change (Highsmith,
2009).

98
S Solis Vuurmans
https://t.me/PrMaB
 High number of scrum ‘meeting’ or events: A cornerstone of agile project management are the
Daily Stand Ups (DSU), and if done correctly, they should be 15 minutes every day. This shook many
newcomers to the methodology. There is a relation between amount of events needed and the intensity
of the project (days per week).
Accountability for work: Some engineers have trouble being publicly accountable for the job they
perform. They normally interact with their supervisor and there are some still engineers who prefer
working in that manner.
High level of commitment of client: The client plays a key role in the scrum process, especially
with the feedback after each sprint. The product owner is the one who has to make key decisions that
have an impact on the work of the whole team. The client needs to be prepared to account for their
participation if he accepted the scrum methodology in order to exploit the corresponding benefits.
Not considering life cycle analysis (cost of saved rework): This was one of the biggest challenges
of innovation, there is still no quantitative analysis done on how scrum affects the end results of the
project (time and cost). Initially the intensity in hours per advisor in scrum projects is high in
company standards, but in some traditional projects there is need of rework, which involves extra time
and additional costs.
Scrum with a strict contract: Contracting in infrastructure is already quite standardized, specially
dealing with public entities. In the Agile manifesto (Beck et al., 2001) says: “Customer
collaboration over contract negotiation”. However, the relation of the type of contract used goes
beyond the scope of this project.

5.2 AREAS OF IMPROVEMENT

The objective of this chapter is to present to the Grontmij Company possible areas of
improvement based on the research results, which was directed to the identification of the CSF in
agile environment. First we will make an analysis of the relationship of the four perspectives
identified in chapter 4 with the core principles of scrum (5.2.1.) and afterwards give recommendations
of actions in order to maximize the opportunities of the most important CSF identified (5.2.2).

5.2.1 Relation of scrum and important CSF

They are four different perspectives identified by the Q-methodology used in this research. While
the sample used was restricted (31 persons) the group had diverse experience, range of roles, ages,
departments, infrastructure knowledge and, most important, scrum experience.
The idea behind this analysis was to see whether those perspectives had any relation with the
project management methodology used. Based on the research results we can determine that three
perspectives have a strong relation with scrum principles as is shown in the following figure.

99
S Solis Vuurmans
https://t.me/PrMaB
 Figure 5-3 | Relationship between the agile manifesto core elements and the research perspectives

This conclusion was drawn based on the highest ranked and most distinguished CSF. The relation
with the core principles of the agile manifesto and a brief explanation of the process will be given
next.
Perspective one “Collaboration with client to maximize value”: This perspective was the most
common out of the research (45% of the total sample of respondents). It is most closely related with
the scrum methodology since it focuses on client participation and the work of the team members, all
of this in order to achieve a high value project. Has a strong link to core principals of ‘customer
collaboration over contract negotiation’ as well as ‘individual interaction over processes and tools’.
Perspective two “Strong leader”: Has the least relation to the scrum methodology and also has the
least amount of respondents related to it (13% of the total sample). The perception is to need one sole
responsible and director of the project. And since scrum wants to give the team the responsibility to
direct the project it clashes in major principles.
Perspective three “Team empowerment”: Is also very much related to the scrum methodology and is
comprised of a high number of respondents (29%). Also a very important perspective, while the
respondents have a mixed view of adapting, since they are not very eager to change. However, the
perspective has a strong link to the core principal of ‘individual interaction over processes and tools’.
Perspective four “Collaboration with client for flexibility”: Is related to the scrum methodology as far
as the flexibility core is concerned and also has the least amount of persons related to it (13%). This
perspective is the trickiest to view as important for infrastructure projects since it is highly related to
the type of contract used in the project. Has a high link to core principals of ‘responding to change
over following a plan’.

100
S Solis Vuurmans
https://t.me/PrMaB
 By this overview we see a high relation of success perspectives somewhat related to core
principles of scrum. So even as the management methodology does not satisfy 100% of the
respondents it does present tools and processes that relate in a positive manner to a high number of
respondents.

101
S Solis Vuurmans
https://t.me/PrMaB
 5.2.2 Going more agile
Based on the previous information, with a focus on exploiting the opportunities of the use of
scrum in the infrastructure industry in Grontmij, a description of the recommended actions in
presented. Those actions are based on maximizing the positive valued CSF in the research.
In the following table a summary of the recommended actions will be given as well as their
relationship with the CSF.
Table 5-6 | Improvement actions

Important Factor Clusters

Recommended

Organization
action
Phase

Code

members
manager
Project

Project

Client
Team

APM
A. Selection of Definition
project of value
Flexibility
of scope,
budget
and time

B. Selection of Participa
client tion
Commit
ment
Initiation

C. Determining Technical
scrum teams knowledge
and
collaboration
Communication

Self guided
Organizational structure

D. Selection of Soft skills and

leader roles commitment

E. Selection of Technical
team knowledge
members and
collaboration

F. Definition
Execution
/ Design

of work DSU, PB and

schedule Commitment
retrospectives

G. Training
Permanent

Top
DSU, PB and
Commitment Commitment management
retrospectives
support

In the past table the idea is to link the important CSF based on the perspectives and linked them to
strategies of implementation gathered from different authors as (Kelley, 2007; Pichler, 2010;
Poppendieck & Poppendieck, 2009) but the establishment of recommendations on ‘going agile’ or ‘to
use scrum’ were mostly based on the books SCRUM IN ACTIE by de Boer, et al. (2015) and
SCRUM: THE ART OF DOING TWICE THE WORK IN HALF THE TIME by Sutherland (2014).
102
S Solis Vuurmans
https://t.me/PrMaB
A. Selection of project:
The most influential phase of scrum in a project is in the early stages of the life cycle. It is here
where the impact on maximizing the value takes significance. The methodology is helpful in case the
existing contract has a high number of uncertainties since the inclusion of the client’s perspective
throughout the whole process is needed, and that will help clear out any ambiguities in the project.
B. Selection of client:
This has been already mentioned by Jeukens (2014). It is important that a client is willing to
participate in the scrum process as well as that he is knowledgeable of scrum. Adapting to the sprint’s
deliverables and presenting feedback is key for the success of a project managed in an agile
environment.
C. Determining the scrum teams:
Depending on the project the establishment of efficient scrum teams is an important issue to be
taken into account. The recommended number of team members is around 7 persons14 but can easily
be adapted to the needs of the project throughout the process. There should be a focus on including
also actual developers/advisors in the team and not only limiting to management people. In case of
having several scrum teams a scrum of scrums could be beneficial.
The characteristic of the existing way of establishing scrum teams is that the persons included in
the scrum, are actually not the ones who are developing each task. They normally have advisors
working with them separately. Those advisors don’t participate in the scrum events; as DSU,
retrospectives or reviews. This situation makes the advantages of scrum less significant since the
process does not engage their knowledge and expertise.
The best way to adaption is to generate smaller scrum teams and execute events as scrum of
scrums. It would adapt to the existing IPM model since the major roles of PO and SM would prevail.
The proposed change of team distribution is presented in the following figure.

14
Based on expert scrum consultants.

103
S Solis Vuurmans
https://t.me/PrMaB
 Actual situation
Recommended

Figure 5-4 | Recommendation of scrum team distribution

As mentioned above the scrum team will be subdivided. The advisors will be able to participate
more in the direction of the project, but it does require commitment of all members of the project in
order to work. The scrum teams can be formed to tackle different tasks of the product backlog so the
idea to have them multidisciplinary is still possible, and if needed, can be formed with just one
technical background and tackle a complex part of the project. There are several possibilities to form
the teams; the idea is to take advantage of the scrum process.
D. Selection of leader roles: The product owner (PO) and scrum master (SM) play key roles in the
development of a scrum project. Their selection should be done carefully. Their knowledge of scrum
should be the highest of the whole company and they must count with soft skills (leadership,
innovation, negotiation).
The technical knowledge of the PO and SM is not a must but welcomed, especially at moments
when dealing with the client in order to get speedy feedback without having to recur to the advisors.
E. Selection of team members: The success depends as much from the process used as from the
people involved. It is key to include an extra step in order to select the right human resources.
Key features to take into account:
-Availability: Same days in order to participate in all scrum events.
-Level of multitasking: Depending on the intensity of the scrum, a low level of multitasking is
recommended. Just working on one project per day.

104
S Solis Vuurmans
https://t.me/PrMaB
 -Scrum knowledge: Of the process and core principles.
F. Definition of work schedule
This is one of the biggest adaptations of the scrum model. Since in infrastructure the intensity of work seldom
reaches to 40 hours a week per advisors. The events in scrum should be adapted as well. The key decisions refer
to:
- Work space: Working in the same room (define a scrum project room), and Scrum team works the
same days literally together.
- Adaptation to client’s needs: In order to incentivise client’s participation, we suggest to consider
working in same building as client.
There is a need to adapt to the methodology depending on the duration of the sprints (de Boer et
al., 2015).
Table 5-7 | Recommended duration of scrum meetings adapted from de Boer et al. (2015)

Sprint 4 weeks 3 weeks 2 weeks 1 week

Hours p/advisor <15 h/w 24 h/w 40 h/w +40 h/w
Sprint planning 2.5 hours 2.5 hours 2 hours 1.5 hours
Daily Stand Up 15 min 15 min 15 min 15 min
DSU frequency 2 /w 2-3 /w Daily Daily
Review 1.5 1.5 hours 1 hour 30 min
Retrospective 30 min 30 min 30 min 30 min

G. Training
It is important to continuously improve the methodology and to train the people involved. The
methodology itself presents a ‘learn from previous mistakes’ process, but the benefits of the agile
environment should be further spread. In Grontmij there was a committee called ‘the scrum guild’
with several major believer in scrum. It would be helpful to reinforce it if the company wants to
continue managing projects with scrum.

5.3 DISCUSSION
The Grontmij Company is in the Netherlands one of the pioneers in using scrum with
infrastructure projects. In the four concrete projects where scrum has been used, this methodology
was applied mainly in the pre-design phase and during an average period of six months. The
experience of Grontmij in scrum is considered very valuable and it is worthwhile to see how the
present research and its outcome can be of any use to the company in order to improve and expand the
scrum application in their projects.
In practice, the introduction of scrum in the four infrastructure projects went through a process of the
application of some adaptations in order to adjust the methodology to the particular characteristics of
the infrastructure projects and the organizational structure of the company. These adaptations have
been applied in a proper manner and received positive results as was expressed by the persons
involved.
Among those positive results we can mention the following achievements:
Structured way of working, Creation of team spirit, Interchange of knowledge, Efficiency of
work, Reduction of the amount of rework, Client satisfaction.
105
S Solis Vuurmans
https://t.me/PrMaB
 These outcomes, which are merely subjectively appreciated, should be analysed further in order to
quantify them and to compare them with traditional project management if we want to know for
certain if agile adapts positively to the infrastructure sector.
Apart from the positive outcomes, the team involved also faced a couple of challenges that were
perceived as dilemma while using scrum in infrastructure projects. Some of them are the personal
view of the advisor and others are strictly related to the management process, which are:
Multitasking of team that is working in several projects at the same time, Uncertainty about the
benefits of scrum, High number of scrum ‘meeting’ or events, Problem to be publicly accountable for
work, High level of commitment of client, Not considering life cycle analysis (cost estimation of
saved rework), Scrum with customer collaboration versus strict contract.
Although an extended analysis of these aspects was not beyond the scope of this research, it
would be interesting topics to analyse in order to further study the implications of infrastructure
projects in agile environment.
As a next step, the four perspectives (collaboration with client for value, team empowerment,
capacity to respond to changes, strong leader) together with the corresponding most distinguished
Critical Success Factors (which principally are: client acceptance, commitment and teamwork of team
members, and adequate communication) identified through the research, have been linked with the
three basic principles of the manifesto for agile development (customer collaboration over contract
negotiation, individual interaction over processes and tools, responding to change over following a
plan), in order to identify possible areas of improvement of scrum use within Grontmij.

Cri)cal Success
Agile principles Reseach perspec)ves Factors

Figure 5-5 | Relation Agile principles, perspectives and CSF

In the context of using the agile tool of scrum in infrastructure projects, the research has identified
CSF that are keen to focus on in order to maximize success and also those to be avoided that do not
contribute to this aspect.
By this analysis the following can be recommended:
Perspective one “Collaboration with client for maximizing value”: Working in short communication
channels, including also the client, will help into presenting the best value product with the existing
resources (time, budget and quality).
Perspective two “Strong leader”: With a main responsible for the project all decisions are going
through the project leader while the advisors only deliver what they are asked for. This perspective is
the one that is most related to the traditional ‘waterfall model’ where exists a clear division of tasks
and responsibilities.
Perspective three “Team empowerment”: This perspective involves persons that do want to be fully
engaged in the project. Different tools of agile like for example: Product Backlog, sprint meetings and
Daily Stand Ups (DSU) come in handy since, through the application of these tools, the team
members are able to give their input to the direction the project goes.
Perspective four “Capacity to respond to changes”: Related to high responsibility roles as project
leaders. They negotiate with the client in order to have flexibility of scope, budget and time with the
objective to present the best result possible. Is the most complex to analyse since it has a high relation
with the contract used. But trust between both parties is key.

106
S Solis Vuurmans
https://t.me/PrMaB
 Finally, a few recommendations are formulated about concrete actions, linked with their most
important CSF, to be introduced in the existing scrum processes of the Grontmij Company. The idea
behind these recommendations is to maximize the effect of positive CSF identified in early stages of
this research. The recommended actions are the following:
A. Selection of phase of the project cycle: It is mainly in the early stages of the project life cycle
(initiation, pre-design) when the highest impact on maximizing value can be expected through client
collaboration, and that is where scrum excels. This involves also flexibility of scope, time and budget.
B. Selection of client: Their knowledge of scrum and willingness to participate actively during the
whole process is key. A fluent communication is crucial and their feedback is considered an important
input after each sprint.
C. Determining the scrum teams: Smaller and efficient groups of collaborative team members with
good technical knowledge work better. It is important that also the advisors participate in scrum and
not only the IPM team. When the group becomes too big, a subdivision of the scrum team is
recommended: scrum of scrums will facilitate the communication.
D. Selection of leader roles: Since the Product Owner (PO) and the Scrum Master (SM) are key roles;
the selection of the persons for these functions should be done carefully. Special characteristics of
these persons are – apart from a good knowledge about the scrum methodology – leadership,
negotiation capacity, communication skills and innovation minded.
E. Selection of team members: Willingness to collaborate and communicate is key, making a ‘team’
that support and complement each other. If during the process a team member for some reason doesn´t
fit in the group, it must be possible to get him/her changed.
F. Definition of work schedule: Adapt the scrum events, sprint lengths to the days per week invested
in the project, don’t let it feel like an overdose of meetings.
G. Training: The training should be continuously and aimed at informing advisors, project leaders and
clients about the benefits of scrum, as well as promoting a process of “learn from previous mistakes”
and systematization of experiences with the objective to improve ever more the benefits of the agile
environment.

107
S Solis Vuurmans
https://t.me/PrMaB
 CHAPTER VI
“Change does not necessarily assure progress, but progress implacably
requires change" (Henry Steele Commager)

In this chapter the conclusions and recommendations will be presented. This chapter is divided
into two parts: (i) the conclusions (6.1) with regard to the research (6.1.1) and related to the
perspectives of success (6.1.2); and (ii) the conclusions of the use of scrum in the company (6.2)
which are divided into three types of recommendations: recommendations about the used
methodology, recommendations for the company and recommendations for further research.

6 CONCLUSIONS AND
RECOMMENDATIONS
How is the engineering company able to assess success of infrastructure projects in agile
managed environment?

Answer main question summary: Finally the overall objective of the present thesis
Exploiting the ‘Important CSF’, positive and research was to give an answer to the question in which
distinguishable CSFs, will facilitate the way the engineering company is able to assess success
achievement of successful infrastructure
of infrastructure projects in agile managed
project managed in an agile environment.
The application of ‘dependent CSF’ will lead
environment. In order to be able to treat this question a
success framework for infrastructure projects managed
in the future to further implementation of agile
projects in the infrastructure industry. in an agile environment has been developed, which
includes Critical Success Factors (CSF) identified
through an extensive literature review and which were
verified with a group of 31 respondents – all of them belonging to the Grontmij Company.
So this report contains an exploratory study about project success exploiting critical success
factors (CSF). Based on the framework we are able to identify which success factors were perceived
most critical to the project success by three different reference groups: (i) Infrastructure engineers
with scrum experience, (ii) Infrastructure engineers without scrum experience and (iii) ICT experts
with scrum experience (since this methodology originates in the software development industry). The
final purpose is to encourage that these factors will be taken into account in project implementation
processes in order to reinforce project success in the future, especially moving towards a more agile
style of project management.
Generally speaking, it is important to emphasize first of all that all projects are processes in time
where always changing circumstances take place and, secondly, that with agile management don´t
exist recipes, although there do exist useful tools, which within favourable working conditions can
help the companies to achieve higher levels of success of their projects.

108
S Solis Vuurmans
https://t.me/PrMaB
6.1 CONCLUSIONS
The conclusions of the literature review (6.1.1) and the perspectives on success (6.1.2) will be
presented in the following subchapters.

6.1.1 Conclusions about the literature research

The literature research was focused on the compilation and description of the concepts of success,
critical success factors, Q-methodology and agile project management. A resume of each topic will be
presented next:
DEFINITION OF SUCCESS: Success can be divided in success of the process or success of the
end result. Using a simplification of the excellence model of Westerveld (2003) a distinction can be
made between the success of the most influential parties in this research: the client, the company and
the team executing the project.
Since the research is directed to a relatively ‘new’ management method (APM), the main focus of
definition of success comes out of the advisors point of view. The interpretation was made in 2.1.2,
page 13, that success relates to ‘happiness’ in a way that:
a) The advisor feels ‘happy’ throughout the process, which motivates him to deliver the best work
possible.
b) The client is ‘happy’ to receive a product that fulfils a specific need.
c) The company is ‘happy’ to satisfy the client’s requirements while making some turnover.

For the purpose of the present research it was decided to take as main reference the first level (a),
namely the advisor’s subjective point of view; even though the relation to client, company,
stakeholder, end user and contracting parties also was considered, but always from the perspective of
the project personnel (advisors).

Figure 6-1 | Perspective of success analysed

CSF IDENTIFICATION: With the objective to establish the success framework to be used
based on Critical Success Factors, extensive literature research was done on this subject. First a clear
definition of the concept was formulated referencing 15 different articles published during a period
from 1979 till 2014.

109
S Solis Vuurmans
https://t.me/PrMaB
 Using that information as foundation, the proposed CSF framework combines other 16 articles
(seen in table 3.1, page 37) from 1986 till 2014. And since the objective was to present a tailored
framework for projects managed in agile environment, four articles are referring to the ICT industry.
Out of a total number of 260 CSF identified through the literature review, a list of 38 different
CSF was composed. Those 38 CSF were clustered in 8 different groups taken Belassi’s proposal
(Belassi & Tukel, 1996) as reference.
Q METHODOLOGY AS RESEARCH METHOD: The decision of using Q-methodology was
made because of its potential to present perspectives without the need to count with a high sample
number (Brown, 1978). For the research it was proposed to establish a Q-set of 38 variables and a P-
set of approximate 30 respondents.
The valuable data obtained through the questionnaire was not only the ranking of CSF but also the
follow up questions, where the concept of the respondent regarding to each of the factors could be
verified by the researcher (minimizing the risk of misunderstanding of factors) and during which
raised interesting aspects related to their experience in scrum projects.
RESEARCH DONE IN THE COMPANY: The complete set of persons (respondents) who
participated in this research belongs to the engineering firm Grontmij. The outcome of the proposed
success framework was also linked to ‘how they performed infrastructure projects with scrum’. Based
on this we found it useful to review the ways in which certain projects where managed and compare
their design process with what literature describes as ‘agile’.

6.1.2 Conclusions about the perspectives on success

Taking as reference the success framework that was designed in this research, a list of highly
ranked and distinguishable CSF was identified through the use of questionnaires and interviews.
These CSF are the factors about which most Q sorting respondents were positive, and which were
distinguishable in the three perspectives 1, 3 and 4 (Collaboration with client for value, Team
empowerment, and Capacity to respond to changes), all of the three being complementary between
each other and showing a direct relation with agile core principles. These factors are found to be
crucial for reaching success in infrastructure projects managed in an agile environment.
So not all the originally proposed 38 CSF will be discussed, but only the ones that received a high
ranking by the perspectives. The final objective is to present the most ‘important CSF’ to which is
needed to pay special attention exploiting them during the whole project life cycle, in order to
increase the chances of improving the success in projects.
In the next figure a categorization of the elements is shown, which provides insight in the
usefulness of the elements in the future implementation. Each of the 8 clusters will be discussed
separately. In the figure a distinction between ‘Level of rank of CSF’ and ‘relation between Agile and
traditional’ is made. The category of ‘High ranked CSF’ includes distinguishable CSF, the distinction
made in order to divide them in Agile or traditional is made based on the perspectives identified in
this research (specially perspective two, strong leader).
While not all CSF are included in the figure, it is important to advise that the low ranked Agile
elements are important to take into account if the intention of the company is to evolve further to a
more agile way of working. The low right corner represents the ‘Not very influential for success
factors’ are the ones that present little to no effect on the outcome of the process generally in all
perspectives.

110
S Solis Vuurmans
https://t.me/PrMaB
 Figure 6-2 | Conclusion summary on CSF by methodology

CSF RELATED TO CLIENT: All three CSF with reference to participation, acceptance /
satisfaction and commitment of the client are ranked positively in all perspectives and need to be fully
covered during the process in order to assure a successful project. This reaffirms at the same time the
“client orientation” of the Grontmij Company and coincides with the company´s core purpose (“We
enable our clients to make informed decisions and well-considered investments…”) and particularly
two of their three core values, which are:
1. Collaborative: refers to being part of a collective effort to meet the client’s needs,
working together to find win-win solutions with empathy and respect for all.
2. Reliable, where the company emphasizes that they are always there for their clients –
now and into the future – and that clients, partners and colleagues can all rely on them to
deliver quality performance.

CSF RELATED TO THE PROJECT: In the cluster related to the project there are two very
important and highly ranked CSF, which are: definition of value and adequate communication. The
agile methodology counts with special tools in order to give more structure to those two usually

111
S Solis Vuurmans
https://t.me/PrMaB
abstract factors. In the first place, the Daily Stand Ups (DSU) help shortening the communication
channels and reduce the need to produce extensive documentation. And since it is recommended to
work in the same physical space, team integration and communication is improved, helping the
synergy of the entire process. In order to quantify value the tool of product backlog is helpful. In
collaboration PO and team a prioritization of tasks is done for each sprint, giving a better picture on
what is the need/pain of the client.
The CSFs related to flexibility are essential elements in the application of agile in infrastructure,
but right now these factors might not be very influential since the contracting structure is generally
very rigid. Nevertheless, in the future if a more collaborative legal framework will be performed
(integrated contracts), the possibilities to not only adapt to change, but to thrive on it will help the
company and the industry to evolve.
The CSF of Urgency and Safety were considered un-influential for success. For the fact that
during the design process those two do not apply, even though the design considers it as important
during execution (actual construction).
CSF RELATED TO THE PROJECT MANAGER: A project manager needs to have proper
soft skills and commitment; the idea of having a high technical knowledge will help in the long run.
CSF RELATED TO TEAM MEMBERS: The team members need to have the technical
knowledge to fulfil the tasks adherent to their roles.
CSF RELATED TO THE ORGANIZATION: This cluster contains two factors, top
management support and organizational structure. Both are currently not key for success but if the
implementation of scrum wants to be spread further in the industry and in the company, both need re-
structuring.
It is indispensable top management support to deal with negotiations on subjects as project budget
and resources (hours per advisor). Since at first glance the high intensity of ‘scrumming’ may indicate
an important initial investment, but savings in the long term in aspects as: re-work, team efficiency,
and clients value perception are not been researched yet.
The same applies to the organizational structure, since the existing one is still hierarchical (having
a project leader and advisors). If the tendency is to move towards an agile way of working, the
‘managerial’ task is replaced with a more horizontal organizational structure, giving more
responsibility to the team members.
CSF RELATED TO EXTERNAL ENVIRONMENT: The characteristics of the projects
studied (mostly during pre-design phase through the view of the engineering company) the external
factors identified through literature do not have a real influence to the process. This is because most
external factors are handled through the client (mainly public entity), in this way all communication is
going via this entity.
CSF RELATED TO AVAILABLE RESOURCES: The availability of resources does not
influence the process towards success. Luckily in the studied situation human resources, workspace,
workstations, transportation, etc. are not restraining. Even if when some of the respondents do
considered an important factor they acknowledged that since the company has the capacity to deliver
it and adapt to the needs efficiently, there where not considered as important CSF.
The way resources are distributed differs greatly between waterfall and agile. Traditional manner
a team is build according to the needs of a specific project, to the people working together are
different in each project. While in agile the constant in the scrum team, and what varies is the projects
or tasks they perform. This may be one of the biggest reasons why the CSF related to resources aren’t
ranked high on this research and may be one of the biggest obstacles for total implementation of agile
in infrastructure.

112
S Solis Vuurmans
https://t.me/PrMaB
6.2 RECOMMENDATIONS
This chapter will provide in some recommendations. In the first paragraph recommendations
based on the research will be discussed. In the second paragraph some recommendations based on the
results will be provided and finally recommendations for further research are presented.

6.2.1 Recommendations of the research

DEFINITION OF SUCCESS: When it is unclear what project success means, it is difficult to
measure the success of a project by means of success criteria or to influence success with the aid of
success factors. It is therefore important to realize that project success can mean different things to
different people. A project that is successful in the opinion of a client is not necessarily also a success
in the eyes of the engineering firm and vice versa. And even if these two parties both experience a
project as successful there might be other stakeholders or end users who think differently about this.
The way the analysis of CSF remains a quantitative ranking based on subjective perceptions.
CSF IDENTIFICATION: While performing the literature study certain assumptions had to be
made when the set of success factors was composed out of the success factors provided by the
literature. Out of the initial set of success factors, the factors were combined wherever possible. This
may have led to misinterpretation of the real meaning of the factor. For instance ‘Leadership skills’
and ‘Leadership style’ were both merged into the factor ‘Soft skills of project management. It is
possible that the factors that were used during the interviews were made to general.
It is highly recommended to include the factors that were not, or almost not, mentioned in the
literature but were identified as critical in this research. Together with some of the factors that were
indicated as missing factors during the interviews. These factors are:
Identified as critical in this research
• Open and transparent project team communication
• Client and contractor have a common goal on maximizing value
• Collaborative culture
• Client involvement in process

Appointed during the interviews

• Contract type
• Knowing the interests of the other party and vice versa
• A competent/experienced client in the agile environment
• Early involvement of different disciplines during the design and execution phase

THE Q METHODOLOGY: Regarding the internal validity of the Q sorting research two main
limitations are distinguished.
• The statements included in the questionnaire were based on the distinguished helpful elements of
‘Traditional’ and ‘Agile’. Since the helpfulness of these elements was based on assumptions, also
the statements included in the questionnaire were based on assumptions. This makes the internal
validity of this research limited.
• Also the way the statements were explained led to a limited internal validity. Respondents might
have misinterpreted some statements. This is called a measurement error: the bias that originates
from the respondents' own interpretation and assessment of the survey (Visser, Krosnick, &
Lavrakas, 2000), and occurs in most studies using a written or electronic questionnaire.

6.2.2 Recommendations for the company

Based on the research main question, the proposed framework of success should be used in future
projects (managed in an agile way) as a way to improve success of their process.

113
S Solis Vuurmans
https://t.me/PrMaB
 The categorization as made in the conclusions is used as basis for the recommendations on how to
further implement the use Agile in the project management of infrastructure projects. It is advised to
divide the implementation and use into three steps: (i) Identification of CSF, (ii) Incentivize important
CSF based on perspectives and (iii) Recommended actions.

Figure 6-3 | Recommendation summary

OBTAIN LEADERSHIP APPROVAL AND SUPPORT: In order to successfully and viable

transition to Agile, it is important to socialize the methodology and the required changes involved
with the top executive level of the company. Having approval, buy-in, and support "from above"
better ensures success.
ADAPTION OF ORGANIZATIONAL STRUCTURE: Many firms proudly announce that
they have been undergoing Agile transformation without accepting the fact that in order to truly
appreciate the benefits of Agile tools and techniques as the mechanism for more effective product
development, firms also must adopt agility in their structure and culture. The former is just not
possible without the latter. Specifically, if an organization does not have in its plans to fundamentally
adjust its conventional hierarchical structure, flatten its convoluted reporting lines, remove redundant
roles that do not really contribute much value to the overall process, and trim wasteful activities, then
there will be no cultural shift. So in order to successfully transition to Agile, companies should be
willing and ready to reorganize.

114
S Solis Vuurmans
https://t.me/PrMaB
 ADEQUATE LOCATION OF TEAMS/WORK ENVIRONMENT: One of the core concepts
of Scrum is having a co-located team. During each sprint, the team works together in one area
completing all the analysis, design, testing and implementation work for each piece of the project.
This is done best in an agile style work environment, which would be a room that has whiteboards,
computers and enough space to collaborate as a team.
PROGRESSIVE SCRUM INTRODUCTION IN THE COMPANY: Instead of attempting top-
down Agile transformations of multiple teams, projects, and programs at the same time, it is much
more advisable for companies to start small, to consider a pilot Agile project to gain small, quick
wins, and then gradually proceed with Agile adoption by sharing knowledge and lessons learned
laterally: from team to team, from project to project. It is important, however, that executive support
and buy-in come all the way from the top-executive level, what is inevitably required for a lasting
cultural shift. Executive-level coaching is required for this to be a success.
(RE)TRAINING: To be successful in agile, proper training must be given to all those involved.
If not, expectations will not be properly set, which might lead to misjudgement and poor decisions. It
is important to train the staff on new and revised roles before attempting a Scrum implementation
(and train all new hires on these roles during orientation).
JOB DESCRIPTIONS REVIEW: It is necessary to rewrite job descriptions for the existing
team roles that will change under Scrum. One of the most disputable roles in agile product
development is that of the project manager (PM) and the concepts introduced by Scrum require the
role of the project manager to change. Traditionally trained project managers are confused as to what
their new roles and responsibilities should be in an environment that no longer needs them to make
stand-alone decisions. So it is recommended to focus on redefining the job of project manager to
better fit the self-managed team environment, one of the core agile principles. Special emphasis is
placed on the shift to servant leadership, with its focus on facilitation and collaboration.
Scrum also introduces new roles that do not exist in the old traditional structures, which are the
product owner and Scrum Master. The biggest problem is that many people don’t understand the full
scope of the Scrum Master role. Many times they see it as a passive facilitator role and all you need to
know is the mechanics of how to do Scrum. Most Certified Scrum Master (CSM) courses only cover
the basic mechanics of Daily Stand Ups, Sprint Reviews, Retrospectives, etc. and that’s a very small
fraction of what a good Scrum Master needs to know. The Scrum Master needs to be a facilitator who
supports the team in learning self-organization and the Scrum rules. The Scrum Master position is
rarely a full-time job and unless the SM is sanctioned to support multiple teams, it remains a part-time
facilitator role.
REORIENT PERFORMANCE REVIEW AND INCENTIVE STRATEGY: Scrum
recognizes the need for collaborative, self-organizing teams to succeed. Consequently performance
reviews should seek to improve success for the entire team and must be conducted differently from
traditional personal performance reviews. So it is important to remove the individual-oriented criteria,
such as job knowledge, time management, and ability to balance multiple priorities, and replace them
by team-oriented criteria, such as makes others better at their jobs, contributes to shared knowledge,
willingness to work beyond job title, and met team deliverable and quality goals. The performance
reviews should encourage team building and efficiency, reward team-serving, promote cross-
functional behaviours based on the newly revised job descriptions, and discourage individual
"superstar" goals that negatively impact teams.

6.2.3 Recommendations for further research

While the present thesis research provides some valuable insight into the agile culture, it also
shows some opportunities for further research.
• Cost/benefit analysis to determine whether the adoption of an agile framework is actually
monetarily beneficial for a company and client. It is not always easy to map end-client
satisfaction and demand, and subsequent revenue increase to changes of product
development approaches. A delayed cause-and-effect prevents executive management

115
S Solis Vuurmans
https://t.me/PrMaB
 from seeing results of Agile transformation soon enough to decide whether it is worth
continuing the experiment. Normally, executives do not use a "stop the ship" approach to
objectively analyse what has been accomplished in order to decide whether it makes sense
to continue.
• Development of standardized techniques or mechanisms to measure levels of agile
maturity across multiple organizational verticals. Although developing universal best
practices for multiple teams, even within the same organization, is not expected, the
ability to tie low-level (local, single-team) Agile metrics to global performance indicators
is possible and even desirable.
• This research was conducted for a civil engineering company and thus also focussed on
civil engineering companies. It is recommended to also conduct further research in the
field of agile from the point of view of the client of an infrastructure project or the
contractor contracted for an infrastructure project under an integrated contract.
• Agile Project Management (APM) tries to merge the distinctive phases of a project
towards a continue and incremental process (Sutherland, 2014), it would also be
interesting to examine the possible application and effect of implementing the Scrum
process beyond the project phases. Thus research into the effects of letting the clear
boundaries between phases go and (partially) merge them.
• The impact of agile of maximizing value is specially focused on what the client considers
valuable, at the long run the stakeholders and users are the ones making use of the product
so their perspective on success would be interesting to also be considered.
• Research about cultural impacts on Scrum methodology. Since this research was done
only in the Dutch environment the implications of cultural view on concepts as hierarchy,
or as Hofstede (Hofstede, Hofstede, & Minkov, 1997) characterizes as ‘power distance’, it
could influence the assimilation of a methodology as agile.

116
S Solis Vuurmans
https://t.me/PrMaB
 REFERENCES

Alliance, S. (2013). Scrum alliance. http://www.scrumalliance.org.

Atkinson, R. (1999). Project management: cost, time and quality, two best guesses and a
phenomenon, its time to accept other success criteria. International Journal of Project
Management, 17(6), 337-342.
AXELOS. (2014). Retrieved from https://www.axelos.com/prince2
Baker, B. N., Murphy, D. C., & Fisher, D. (2008). Factors affecting project success. Project
Management Handbook, Second Edition, 902-919.
Barber, P., Graves, A., Hall, M., Sheath, D., & Tomkins, C. (2000). Quality failure costs in civil
engineering projects. International Journal of Quality & Reliability Management, 17(4/5),
479-492. doi:doi:10.1108/02656710010298544
Beck, K., Beedle, M., Van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., . . . Jeffries,
R. (2001). Manifesto for agile software development.
Belassi, W., & Tukel, O. I. (1996). A new framework for determining critical success/failure factors
in projects. International Journal of Project Management, 14(3), 141-151.
Björnfot, A., & Stehn, L. (2004). Industrialization of Construction–a lean modular approach. Paper
presented at the Proceedings of the 12th Annual Conference of the International Group for
Lean Construction, Elsinore, Denmark.
BREAM. (2014). KEY PERFORMANCE INDICATORS (KPI'S) FOR THE CONSTRUCTION
INDUSTRY. BRE and CCI construction performance measurement and benchmarking
engine. Retrieved from http://www.bre.co.uk/page.jsp?id=1478
Brouwer, M. (1999). Q is accounting for tastes. Journal of Advertising Research, 39, 35-40.
Brown, S. R. (1970). On the use of variance designs in Q methodology. Psychological Record, 20,
179-189.
Brown, S. R. (1978). The importance of factors in Q methodology: Statistical and theoretical
considerations. Operant subjectivity.
Brown, S. R. (1980). Political subjectivity: Applications of Q methodology in political science: Yale
University Press.
Brown, S. R. (1993). A primer on Q methodology. Operant subjectivity, 16(3/4), 91-138.
Cantarelli, C. C. (2009). Cost overruns in Dutch transportation infrastructure projects. Paper
presented at the Delft University of Technology. Conference Presentation.
Chan, A. P. C., & Chan, A. P. L. (2004). Key performance indicators for measuring construction
success. Benchmarking: An International Journal, 11(2), 203-221.
doi:doi:10.1108/14635770410532624
Chin, K.-S., Chan, B. L., & Lam, P.-K. (2008). Identifying and prioritizing critical success factors for
coopetition strategy. Industrial Management & Data Systems, 108(4), 437-454.
Chow, T., & Cao, D.-B. (2008). A survey study of critical success factors in agile software projects.
Journal of Systems and Software, 81(6), 961-971.

117
S Solis Vuurmans
https://t.me/PrMaB
Clark, J. O. (2009). System of systems engineering and family of systems engineering from a
standards, V-model, and dual-V model perspective. Paper presented at the Systems
Conference, 2009 3rd Annual IEEE.
Cobb, C. G. (2011). Making Sense of Agile Project Management: Balancing Control and Agility:
Wiley.
Cohn, M. (2005). Agile Estimating and Planning: Pearson Education.
Cohn, M., & Ford, D. (2003). Introducing an agile process to an organization. Computer(6), 74-78.
Coman, L. (2014). Public project management in western Europe: perspectives on project success.
(Msc), TU Delft, Delft.
Cooke-Davies, T. (2002). The “real” success factors on projects. International Journal of Project
Management, 20(3), 185-190.
Dainty, A. R., Cheng, M.-I., & Moore, D. R. (2003). Redefining performance measures for
construction project managers: an empirical evaluation. Construction Management &
Economics, 21(2), 209-218.
de Boer, P., Bruggink, M., Bruns, M., van de Hoef, N., Peters, G., Roozemond, M., & Wijnands, W.
(2015). Scrum in actie: maak van elk project een succes! : Atlas Contact, Uitgeverij.
de Souza Bermejo, P. H., Zambalde, A. L., Tonelli, A. O., Souza, S. A., Zuppo, L. A., & Rosa, P. L.
(2014). Agile Principles and Achievement of Success in Software Development: A
Quantitative Study in Brazilian Organizations. Procedia Technology, 16, 718-727.
de Wit, A. (1988). Measurement of project success. International Journal of Project Management,
6(3), 164-170. doi:http://dx.doi.org/10.1016/0263-7863(88)90043-9
Deemer, P., Benefield, G., Larman, C., & Vodde, B. (2010). The scrum primer. Scrum Primer is an
in-depth introduction to the theory and practice of Scrum, albeit primarily from a software
development perspective, available at: http://assets. scrumtraininginstitute.
com/downloads/1/scrumprimer121. pdf, 1285931497, 15.
Flyvbjerg, B. (2006). Five misunderstandings about case-study research. Qualitative inquiry, 12(2),
219-245.
Flyvbjerg, B., Bruzelius, N., & Rothengatter, W. (2003). Megaprojects and Risk: An Anatomy of
Ambition: Cambridge University Press.
Flyvbjerg, B., Holm, M. S., & Buhl, S. (2002). Underestimating costs in public works projects: Error
or lie? Journal of the American planning association, 68(3), 279-295.
Freund, Y. P. (1988). Critical success factors. Planning Review, 16(4), 20-23.
Golany, B., & Shtub, A. Work Breakdown Structure. Handbook of Industrial Engineering:
Technology and Operations Management, Third Edition, 1263-1280.
Hertogh, M., & Westerveld, E. (2010). Playing with Complexity. Management and organisation of
large infrastructural projects: AT Osborne/Transumo.
Highsmith, J. (2009). Agile project management: creating innovative products: Pearson Education.
Hofstede, G., Hofstede, G. J., & Minkov, M. (1997). Cultures and organizations: McGraw Hill New
York, NY.
Institute, P. M. (2013). A Guide to the Project Management Body of Knowledge (PMBOK® Guide):
Project Management Institute, Incorporated.
Jeukens, G. (2014). Scrum: Oplossing of hulpmiddel tegen faalkosten? (Masters), Universiteit
Twente, Twente.
Karlesky, M., & Vander Voord, M. (2008). Agile Project Management. ESC, 247, 267.

118
S Solis Vuurmans
https://t.me/PrMaB
Kelley, T. (2007). The art of innovation: lessons in creativity from IDEO, America's leading design
firm: Crown Business.
Koops, L. (2015). [Q methodology questions].
Koskela, L. (2003). Is structural change the primary solution to the problems of construction?
Building Research & Information, 31(2), 85-96. doi:10.1080/09613210301999
Kroon, M. (2014). Use of Scrum in Grontmij. Retrieved from
http://www.grontmij.nl/Diensten/Infrastructuur-en-mobiliteit/Pages/Met-de-scrum-methode-
optimale-uitvoering-van-projecten.aspx
Latham, G. P., Fay, C. H., & Saari, L. M. (1979). The development of behavioral observation scales
for appraising the performance of foremen. Personnel Psychology, 32(2), 299-311.
Lavèn, A. (2014). Retrieved from http://www.grontmij.com/Pages/design-engineering-management-
consultants-grontmij.aspx
Layton, M. C. (2012). Agile Project Management For Dummies: Wiley.
Lester, A. (2006). Project Management, Planning and Control: Managing Engineering, Construction
and Manufacturing Projects to PMI, APM and BSI Standards: Elsevier Science.
Leybourn, E. (2013). Directing The Agile Organisation: A lean approach to business management: IT
Governance Ltd.
Li, B., Akintoye, A., Edwards, P. J., & Hardcastle, C. (2005). Critical success factors for PPP/PFI
projects in the UK construction industry. Construction Management and Economics, 23(5),
459-471. doi:10.1080/01446190500041537
Lim, C., & Mohamed, M. Z. (1999). Criteria of project success: an exploratory re-examination.
International Journal of Project Management, 17(4), 243-248. Retrieved from http://ac.els-
cdn.com/S0263786398000404/1-s2.0-S0263786398000404-main.pdf?_tid=075bfb78-62ad-
11e5-9590-00000aab0f02&acdnat=1443093279_1aec7fa44993a4f53e6242d1f34a0c0c
Loenhout, C. (2013). Public project manager's perspective on project success. (MSc Construction
Management and Engineering), TU Delft, Delft, The Netherlands.
Management, A. f. P. (2006). APM Body of Knowledge: The Association.
Misra, S. C., Kumar, V., & Kumar, U. (2009). Identifying some important success factors in adopting
agile software development practices. Journal of Systems and Software, 82(11), 1869-1890.
Morris, P., Patel, M., & Wearne, S. H. (2000). Research into revising the APM project management
body of knowledge. International Journal of Project Management, 18(3), 155-164. Retrieved
from http://ac.els-cdn.com/S026378639900068X/1-s2.0-S026378639900068X-
main.pdf?_tid=d15546e2-62ac-11e5-ab47-
00000aacb35d&acdnat=1443093189_a3c1b501cc30b86dec40987df2011a9a
Munns, A. K., & Bjeirmi, B. F. (1996). The role of project management in achieving project success.
International Journal of Project Management, 14(2), 81-87.
doi:http://dx.doi.org/10.1016/0263-7863(95)00057-7
Pichler, R. (2010). Agile product management with scrum: Creating products that customers love:
Addison-Wesley Professional.
Pinto, J. K., & Covin, J. G. (1989). Critical factors in project implementation: a comparison of
construction and R&D projects. Technovation, 9(1), 49-62.
Pinto, J. K., & Slevin, D. P. (1988). Project success: definitions and measurement techniques.
PMI. (2014). Retrieved from http://www.pmi.org/PMBOK-Guide-and-Standards.aspx
Poppendieck, M., & Poppendieck, T. (2009). Leading lean software development: Results are not the
point: Pearson Education.

119
S Solis Vuurmans
https://t.me/PrMaB
Ridder, d. (2011). Dynamic control of projects. Paper presented at the Dynamic control of projects,
TU Delft.
Risdon, A., Eccleston, C., Crombez, G., & McCracken, L. (2003). How can we learn to live with
pain? A Q-methodological analysis of the diverse understandings of acceptance of chronic
pain. Social science & medicine, 56(2), 375-386. Retrieved from
http://www.sciencedirect.com/science/article/pii/S0277953602000436
Rockart, J. F. (1978). Chief executives define their own data needs. Harvard business review, 57(2),
81-93.
Rockart, J. F. (1982). The changing role of the information systems executive: a critical success
factors perspective: Massachusetts Institute of Technology Boston.
Schendel, D., & Hofer, C. W. (1979). Strategic management: A new view of business policy and
planning: Little, Brown.
Schwaber, K. (1997). Scrum development process Business Object Design and Implementation (pp.
117-134): Springer.
Servello, M., & Evans, M. W. (2002). Work Breakdown Structure Encyclopedia of Software
Engineering: John Wiley & Sons, Inc.
Shenhar, A. J., Dvir, D., Levy, O., & Maltz, A. C. (2001). Project Success: A Multidimensional
Strategic Concept. Long Range Planning, 34(6), 699-725.
doi:http://dx.doi.org/10.1016/S0024-6301(01)00097-8
Smith, N. W. (2001). Current Systems in Psychology: History. Theory, Research, and Applications.
Stabell, C. B., & Fjeldstad, Ø. D. (1998). Configuring value for competitive advantage: on chains,
shops, and networks. Strategic management journal, 19(5), 413-437. Retrieved from
http://onlinelibrary.wiley.com/store/10.1002/(SICI)1097-0266(199805)19:5%3C413::AID-
SMJ946%3E3.0.CO;2-
C/asset/946_ftp.pdf?v=1&t=i8h76lwh&s=b69737c1521fd97e994a7582b1c3c6e2552a9f92
Stankovic, D., Nikolic, V., Djordjevic, M., & Cao, D.-B. (2013). A survey study of critical success
factors in agile software projects in former Yugoslavia IT companies. Journal of Systems and
Software, 86(6), 1663-1678.
Suprapto, P. (2015). [Q methodology basic questions].
Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time: Crown Publishing
Group.
Thomas, D. B., & Baas, L. R. (1992). The issue of generalization in Q methodology:“Reliable
schematics” revisited. Operant subjectivity, 16(1), 18-36.
Thomas, J., & Mengel, T. (2008). Preparing project managers to deal with complexity – Advanced
project management education. International Journal of Project Management, 26(3), 304-
315. doi:http://dx.doi.org/10.1016/j.ijproman.2008.01.001
Toor, S.-u.-R., & Ogunlana, S. O. (2008). Critical COMs of success in large-scale construction
projects: evidence from Thailand construction industry. International Journal of Project
Management, 26(4), 420-430. Retrieved from http://ac.els-cdn.com/S0263786307001275/1-
s2.0-S0263786307001275-main.pdf?_tid=57482dc0-e295-11e4-945c-
00000aacb35d&acdnat=1429009357_abee38cbb942bc3dca6264e22b096ee5
Toor, S.-u.-R., & Ogunlana, S. O. (2010). Beyond the ‘iron triangle’: stakeholder perception of key
performance indicators (KPIs) for large-scale public sector development projects.
International Journal of Project Management, 28(3), 228-236. Retrieved from http://ac.els-
cdn.com/S0263786309000623/1-s2.0-S0263786309000623-main.pdf?_tid=6b769ff2-e295-
11e4-adb6-00000aab0f6c&acdnat=1429009390_f77571db340bcc5ab4c45bd763d5fb82

120
S Solis Vuurmans
https://t.me/PrMaB
Turner, P. J. R. (2014). Gower Handbook of Project Management: Ashgate Publishing, Limited.
van Eeten, M. J. G. (1999). Dialogues of the deaf: defining new agendas for environmental deadlocks:
TU Delft, Delft University of Technology.
Van Exel, J., & de Graaf, G. (2005). Q methodology: A sneak preview. Online document. http://www.
qmethodology. net/PDF/Q-methodology.
Verschuren, P., & Doorewaard, H. (2010). Designing a Research Project: Eleven International
Publishing House.
Visser, P. S., Krosnick, J. A., & Lavrakas, P. J. (2000). Survey research.
Wagner, C. (2014). Is it project success a coincidence or can it be enforced? a Comparative study on
the critical success factors of the Stadsbrug Nijmegen project and similar civil engineering
projects in The Netherlands. (Msc), TU Delft, Delft.
Weber, A., & Thomas, I. R. (2005). Key performance indicators. Measuring and Managing the
Maintenance Function, Ivara.
Webler, T., Danielson, S., & Tuler, S. (2009). Using Q method to reveal social perspectives in
environmental research. Greenfield MA: Social and Environmental Research Institute, 54.
Westerveld, E. (2003). The Project Excellence Model®: linking success criteria and critical success
factors. International Journal of Project Management, 21(6), 411-418.
Wideman, R. M. (2002). Comparing PRINCE2® with PMBoK®. http://www. pmforum.
org/library/papers/Prince2vsGuide3easrd1. htm. Acessado em, 1(04), 2004.
Wijnen, G., & Storm, P. (2011). Projectmatig werken: Unieboek | Het Spectrum.
Yllén Johansson, M. (2012). Agile project management in the construction industry: An inquiry of the
oppurtunities in construction projects.

121
S Solis Vuurmans
https://t.me/PrMaB
 APPENDIX

122
S Solis Vuurmans
https://t.me/PrMaB
 A. QUICK OVERVIEW OF OTHER WATERFALL MODEL
PROJECT MANAGEMENT METHODOLOGIES
We will mention some ‘traditional’ project management methodologies that are more entrenched
in the construction industry. The most known in Europe are PRINCE2 and PMBOK.
PRINCE2: PRojects IN Controlled Environments (PRINCE2), as their official website states
(AXELOS, 2014), and was initially developed in 1989 by the Central Computer and
Telecommunications Agency (CCTA) as a UK Government standard for information systems (IT)
project management. It isolates the management aspects of project work from the specialist
contributions, such as design and construction.
PRINCE2 is based on seven principles (continued business justification, learn from experience,
defined roles and responsibilities, manage by stages, manage by exception, focus on products and
tailored to suit the project environment), seven themes (business case, organization, quality, plans,
risk, change and progress) and seven processes as seen in the following figure.

Figure 6-4 | Structure of PRINCE2 by Axelos, 2014

The seven themes are the following (AXELOS, 2014):

1. Business case: What value would delivering the project bring to the organization?
2. Organization: How will the project team's individual roles and responsibilities be defined in
order for them to effectively manage the project?
3. Quality: What the quality requirements and measures are and how the project will deliver
them.
4. Plans: The steps required to develop the plans and PRINCE2 techniques that should be used.
5. Risk: How the project management will address the uncertainties in its plans and the project
environment.
6. Change: How the project management will assess and act on unforeseen issues or requests for
change.
7. Progress: The on-going viability and performance of the plans and how and whether the
project should proceed.

123
S Solis Vuurmans
https://t.me/PrMaB
 The PRINCE2 processes describe the steps of the project lifecycle, from getting started to project
closure. Each process provides checklists of recommended activities, products and related
responsibilities. Processes are the following and can be seen in the Figure 6-5: (i) Starting up a
project, (ii) Directing a project, (iii) Initiating a project, (iv) controlling a stage, (v) Managing product
delivery, (vi) Managing stage boundaries and (vii) Closing a project.

Figure 6-5 | Use of PRINCE2 processes through the project life cycle

PMBOK: The Guide to the Project Management Body of Knowledge (PMBOK guide) is
developed by the Project Management Institute (PMI), (PMI, 2014). It presents a conceptualization
practices, knowledge, skills, tools, and techniques can enhance the chance of success over many
projects.
The guide is based mostly in processes; in which each is divided in: (i) Input, (ii) Tools and
techniques (mechanisms applied) and (iii) Outputs (documents, plans, designs).
The methodology divides the project in five processes groups (Institute, 2013).
1. Initiating: Those processes performed to define a new project or a new phase of an existing
project by obtaining authorization to start the project or phase.
2. Planning: Those processes required to establish the scope of the project, refine the objectives, and
define the course of action required to attain the objectives that the project was undertaken to
achieve.
3. Executing: Those processes performed to complete the work defined in the project management
plan to satisfy the project specifications
4. Monitoring and Controlling: Those processes required to track, review, and regulate the progress
and performance of the project; identify any areas in which changes to the plan are required; and
initiate the corresponding changes.
5. Closing: Those processes performed to finalize all activities across all Process Groups to formally
close the project or phase.
Each of them interacts with each other during the lifecycle of the project, as seen in the following
figure.

124
S Solis Vuurmans
https://t.me/PrMaB
 Figure 6-6 | Process groups in phases of project by PMI (2013)

Another major characteristic of this project management methodology is the knowledge areas.
The ten knowledge areas are (Institute, 2013):
1. Project Integration Management: Project Integration Management includes the processes and
activities needed to identify, define, combine, unify, and coordinate the various processes and
project management activities within the Project Management Process Groups.
2. Project Scope Management: Project Scope Management includes the processes required to ensure
that the project includes all the work required, and only the work required, to complete the project
successfully.
3. Project Time Management: Project Time Management includes the processes required to manage
the timely completion of the project.
4. Project Cost Management: Project Cost Management includes the processes involved in planning,
estimating, budgeting, financing, funding, managing, and controlling costs so that the project can
be completed within the approved budget.
5. Project Quality Management: Project Quality Management includes the processes and activities
of the performing organization that determine quality policies, objectives, and responsibilities so
that the project will satisfy the needs for which it was undertaken.
6. Project Human Resource Management: Project Human Resource Management includes the
processes that organize, manage, and lead the project team.
7. Project Communications Management: Project Communications Management includes the
processes that are required to ensure timely and appropriate planning, collection, creation,
distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of
project information.
8. Project Risk Management: Project Risk Management includes the processes of conducting risk
management planning, identification, analysis, response planning, and controlling risk on a
project.
9. Project Procurement Management: Project Procurement Management includes the processes
necessary to purchase or acquire products, services, or results needed from outside the project
team
10. Project Stakeholders Management: Project Stakeholder Management includes the processes
required to identify all people or organizations impacted by the project, analysing stakeholder
expectations and impact on the project, and developing appropriate management strategies for
effectively engaging stakeholders in project decisions and execution.
125
S Solis Vuurmans
https://t.me/PrMaB
 Each of the ten knowledge areas contains the processes that need to be accomplished within its
discipline in order to achieve effective project management expanding on the basic knowledge of the
‘iron triangle’ to a more elaborated setting as presented in the next figure.

Figure 6-7 | Knowledge areas according to PMBOK

126
S Solis Vuurmans
https://t.me/PrMaB
 B. STATISTICAL ANALISYS OF Q-METHODOLOGY
The analysis comprises two parts. The first one being composing a correlation matrix and the
second one being the factor analysis. The correlation matrix shows the correlations between the
different points of view. A correlation of +1, a perfect positive correlation, between two points of
view means that the points of view are identical. A correlation of -1 gives a perfect negative
correlation, thus no statement was assessed equally. In order to calculate the correlation between two
points of view the following formula can be used:
𝐷!
𝑟 =1− ! !
𝑆!! + 𝑆!!
Where D is the difference between the scoring of the first respondent on one statements and the
scoring of the second respondent on that same statement. D2 is the root square of this difference and
ΣD2 is the summation of all the square root differences over all the statements assessed. Sr1 is the
scoring of respondent one on one of the statements and Sr12 is the square root of this scoring. ΣSr1 2
is the summation of all the scoring’s square roots. For ΣSr2 2 the same applies. These calculated
correlations can then be put into a matrix, the correlation matrix. The amount of correlations in the
matrix is then n2. Where n is the number of conducted Q sorts, thus the amount of respondents
(Brown, 1993).
In order to assess whether a correlation can considered to be substantial the standard error can be
calculated. In order to do so the following formula can be used:
1
𝑆𝐸 =
𝑛

Where n is the amount of statements assessed by the respondents. Correlations are then
considered to be significant when their absolute value is at least 2 to 2.5 times bigger than the
standard error (Brown, 1993).
Next step in the analysis is conducting a factor analysis. "A factor analysis examines a correlation
matrix and determines how many basically different Q sorts are evidence" (Brown, 1993). High
correlations between a set of Q sorts and low correlations of those Q sorts with other Q sorts may
indicate a factor. With factor analysis one tries to define these factors. To do so, first an initial amount
of factors needs to be estimated. Next factor loadings can be calculated. Factor loadings are the
correlations of individual Q sorts with the factor, which in fact is the average of the set of highly
correlated Q sorts. Factor loadings which are bigger than the absolute value 0.5 are considered to be
significant. In the first graph of figure 35 two factors are set out and four Q sorts are considered. The
factor loading of one of the Q sorts is also shown. In order to highlight the connections between the Q
sorts one could use rotation. The factors are rotated, as is shown in the second graph of figure 35. As
can be seen the factor loadings of the two upper Q sorts become more alike in comparison with the
unrotated situation. Another benefit of rotation is that factor loadings might increase which is
beneficial for the significance of the factor loading. For the example Q sort one can see that the factor
loading on factor one increases from 0.55 to 0.8, whereas the factor loading on factor two decreases
from 0.6 to 0.2. Factor rotation can be performed as many times as needed to result in a final set of
factors (Brown, 1993).
Interpreting: For interpreting the final factors not so much the factor loadings are interesting but
more the factor scores. The factor score of a statement is the weighted average score of a statement,
based on the scorings on that statement of each of the Q sorts corresponding with the factor. The
weighted average needs to be calculated since not all Q sorts have the same correlation with the
factor. A Q sort correlating higher with the factor should also have more weight in defining the factor.
The Q sorts are assigned weights according to the following formula:

127
S Solis Vuurmans
https://t.me/PrMaB
 𝑓
𝑤=
1 − 𝑓!
Where w is the Q sort's weight and f is the factor loading of the Q sort.
By multiplying the weights with the scoring of the Q sort on the specific statement and doing so
for all the Q sorts associated with the factor, the final factor score of the statement can be calculated.
Thus applying the following formula:

𝐹𝑆! = 𝑊!" ∗ 𝑆!,!"

Where FSx is the factor score of statement x , wri is the weight of the Q sort as filled out by
respondent i , and Sx,ri is the scoring assigned to statement x by respondent i .
The statements can then be put into the standard Q sorting score sheet based on their factor scores.
Thus the statement with the highest factor score will be assigned +3, and the statements with the
lowest factor score -3, and so on. This results in the 'average' Q sort of a factor (Brown, 1993). Based
on this 'average' Q sort the researcher can interpret the factor and can also assign a name to the factor
(Brown, 1980). By examining the statements that distinguishes the factor from the other factors, the
researcher may gain more insight in the factors and these distinguishing statements may be used for
interpreting the factor (Brown, 1993).
Correlation analysis: Correlation analysis can be used to assess the relation between two variables.
Two most commonly used types of correlation tests are Pearson product-moment correlation and
Spearman’s rho. Pearson product-moment correlation is mostly applied to variables which can be
measured on an interval or ratio scale and Spearman’s rho is mostly applied to variables which can be
measured on a categorical or ordinal scale (Pallant, 2007). Below for both the formula for calculating
the correlation between two variables is presented.
Pearson product-moment correlation:
𝑛 𝑥𝑦 − 𝑥 𝑦
𝑟=
𝑛 𝑥! − 𝑥! 𝑛 𝑦! − 𝑦!

Spearman’s rho:
6 𝑥−𝑦 !
𝑟=
𝑛 𝑛! − 1
Where r represents the correlation, n the sample size, x variable one and y variable two (Baarda &
De Goede, 1999).
A correlation of +1 of -1 can be seen as a ‘perfect’ correlation, since this means that one is able to
exactly determine the value of a variable just by knowing the value of the other correlated variable. A
correlation of 0 means that there is no relationship between both variables. A positive correlation can
be interpreted as follows: in case variable one increases, variable two also increases. A negative
correlation can be interpreted as follows: in case variable one increases, variable two decreases
(Pallant, 2007).
The strength of the correlation can be assessed by using the following guidelines as set up by
Cohen (1988).
• Weak
0,10 ≤ 𝑟 ≤ 0,29
• Medium
0,30 ≤ 𝑟 ≤ 0,49
• Strong
0,50 ≤ 𝑟 ≤ 1,00

128
S Solis Vuurmans
https://t.me/PrMaB
 C. INTERVIEWS DATABASE
NAME JOB TITLE ROLE PROJECT PERSPECTIVE
Aarts, Mark Project manager PM Rotterdam A50 Infra trad
Adriaansens, Didier Project leader PL Various Infra trad
Beek, Lisette van Project leider PM HOV Hilversum Infra Scrum
Blom, Rianne Thesis researcher Advisor Embracing change Infra Scrum
Boukema, Sybren System engineer TM Project Groningen Infra Trad
road
Bouwers, Bart Agile coach SM HOV Hilversum Infra Scrum
Broersma, Louis Process manager PM Various Infra trad
Brookhuis, Bart Technical advisor TM Rijnland route Infra Scrum
Bunnik, Micha Structural engineer TM Road design Infra Trad
Burg, Gerrit-Jan Developer TM Various ICT
van den
Buuren, Coos van Advisor in civil TM Rijnland route Infra Scrum
engineering and
Claessen, Guus Programmer TM GIS ICT
economical models
Clement, Patrick Scrum master and SM HOV Hilversum Infra Scrum
group leader
Culp, Kirsten ICT GIS TM ICT GIS ICT
Davelaar, Hilbert ICT GIS Project leader, SM, HOV Hilversum Infra Scrum
PO
De Kroon, Maurice Project Manager in PL, PO, PM HOV Hilversum, Infra Scrum
several various
Dijkstra, Theo Project engineer PM Connection Infra Trad
infrastructure
Groningen
Donselaar-Gaal, Advisor
projects in water TM Various Infra Trad
Brenda management
Donselaar, Stefan Ext. Advisor TM Various Infra Trad
Drunen, Martijn Infrastructure TM Various Infra Trad
van manager consultant
Egmond, Lotje Environment TM Various Infra Trad
advisor
Everaars, Marc Geotechnical TM Rijnlandroute Infra Scrum
Grimoudo, Marco ICT GIS TM Software ICT
development
Ham, Ferry Department head PL Various Infra trad
‘roads and
Hartigh, Margreet ICT Gis Scrum master Observ program ICT
highways’
Hartman, Joop Project leader PM A2 Maastricht Infra Trad
Heerdink, Judit Contract advisor TM Rijnlandroute Infra Scrum
Heijmans, Erik Water management Personnel manager Infrastructure Infra Traditional
Hendrickx, Harjet Tender advisor TM Various Infra trad
Hertog, Gertjan den ICT Gis TM Observ ICT
Hogenboom, ICT Gis TM Various ICT
Priscilla
Jeukens, Gé Thesis researcher X Failure costs of Infra Scrum
Scrum
Jonge, Willem de Project manager PM Connection Infra Trad
highways and roads Groningen and
Kleinjan, Arnold Geotechnical TM Various
various
advisor
Koeslag, Hans Surroundings TM Various Infra trad
advisor
Korporaal, Erwin Project leader PM Water management Infra Trad

129
S Solis Vuurmans
https://t.me/PrMaB
Kruijs, Tim van de Contract manager TM Train station Infra trad
Kruijs improvement
Kruyt, Claus Technical manager PM Risk analysis of Infra SCRUM
Marte
Kwakkelstein, Mar Project leader PM A16 Dordrecht Infra trad
Lange, Marcel de Developer TM Observ program ICT
Langeveld, Ton van Advisor TM A2 Maastricht Infra Trad
Mertens, Jeff Project leader and PM-SM Various Scrum Infra scrum
scrum certification
Meulblok, Martijn Project leider PM Maastricht tunnel Infra Trad
Morrisson, Kramer Advisor in TM General building Infra trad
department Roads construction
Orlinska, Karolina ICT TM ICT ICT
Ouden, Arjen van Contract manager TM Risk analysis of Infra Scrum
den Marte
Pauw, Hans Wegen PM-PL Delft Spoor zone Infra Traditional
Poel, Hans van der Senior manager PM Rijnlandroute Infra Scrum
Raadgever, Tom Consultant flood TM Risk analysis of Infra SCRUM
safety Marte
Raaijmakers, Ruud Advisor for water TM Water management Infra SCRUM
management projects
Rodenburg, Sjaak Infrastructure, PM Infrastructure Infra Traditional
projects
Energy
Rutten, Nanet Project TM Maximabrug and Infra scrum
management HOV Hilversum
Sintemaartensdijk, Team leader PM Maximabrug Infra Scrum
advisor
Eline van
Slaterus, Rolf Technical advisor TM Rijnlandroute Infra Traditional
Sluis, Jan van der Highway designer TM Maximabrug Infra scrum
Smit, Marti System engineer TM A2 Maastricht Infra Trad
Sprengelmeijer, Programmer TM Observ program ICT
Marco
Tanis, Kees Advisor TM Various Infra trad
Thyssen, Kevin Programmer TM Observ program ICT
Tiemessen, Pieter Advisor TM Various Infra trad
Verver-Bax, Florine Surroundings TM Various Infra trad
advisor
Vliet, Jeroen van Advisor in project TM Various Infra SCRUM
management
Vos, Hans de Programmer TM Observ program ICT
Vreugdenhil, Johan Project leader PM Various Infra Trad
Wesselink, Project manager TM, SM Various Infra scrum
Willemijn
Wicherson, Jurgen Project leader PM Dordrecht Infra trad
connection
Van der Knaap, Scrum master, SM Several scrum Infra scrum
Pieter project manager

130
S Solis Vuurmans
https://t.me/PrMaB
D. INTERVIEWS PROTOCOL

2015_03_05_SE)Interview.docx)
____________________________________________________________________________________________________________)
)

INTERVIEW(QUESTIONS([CODE:(__](
)
Interviewer:) Sebastian)Solis)Vuurmans) Date:) )
Place:) ) Time:) )
)
Introduction(
− Thank)them)for)participating)in)interview)
− Ask)permission)to)record)interview)
− Introduce)myself)
− Explanation)about)the)research)and)its)progress)
− Explanation)why)the)interview)helps)the)research)
− Ask)the)interviewee)to)introduce)him/herself)
)
Goals(
− Exploratory)interview)for)success)assessment)of)infrastructure)projects)
− Map)out)opinions)and)perspectives)regarding)Agile)Project)Management)(and)the)tool)of)
Scrum))
______________________________________________________________________________)
(
Interview(questions(
Interviewee:)
1. Ask)the)interviewee)to)introduce)him/herself)
)
Name:) ) Company:) )
Occupation:) ) Department:) )
Edu)/)Cert:) ) Years)Exp.:) )
APM)project:) ) Responsibility:) )
)
Projects)
2. What)kind)of)projects)do)you)mostly)perform?)(Infrastructure)or)ICT))
3. What)type)of)contract)was)used/delivered?)(Traditional)or)integrated))
Success)
4. Do)you)consider)the)project)successful?)Why?)
5. How)are)these)projects)measured)on)success?)Are)there)KPIs)used?))
6. Do)you)consider)the)use)of)APM)(Scrum))influenced)the)result)of)the)project?)Why?)
7. Do)you)consider)the)use)of)APM)(Scrum))influenced)the)process)of)the)project?)Why?)
8. What)areas)you)consider)to)need)improvement?)Why?)
Problem)
9. What)do)you)consider)to)be)the)most)important)obstacle)faced)on)the)project?)
10. What)was)the)pain)associated?)What)else?)Tell)me)more.)
Process)
11. How)does)the)project)start?)(Initiation))
12. What)phase)the)project)life)cycle)were)you)involved?)
13. How)big)was)the)project)team)involved?)(Number)of)people))
14. Who)makes)the)planning?)And)how)is)the)planning)made?)(Use)of)product)backlog))
15. Roles:)Who)does)what)in)the)team?)
16. What)are)the)different)backgrounds)of)the)team)members?))

) 1)

131
S Solis Vuurmans
https://t.me/PrMaB
2015_03_05_SE)Interview.docx)
____________________________________________________________________________________________________________)
)

Communication)
17. What)is)discussed)during)the)first)meeting?)(Stories))
18. How)often)are)consultations)arranged)during)the)project?)(Daily)stand)ups))
a. How)long)are)those)consultations?)
b. What)is)discussed)during)those)consultations?)
c. During)the)consultations,)do)team)members)indicate)if)they)have)encountered)
problems?)How)are)those)tackled?)
19. Besides)the)consultation,)how)much)intermediate)communication)exists)between)team)
members?)Between)teams/departments?)
20. How)do)you)maintain)contact)with)the)client?)(Product)owner))
21. Do)team)members)also)perform)different)projects)simultaneously)(multitasking)?)
d. What)consequence)does)it)has)for)the)planning?)
e. Who)is)in)charge)of)assess)which)project)takes)priority?)
Scope)
22. What)is)the)level)of)specification)of)the)scope)at)the)beginning)of)most)projects?)
23. And)how)do)you)react?)
a. Do)you)immediately)work)it)out)in)detail)and)make)and)offer?)
b. Or)do)you)first)ask)what)the)real)wishes)are?)Do)you)start)a)dialogue)with)the)
client?)
Change)management)
24. How)often)do)changes)happen?)What)kind)of)changes)occurs?)
a. In)the)assignment)as)formulated)by)the)client?)
b. In)the)team)formation?)
25. How)do)you)cope)with)the)changes?)
Problems)
26. What)are)the)problems)you)frequently)encounter?)
27. How)are)those)problems)usually)solved?)
28. Could)you)name)an)example?)
Lean)and)Agile)knowledge)
29. How)you)ever)heard)of)Lean)construction)and)Agile)Project)Management?)
30. What)tools)have)you)used)of)previously)mentioned)methodologies?)
a. What)where)your)responsibilities?)
b. What)type)of)project)was)it)for?)
c. How)was)the)end)result?))
)
)
______________________________________________________________________________)
)
Closure(
− Ask)the)interviewee)if)he/she)has)any)questions,)comments)or)tips)
− Agreements)
o Anonymity)
o Use)information)from)interview)f)
o Informing)interview)of)research)results)
− Thank)interviewee)
)

) 2)

132
S Solis Vuurmans
https://t.me/PrMaB
E. OVERVIEW OF CSF IN LITERATURE

133
S Solis Vuurmans
https://t.me/PrMaB
 Articles
Master&thesis
Success&in&infrastructure&projects Success&in&ICT
Toor&
Pinto& Pinto& Munns& Belassi& and& BERME van&
Success&Factors
&& && && && Cooke?& Ogunla Lam&et& Chow& JO&et& Misra& Stanko Loenh Wagne
Slevin& de&Wit& Covin& Bjeirmi& Tukel& Davies& Turner& na& al.& &&Cao& al.& et&al.& vic& Coman& out& r&

APM&&RELATED
(1986) (1998) (1989) (1996) (1996) (2001) (2007) (2006)& (2008) (2007) (2014) (2009) (2013) (2014) (2013) (2014)

#&CSF
CODE A B C D E F G H I J K L M N O P
1 A1 Clearly'defined'goals x
2 A2 Competent'project'manager x
3 A3 Top'management'support x
4 A4 Competent'project'team'members x
5 A5 Sufficient'resource'allocation x
6 A6 Adequate'communication'channels x
7 A7 Control'mechanisms x
8 A8 Feedback'capabilities x
9 A9 Responsiveness'to'clients x
10 B10 Realistic'and'thorough'definition'of'project x
11 B11 Efficient'manner'of'project'execution' x
12 B12 Comprehension'of'project''environment'' x
13 B13 Selection'of'organization'realizing'project' x
14 B14 Formulation'of'sound'project'policies' x
15 B15 Clear'and'simple'project'organization' x
16 B16 Selection'of'key'personnel' x
17 B17 Efficient'and'dynamic'management'controls x
18 B18 Reliable'management'information'systems x
19 B19 Planning'effort'(construction) x
20 B20 Planning'effort'(design) x
21 B21 Project'manager'goal'commitment' x
22 B22 Project'team'motivation' x
23 B23 Project'manager'technical'capabilities' x
24 B24 Scope'and'work'definition' x

S Solis Vuurmans
https://t.me/PrMaB
25 C25 Mission'H'Initial'clarity'of'goals'and'general'directions x
Top'man.'Support'H'willingness'of'top'management'to'provide'the'necessary'resources'and'authority/'
x
26 C26 power'for'project'success'
Project'schedule/plans'H'a'detailed'specification'of'the'individual'action'steps'required'fir'project'
x
27 C27 implementation'
28 C28 Client'consultation'H'communication,'consultation,'and'Active'listening'to'all'impacted'parties' x
29 C29 Personnel'H'selection,'recruitement,'and'training'of'the'necessary'personnel'for'the'project'team' x
Technical'tasks'H'availability'of'the'required'technology'and'expertise'to'accomplish'the'specific'technical'
x
30 C30 action'steps'
31 C31 Client'acceptance'H'the'act'of'selling'the'final'project'to'its'ultimate'intended'users' x
Monitoring'and'feedback'H'timely'provision'of'comprehensive'control'information'at'each'stage'in'the'
x
32 C32 Implementation'process'
Communication'H'The'provision'of'an'appropriate'network'and'necessary'data'to'all'key'actors'in'the'
x
33 C33 project'implementation'
34 C34 TroubleHshooting'H'the'ability'yo'handle'unexpected'crises'and'deviations'from'plan' x
Characteristics'of'the'project'team'leader'H'competence'of'the'project'leader'(administratively,'
x
35 C35 interpersonally,'and'technically)'and'the'amount'of'authority'available'to'perform'his/her'duty'
Power'and'politics'H'the'degree'of'political'activity'within'the'organization'and'the'perception'of'the'project'
x
36 C36 as'furthering'an'organization'member's'selfHinterests'

134
 Environmental'effectsthe'likelihood'of'external'organizational'or'environmental'factors'impacting'on'the'
x
37 C37 operations'of'the''project'team,'positively'or'negatively'
Urgency'H'the'perception'of'the'importance'of'the'project'or'the'need'to'implement'the'project'as'soon'as'
x
38 C38 possible
39 D39 Having'the'right'person'as'project'manager x
40 D40 Realistic'goal x
41 D41 Commitment'to'the'project x
42 D42 Adequate'basis'to'the'project x
43 D43 Availability'of'project'management'techniques x
44 D44 Planned'project'closedown x
45 D45 Good'defined'tasks x
46 D46 Having'competition x
47 D47 Client'satisfaction x
48 D48 Having'profitability x
49 D49 Third'parties x
50 D50 Market'availability x
51 D51 Implementation'process x
52 E52 Ability'of'project'manager x
53 E53 Ability'of'team'members x
54 E54 Project'size'and'value x
55 E55 Organization'measures x
56 E56 Client'consultation'and'acceptance x
57 E57 Project'managers'performance x
58 E58 Project'preliminary'estimates x
59 E59 Availability'of'resources x
60 E60 External'enviroment x
61 F61 Adequacy'of'companyHwide'education'on'the'concepts'of'risk'management. x
62 F62 Maturity'of'an'organisation’s'processes'for'assigning'ownership'of'risks. x
63 F63 Adequacy'with'which'a'visible'risk'register'is'maintained. x
64 F64 Adequacy'of'an'up'to'date'risk'management'plan x
Adequacy'of'documentation'of'organisational
x
65 F65 responsibilities'on'the'project.

S Solis Vuurmans
https://t.me/PrMaB
66 F66 Keep'project'(or'project'stage'duration)'as'far'below'3'years'as'possible'(1'year'is'better).' x
67 F67 Allow'changes'to'scope'only'through'a'mature'scope'change'control'process.' x
68 F68 Maintain'the'integrity'of'the'performance'measurement'baseline.' x
The'existence'of'an'effective'benefits'delivery'and'management'process'that'involves'the'mutual'coH
x
69 F69 operation'of'project'management'and'line'management'functions.'
PortfolioH'and'programme'management'practices'that'allow'the'enterprise'to'resource'fully'a'suite'of'
x
70 F70 projects'that'are'thoughtfully'and'dynamically'matched'to'the'corporate'strategy'and'business'objectives.'
A'suite'of'project,'programme'and'portfolio'metrics'that'provides'direct'‘‘line'of'sight’’'feedback'on'current'
project'performance,'and'anticipated'future'success,'so'that'project,'portfolio'and'corporate'decisions'can' x
71 F71 be'aligned.'
72 F72 An effective means of ‘‘learning from experience’’ on projects x
73 G73 Project'mission x
74 G74 Top'management'support x
75 G75 Schedule'and'plans x
76 G76 Client'consultation x
77 G77 Personnel x
78 G78 Technical'tasks x
79 G79 Client'acceptance x
80 G80 Monitoring'and'feedback x

135
 81 G81 Communication x
82 G82 TroubleHshooting' x
83 H83 Competent'project'manager' x
84 H84 Competent'team'members' x
85 H85 Building'a'balanced'and'winning'team' x
86 H86 Regular'client'consultation' x
87 H87 Responsiveness'of'client' x
88 H88 Knowing'what'client'really'wants' x
89 H89 Clear'prioritization'of'project'goals'by'the'client' x
90 H90 Client'acceptance'of'plans' x
91 H91 Awarding'bids'to'the'right'designers/contractors' x
92 H92 HighHquality'workmanship' x
93 H93 Top'management'sponsorship' x
94 H94 Proven'methodology'(that'includes'a'vision'process)'of'project'management'and'project'procurement' x
95 H95 Effective'project'planning'and'control' x
96 H96 Effective'change'management' x
97 H97 Sufficient'resources' x
98 H98 Clearly'written'lines'of'responsibility' x
99 H99 Clear'and'detailed'written'contract' x
100 H100 Proper'dispute'resolution'clauses'incorporated'in'the'contract' x
101 H101 Developing'positive'friendly'relationships'with'project'stakeholders' x
102 H102 Clearly'defined'goals'and'priorities'of'all'stakeholders' x
103 H103 Strategic'alignment'of'project'goals'with'stakeholders’'interests' x
104 H104 Adequate'communication'among'related'parties' x
105 H105 Mutual'trust'among'project'stakeholders' x
106 H106 Frequent'meetings'among'various'stakeholder'to'evaluate'overall'performance' x
107 H107 Absence'of'bureaucracy'from'the'work'place' x
108 H108 Learning'from'previous'experiences' x
109 H109 Reliable'estimates'by'quantity'surveyors' x
110 H110 Positive'organizational'culture'for'effective'project'management' x
111 H111 Requiring'the'use'of'facts'and'data'to'support'actions'at'all'levels'of'decision'making x
112 H112 Feedback'capabilities'in'the'system' x

S Solis Vuurmans
https://t.me/PrMaB
113 H113 Benchmarking'firm’s'performance'against'successful'projects' x
114 H114 Conducting'regular'reviews'to'assure'and'verify'progress'on'project' x
115 H115 Effective'project'control'mechanics' x
116 H116 Fast'troubleHshooting'capabilities'in'the'system' x
117 H117 Creating'accountabilities,'expectations,'roles,'and'responsibilities'for'he'organization x
118 H118 Adequate'work'breakdown'structure'(WBS)'linked'with'organizational'breakdown'structure'(OBS) x
119 H119 Clearly'designed'and'coordinated'technical'tasks' x
120 H120 Standard'software'infrastructure'and'adequate'use'of'IT' x
121 H121 Using'up'to'date'technology'and'automation'for'construction'work' x
122 I122 Time'and'cost x
123 I123 financial'performance x
124 I124 Safety x
125 I125 Quality x
126 I126 Meeting'technical'performance'specifications x
127 I127 Goal'attainment x
128 I128 Completion x
129 I129 Productivity x
130 I130 Satisfaction'of'stakeholders x
131 I131 Expectations'of'client x

136
 132 I132 Conflict'management x
133 I133 Legal'claims x
134 I134 Profesional'image x
135 I135 Aesthetics x
136 I136 Educational,'social'and'professional'aspects x
137 I137 Environmental'sustainability x
138 J138 Management'commitment x
139 J139 Organization'environment x
140 J140 Team'environment x
141 J141 Team'capability x
142 J142 Customer'involvement x
143 J143 Project'management'process' x
144 J144 Project'definition'process' x
145 J145 Agile'software'techniques' x
146 J146 Delivery'strategy' x
147 J147 Project'nature' x
148 J148 Project'type' x
149 J149 Project'schedule' x
150 K150 Team'capacity x
151 K151 Success'in'software'development x
152 K152 Relationship'with'external'partners x
153 K153 Culture x
154 K154 Communication'with'the'customer x
155 K155 Environmental'configuration x
156 L156 Customer'satisfaction x
157 L157 Customer'Collaboration x
158 L158 Customer'Commitment' x
159 L159 Decision'Time' x
160 L160 Team'Distribution' x
161 L161 Team'Size' x
162 L162 Corporate'Culture' x
163 L163 Planning' x

S Solis Vuurmans
https://t.me/PrMaB
164 L164 Control x
165 L165 Competency x
166 L166 Personal'Characteristics' x
167 L167 Communication'&'Negotiation' x
168 L168 Societal'Culture' x
169 L169 Training'&'Learning' x
170 M170 Strong'executive'support x x
171 M171 Committed'sponsor'or'manager x x
172 M172 Cooperative'organizational'culture'instead'of'hierarchical x x
173 M173 Oral'culture'placing'high'value'on'faceHtoHface'communication x x
174 M174 Organizations'where'agile'methodology'is'universally'accepted x x
175 M175 Collocation'of'the'whole'team x x
176 M176 Facility'with'proper'agileHstyle'work'environment x x
177 M177 Rewards'system'apropriate'for'agile' x x
178 M178 Team'members'with'high'competence'and'expertise' x x
179 M179 Team'members'with'great'motivation' x x
180 M180 Managers'knowledgeable'in'agile'process' x x
181 M181 Managers'who'have'lightHtouch'or'adaptive'management'style x x
182 M182 Coherent,'selfHorganizing'teamwork x x

137
 183 M183 Good'customer'relationship' x x
184 M184 Following'agileHoriented'requirement'management' x x
185 M185 Following'agileHoriented'project'management'process' x x
186 M186 Following'agileHoriented'configuration'management'process x x
187 M187 Strong'communication'focus'with'daily'faceHtoHface'meetings' x x
188 M188 Honoring'regular'working'schedule–no'overtime' x x
189 M189 Strong'customer'commitment'and'presence x x
190 M190 Customer'having'full'authority' x x
191 M191 WellHdefined'coding'standards'up'front' x x
192 M192 Pursuing'simple'design' x x
193 M193 Rigorous'refactoring'activities x x
194 M194 Right'amount'of'documentation x x
195 M195 Regular'delivery'of'software x x
196 M196 Delivering'most'important'features'first' x x
197 M197 Correct'integration'testing x x
198 M198 Appropriate'technical'training'to'team' x x
199 M199 Project'nature'being'nonHlifeHcritical x x
200 M200 Project'type'being'of'variable'scope'with'emergent'requirement x x
201 M201 Projects'with'dynamic,'accelerated'schedule' x x
202 M202 Projects'with'small'team x x
203 M203 Projects'with'no'multiple'independent'teams' x x
204 M204 Projects'with'upHfront'cost'evaluation'done' x x
205 M205 Projects'with'upHfront'risk'analysis'done' x x
206 N206 Continuation'of'client'organisation x x
207 N207 Delivered'on'time x x
208 N208 Effect'on'the'professional'image'of'client'organisation x x
209 N209 Efficient'use'of'the'available'resources x x
210 N210 Fit'for'purpose x x
211 N211 Good'working'relationship'with'contracting'partners x x
212 N212 Impact'on'the'environment,'sustainability x x
213 N213 Learning'opportunities'for'client'organisation x x
214 N214 Personal'growth'and'development x x
215 N215 Profitability'for'contractor x x

S Solis Vuurmans
216 N216 Project'specific'political'or'social'factors x x

https://t.me/PrMaB
217 N217 Quality x x
218 N218 Right'process'is'followed x x
219 N219 Safety x x
220 N220 Satisfies'needs'of'project'team x x
221 N221 Satisfies'needs'of'shareholders x x
222 N222 Satisfies'needs'of'stakeholders x x
223 N223 Satisfies'needs'of'users x x
224 N224 Within'budget'''' x x
225 P225 Risks'addressed,'assessed'and'managed x
226 P226 Client'involvement'into'the'process x
227 P227 Competent'project'manager;'Hard'competences:'project'experience'and'technical'knowledge x
228 P228 Competent'project'manager;'Soft'competences:'leadership,'motivation,'involvement'and'flexibility x
229 P229 Collaborative'team'culture'within'the'project'teams x
230 P230 Collaborative'team'culture'between'the'project'teams x
231 P231 Well'defined'project'scope x
232 P232 Effective'and'dynamic'monitoring'and'control x
233 P233 Effective'organizational'structure x

138
 234 P234 Thorough'preHqualifications'for'potential'bidders x
235 P235 Appropiate'project'procurement'system x
236 P236 Good'communication'and'feedback:'communication'within'the'project'teams x
237 P237 Good'communication'and'feedback:'communication'with'stakeholders x
238 P238 Good'communication'and'feedback:'communication'between''client'and'contractor x
239 P239 Good'communication'and'feedback:'feedback'from'the'client'to'the'contractor x
240 P240 Good'communication'and'feedback:'feedback'from'the'contractor'to'the'client x
241 P241 Clarity'on'client's'requirements x
242 P242 Comprehension'of'the'project'environment x
243 P243 Quick'conflict'resolution'within''the'project'teams x
244 P244 Quick'conflict'resolution'between'the'project'teams x
245 P245 Aiming'for'an'equal'relationship'between'client'and'contractor x
246 P246 Minimal'governmental'interference x
247 P247 Support'from'senior'management x
248 P248 Fully'complete'design'specifications'/'no'scope'changes x
249 P249 Client'and'contractor'have'a'common'goal x
250 P250 Open'and'transparent'project'team'culture'within'the'project'team x
251 P251 Open'and'transparent'project'team'culture'between'project'teams x
252 P252 Past'experience'of'the'contractor:'comparable'project'typology x
253 P253 Past'experience'of'the'contractor:'working'with'the'same'procurement'method x
254 P254 Past'experience'of'the'contractor:'working'with'techniques'used'previously x
255 P255 Strong'business'case'and'sound'basis'for'project x
256 P256 Strong'and'detailed'plan'is'kept'up'to'date x
257 P257 Adequate'budget x
258 P258 Sufficient'skilled'project'team'members x
259 P259 Sufficient'and'well'allocated'resources x
260 P260 Personal'friendships'between'individuals'in'the'project'team x

S Solis Vuurmans
https://t.me/PrMaB
139
 Success&in&infrastructure&projects Success&in&ICT Success&in&master&thesis

Munns& BERME
Pinto&&& Pinto&&& && Belassi&&& Lam&et& Chow& JO&et& Misra&
Slevin& de&Wit& Covin& Bjeirmi& Tukel& Cooke?&Davies& Turner& Toor&and& al.& &&Cao& al.& et&al.& van&Loenhout& Wagner&
(1986) (1998) (1989) (1996) (1996) (2001) (2007) Ogunlana&(2006)& (2008) (2007) (2014) (2009) Stankovic&(2013) Coman&(2014) (2013) (2014)

Count
38 A B C D E F G H I J K L M N O P
a.&Related&to&project&manager
1 HA1 Competent(project(manager(( 9 A2 B23 D39 E52,(E57 G77 H83 L165 M181 P227,(P228
2 HA2 Commitment(of(project(manager 3 B21 D41 L166
3 HA3 Technical(background 3 C35 D43 M180

b.&Related&to&team&members
1 HB1 Competent(team(members 10 A4 B16 C29 E53 G77 H84 J141 L165 M178 P258
2 HB2 Commitment 6 B22 D41 J140 L166 M179 P260
3 HB3 Technical(background 2 H110 M178,(M198
4 HB4 Self(guided(teams 3 H85 L160 M182
5 HB5 Size(of(team 3 K150 L161 M175,(M202

c.&Related&to&project
1 HC1 Definition(of(goals 9 A1 B10,(B24 C25 D40 E54 G73 H89 I126 P231
2 HC2 Definition(of(budget 6 D48 E54 I122 N220 N220 P257
3 HC3 Definition(of(schedule 9 B19,(B20 C27 H95 I122 J149 L163 M188,(M201,(M207 N215 N215
4 HC4 Definition(of(value 3 I125 N217,(N224 N217,(N224
5 HC5 Adequate(communication 7 A6 C33 G81 H104 L167 M173 P236,(P240
6 HC6 Adequate(control 5 A7 B17 H95,(H115 L164 P232
7 HC7 Safety 3 I124 N219 N219
8 HC8 Risk(management 3 F61,(F62,(F63,(F64 M205 P225
9 HC9 Documentation(of(procedures 3 B18 F65 M194
10 HC10 Interchange(of(knowledge( 3 F72 L169 P229,(P230
11 HC11 Adecuate(monitoring(and(feedback 4 A8 C32 G80 H112
12 HC12 Adequate(troubleXshooting 4 C34 G82 H116 I132
13 HC13 Urgency 1 C38

d.&Related&to&organization
1 HD1 Top(management(support 6 A3 C26 H93 J138 M171,(M170 P247

S Solis Vuurmans
2 Organizational(structure C36 E55 F69 J139 M172,(M174 P233

https://t.me/PrMaB
HD2 6

e.&Related&to&client
1 HE1 Client(participation 10 A9 C28 E56 H86 I131 J142 K154 L157 M189,(M190 P226,(P238
2 HE2 Client(acceptance/safistaction 6 C31 D47 E56 G79 H88,(H90 L156
3 HE3 Client(commitment 4 C28 H87 L158 M189

F.&Related&to&resources&(human,&
facilities,&financial)
1 HF1
2 HF2
Eficient(resource(allocation( 4 E59 H97 M175,(M209 P259
Eficient(resource(satisfaction 1 M175,(M209
F. CLUSTERING OF CSF TO DEFINE Q-SET

3 HF3 Eficient(resource(alligment 1 M185,(M209

G.&Related&project&management&
techniques&(APM)
1 HG1 Daily(standups 2 H106,(H114 M187
2 HG2 Product(backlog( 3 B10,(B24 H89,(H109 J144
3 HG3 Retrospectives 1 H108,(H114
4 HG4 Division(of(roles 1 H98,(H117
5 HG5 Required(software( 3 F71 H120 J145

H.&Related&external&environment
1 HH1 Competition 3 D46 E60 M208
2 HH2 Economical 1 E60
3 HH3 Third(parties 6 C37 D49 E60 K152 N216,(N222 N216,(N222
4 HH4 Stakeholder(satisfaction 4 H101,(H102,(H103 I130 N221,(N222,(N223 N221,(N222,(N223

140
G. Q SORTING QUESTIONNAIRE

Figure 6-8 | Step one of questionnaire: the profiling

141
S Solis Vuurmans
https://t.me/PrMaB
Figure 6-9 | Step two of questionnaire: the overview of 38 CSF.

142
S Solis Vuurmans
https://t.me/PrMaB
Figure 6-10 | Step three of questionnaire: the quantification of importance.

143
S Solis Vuurmans
https://t.me/PrMaB
H. Q SORT FACTOR RESULTS FOR THE FOUR
PERSPECTIVES
Table 6-1 | Correlation matrix between sorts

144
S Solis Vuurmans
https://t.me/PrMaB
Table 6-2 | Un rotated factor matrix

145
S Solis Vuurmans
https://t.me/PrMaB
Table 6-3 | Cumulative communalities matrix

146
S Solis Vuurmans
https://t.me/PrMaB
Table 6-4 | Factor matrix with an X indicating defining sort

147
S Solis Vuurmans
https://t.me/PrMaB
 I. ANALISIS WITH AGILE SAMPLE
Table 6-5 | Factor matrix with an X indicating defining sort for two perspectives

QS ORT 1 2
1 Resp_01 0.6400X 0.3728
2 Resp_02 0.5112X 0.3807
3 Resp_03 0.7402X 0.3204
4 Resp_04 0.5987X 0.345
5 Resp_05 0.5811X 0.4883
6 Resp_06 0.5837 0.6280X
7 Resp_07 0.6335X 0.1398
8 Resp_08 0.2128 0.7804X
9 Resp_09 0.3709 0.6172X
10 Resp_10 0.3861 0.7291X
11 Resp_11 0.5894X 0.3086
12 Resp_12 0.0825 0.6785X
13 Resp_13 0.7185X 0.2086
14 Resp_14 0.2302 0.5593X
15 Resp_15 0.6928X -0.0028
16 Resp_16 0.6820X 0.1155
17 Resp_17 0.6814X 0.257
18 Resp_18 0.3886 0.4444X
19 Resp_19 0.6794X 0.4605
20 Resp_20 -0.042 0.6025X
21 Resp_21 0.5349X 0.0652

% expl.Var. 30 21

Table 6-6 | Correlation for two perspectives

1 2
1 1 0.683
2 0.683 1

148
S Solis Vuurmans
https://t.me/PrMaB
 Table 6-7 | Factor matrix with an X indicating defining sort for three perspectives

QS ORT 1 2 3
1 Resp_01 0.5931X 0.2237 0.4019
2 Resp_02 0.4221 -0.0318 0.7285X
3 Resp_03 0.6987X 0.1947 0.3671
4 Resp_04 0.5880X 0.408 0.1127
5 Resp_05 0.562 0.5392 0.1744
6 Resp_06 0.5338 0.5295 0.4149
7 Resp_07 0.6054X 0.0401 0.2589
8 Resp_08 0.1697 0.7471X 0.3333
9 Resp_09 0.3173 0.4817 0.4313
10 Resp_10 0.3294 0.6069X 0.4538
11 Resp_11 0.5548X 0.2146 0.3023
12 Resp_12 -0.0203 0.2437 0.8013X
13 Resp_13 0.6644X -0.0262 0.4678
14 Resp_14 0.1409 0.1809 0.7076X
15 Resp_15 0.7068X 0.1187 -0.0675
16 Resp_16 0.6726X 0.1265 0.1137
17 Resp_17 0.6724X 0.3099 0.1071
18 Resp_18 0.3992 0.6548X -0.072
19 Resp_19 0.6442X 0.41 0.3091
20 Resp_20 -0.0504 0.7186X 0.047
21 Resp_21 0.5325X 0.0966 0.0511

% expl.Var. 27 16 15

Table 6-8 | Correlation for three perspectives

1 2 3
1 1 0.5517 0.5055
2 0.5517 1 0.4456
3 0.5055 0.4456 1

149
S Solis Vuurmans
https://t.me/PrMaB