The symbiosis between information system project complexity and information system project success
Item
Title
The symbiosis between information system project complexity and information system project success
Creator
Marnewick, Carl
Erasmus, Wikus
Nazeer, Joseph
Date
2017
Publisher
AOSIS
Description
Project success is widely covered, and the discourse on project complexity is proliferating. The purpose of this book is to merge and investigate the two concepts within the context of information system (IS) projects and understand the symbiosis between success and complexity in these projects. In this original and innovative research, exploratory modelling is employed to identify the aspects that constitute the success and complexity of projects based on the perceptions of IS project participants. This scholarly book aims at deepening the academic discourse on the relationship between the success and complexity of projects and to guide IS project managers towards improved project performance through the complexity lens. The research methodology stems from the realisation that the complexity of IS projects and its relationship to project success are under-documented. A post positivistic approach is applied in order to accommodate the subjective interpretation of IS-project participants through a quantitative design. The researchers developed an online survey strategy regarding literature concerning the success and complexity of projects. The views of 617 participants are documented. In the book, descriptive statistics and exploratory factor analysis pave the way for identifying the key success and complexity constructs of IS projects. These constructs are used in structural-equation modelling to build various validated and predictive models. Knowledge concerning the success and complexity of projects is mostly generic with little exposure to the field of IS project management. The contribution to current knowledge includes how the success of IS projects should be considered as well as what the complexity constructs of IS projects are. The success of IS projects encompasses strategic success, deliverable success, process success and the ‘unknowns’ of project success. The complexity of IS projects embodies organisational complexity, environmental complexity, technical complexity, dynamics and uncertainty. These constructs of success and complexity are mapped according to their underlying latent relationships to each other. The intended audience of this book is fellow researchers and project and IS specialists, including information technology managers, executives, project managers, project team members, the project management office (PMO), general managers and executives that initiate and conduct project-related work. The work presented in this first edition of the book is original and has not been plagiarised or presented before. It is not a revised version of a thesis or research previously published. Comments resulted from the blind peer review process were carefully considered and incorporated accordingly
Subject
Computer Science
Language
English
isbn
9781928396253
content
The symbiosis between
information system
project complexity and
information system
project success
Head Office
AOSIS (Pty) Ltd
Postnet Suite #110
Private Bag X19
Durbanville 7551
South Africa
Tel: +27 21 975 2602
Fax: +27 21 975 4635
Email: info@aosis.co.za
Website: http://www.aosis.co.za
© Carl Marnewick, Wikus Erasmus & Nazeer Joseph 2017. Licensee: AOSIS (Pty) Ltd
The moral rights of the authors have been asserted.
First Edition published in 2017
Impression: 1
Listed in OAPEN (http://www.oapen.org), DOAB (http://www.doabooks.org/) and indexed
by Google Scholar.
Some rights reserved. This is an open access publication. Except where otherwise noted, this
work is distributed under the terms of a Creative Commons Attribution-NonCommercialShareAlike 4.0 International license (CC BY-NC-SA 4.0), a copy of which is available at https://
creativecommons.org/licenses/by-nc-sa/4.0/.
Enquiries outside the terms of the Creative Commons license should be sent to the Rights
Department, AOSIS, at the above address or to publishing@aosis.co.za
Published in South Africa by AOSIS (Pty) Ltd, 15 Oxford Street, Durbanville, Cape Town,
7550.
Book Title: The symbiosis between information system project complexity and information
system project success
ISBN: 978-1-928396-25-3 (pdf)
ISBN: 978-1-928396-26-0 (e-book)
DOI: https://doi.org/10.4102/aosis.2017.itpsc45
How to cite this work
Marnewick, C., Erasmus, W. & Joseph, N., 2017, The symbiosis between information system
project complexity and information system project success, AOSIS, Cape Town.
Printed and bound in South Africa
This cover photo was provided under the CC0 (https://creativecommons.org/choose/
zero), via Pixabay
The publisher accepts no responsibility for any statement made or opinion expressed in this
publication. Consequently, the publishers and copyright holder will not be liable for any loss or
damage sustained by any reader as a result of his or her action upon any statement or opinion in
this work. Links by third party websites are provided by AOSIS in good faith and for information
only. AOSIS disclaims any responsibility for the materials contained in any third party website
referenced in this work.
Every effort has been made to protect the interest of copyright holders. Should any
infringement have occurred inadvertently, the publisher apologises and undertakes to
amend the omission in the event of a reprint.
The symbiosis between
information system
project complexity and
information system
project success
Carl Marnewick
Wikus Erasmus
Nazeer Joseph
Social Sciences, Humanities, Education & Business
Management Domain Editorial Board at AOSIS
Chief Editor: Scholarly Books
Andries van Aarde, Post Retirement Professor in the Dean’s Office, Faculty of
Theology, University of Pretoria, South Africa
Board Members
Jan Botha, Professor in the Centre for Research on Evaluation, Science and
Technology (CREST), University of Stellenbosch, South Africa
Joan Hambidge, Deputy Dean at the Faculty of Humanities for the University of
Cape Town & Professor for the School of Languages and Literatures, South Africa
Sakari Häkkinen, Dean of the Diocese of Kuopio, Finland
Glenna Jackson, Associate Editor, Professor Chair, Department of Religion and
Philosophy, Otterbein University, Westerville, OH, United States
Gregory C. Jenkins, Dean-elect, St George’s College, Jerusalem, Israel
Reina-Marie Loader, Director and Filmmaker, CinémaHumain, Vienna, Austria
Babita Marthur-Helm, Senior Lecturer Organisational Transformation &
Development; Managing Diversity Gender Empowerment, University of
Stellenbosch Business School, Stellenbosch, South Africa
Christopher Mbazira, Professor of Law & Coordinator of the Public Interest Law
Clinic (PILAC), Makerere University, Kampala, Uganda
Piet Naudé, Professor Ethics related to politics, economics and business &
Director, University of Stellenbosch Business School, Stellenbosch, South Africa
Charles Neill, Professor Department of Business Administration, The British
University in Egypt, El Sherouk, Cairo Governorate, Egypt
Cornelia Pop, Full professor at the Department of Business, Faculty of Business,
Babes-Bolyai University, Cluj-Napoca, Romania
Michael Schratz, Professor, Institut für LehrerInnenbildung und Schulforschung,
Dekan der School of Education, Leopold-Franzens-Universität Innsbruck, Austria
Johann Tempelhoff, Professor, Research Niche for Cultural Dynamics of Water
(CuDyWat), School of Basic Sciences, Vaal Triangle Campus of North-West
University, Vanderbijlpark, South Africa
Anthony Turton, Professor Centre for Environmental Management & Director
TouchStone Resources, University of Free State, South Africa
Willie L. van der Merwe, Professor & Chair Philosophy of Religion, Apologetics
and Encyclopaedia of theology & Professor Extraordinary Stellenbosch University,
South Africa, Vrije Universiteit Amsterdam, Amsterdam, the Netherlands
Christi van der Westhuizen, Associate Professor, Department of Sociology,
Faculty of Humanities, University of Pretoria, South Africa
Joke van Saane, Professor, Amsterdam Center for the Study of Lived Religion,
Vrije Universiteit Amsterdam, the Netherlands
Paul van Tongeren, Professor Department Philosophy, Radboud University
Nijmegen, the Netherlands
Robert G. Varady, Deputy Director and Research Professor of Environmental Policy,
Udall Center for Studies in Public Policy, The University of Arizona, Tucson, AZ
Anné H. Verhoef, Associate Editor, Professor, Faculty of Arts: School of
Philosophy, North-West University, Potchefstroom, South Africa
Xiao Yun Zheng, Professor & Assistant President of Yunnan Academy of Social
Sciences (YASS) and Director International Center for Ecological Culture Studies
(ICECS-YASS), Yunnan Academy of Social Sciences, Kunming City, China
Peer Review Declaration
The Publisher (AOSIS) endorses the South African ‘National Scholarly Book Publishers
Forum (NSBPF) Best Practice for Peer Review of Scholarly Books’. The manuscript
was subjected to rigorous two-step peer review prior to publication, with the identities
of the reviewers not revealed to the author(s). The reviewers were independent of
the publisher and/or authors in question. The reviewers commented positively on
the scholarly merits of the manuscript, and recommended that the manuscript be
published. Where the reviewers recommended revision and/or improvements to the
manuscript, the authors responded adequately to such recommendations.
Research Justification
Project success is widely covered, and the discourse on project complexity
is proliferating. The purpose of this book is to merge and investigate the two
concepts within the context of information system (IS) projects and understand
the symbiosis between success and complexity in these projects. In this original
and innovative research, exploratory modelling is employed to identify the
aspects that constitute the success and complexity of projects based on the
perceptions of IS project participants. This scholarly book aims at deepening the
academic discourse on the relationship between the success and complexity of
projects and to guide IS project managers towards improved project performance
through the complexity lens.
The research methodology stems from the realisation that the complexity of
IS projects and their relationship to project success are under-documented. A
post-positivistic approach is applied in order to accommodate the subjective
interpretation of IS-project participants through a quantitative design. The
researchers developed an online survey strategy regarding literature concerning
the success and complexity of projects. The views of 617 participants are
documented. In the book, descriptive statistics and exploratory factor analysis
pave the way for identifying the key success and complexity constructs of IS
projects. These constructs are used in structural-equation modelling to build
various validated and predictive models.
Knowledge concerning the success and complexity of projects is mostly generic
with little exposure to the field of IS project management. The contribution to
current knowledge includes how the success of IS projects should be considered
as well as what the complexity constructs of IS projects are. The success of IS
projects encompasses strategic success, deliverable success, process success
and the ‘unknowns’ of project success. The complexity of IS projects embodies
organisational complexity, environmental complexity, technical complexity,
dynamics and uncertainty. These constructs of success and complexity are
mapped according to their underlying latent relationships to each other.
The intended audience of this book is fellow researchers and project and IS
specialists, including information technology managers, executives, project
managers, project team members, the project management office (PMO), general
managers and executives that initiate and conduct project-related work.
The work presented in this first edition of the book is original and has not been
plagiarised or presented before. It is not a revised version of a thesis or research
previously published. Comments resulting from the blind peer review process
were carefully considered and incorporated accordingly.
Prof. Carl Marnewick, Wikus Erasmus & Nazeer Joseph
Department of Applied Information Systems
University of Johannesburg
South Africa
Contents
Abbreviations appearing in the Text and Notes x
List of Tables
xi
List of Figures
xiii
Notes on Contributors
xv
Chapter 1
Introduction
1
Investment in information technology
1
Value of IT
3
IS project success rates
6
Strategic alignment of IT
9
Types of IS projects
10
Infrastructure 10
Customisation 11
Integration 11
System implementation (full)
11
System implementation (upgrade)
12
Method of implementation
12
Waterfall model
12
Agile approach
13
Research methodology
15
Book layout
16
Chapter 2
Demystifying project success
18
The evolution of success
20
Project outcomes
21
Success and failure
25
Outcome influencers
27
Project success
27
Product success
28
Organisational benefit
29
Conclusion 32
vii
Contents
Chapter 3
Complexity of information system projects 33
The concept of project complexity
34
Complexity model for new development products
34
Novelty, Technology, Complexity and Pace model
36
Project Complexity Model
37
Information systems development projects
complexity model
39
Constituents of project complexity
41
Organisational complexity
42
Technical complexity
52
Environmental complexity
54
Uncertainty 57
Dynamics 59
Conclusion 60
Chapter 4
I nsights into information system project
success
62
General information
63
Project success
66
Process success
66
Project success
68
Deliverable or product success
70
Business success
73
Strategic success
75
Overall IT project success
76
Conclusion 80
Chapter 5
I nsights into information system
project complexity
Information system project complexity features
Organisational complexity
Technical complexity
viii
81
82
82
85
Contents
Environmental complexity
87
Dynamics 90
Uncertainty 93
Overall complexity view
95
Conclusion 99
Chapter 6
ymbiosis between IS project
S
success and complexity
100
Conceptualising the symbiosis between information
system project success and complexity
100
Development and analysis of IS project
success models
104
Overall results
105
Results for Waterfall projects
111
Results for Agile projects
114
Development and analysis of IS project
complexity models
116
Organisational complexity and project success
118
Environmental complexity
119
Technical complexity, dynamics and uncertainty
126
Overall exploratory factor analysis modelling of
technical complexity, dynamics and uncertainty
126
Conclusion 135
Chapter 7
Simple, complicated, complex and chaos
137
Appendix 141
References 144
Index
156
ix
Abbreviations appearing
in the Text and Notes
EFA
Exploratory Factor Analysis
HSSE
Health, Safety, Security and Environment
ISDP
Information System Development Project
IS
Information System
IT
Information Technology
KMO Kaiser-Meyer-Olkin
NPD
New Product Development
NTCP
Novelty, Technology, Complexity and Pace
PCM
Project Complexity Model
®
PMBOK A Guide to the Project Management Body of
Knowledge
x
List of Tables
Table 1.1: Information technology spending world.
2
Table 1.2: Information technology waste – worldwide. 8
Table 1.3: Information technology waste –
South Africa.
9
Table 4.1: Cost and time comparison: Agile
versus Waterfall.
70
Table 4.2: Overall information technology
project success rates.
79
Table 5.1: Organisational complexity top five
complexity features (Overall).
82
Table 5.2: Organisational complexity top five
complexity features (Agile).
83
Table 5.3: Organisational complexity top five
complexity features (Waterfall).
84
Table 5.4: Technical complexity top five complexity
features (Overall).
85
Table 5.5: Technical complexity top five complexity
features (Agile).
86
Table 5.6: Technical complexity top five complexity
features (Waterfall).
87
Table 5.7: Environmental complexity top five
complexity features (Overall).
88
Table 5.8: Environmental complexity top five
complexity features (Agile).
89
Table 5.9: Environmental complexity top five
complexity features (Waterfall).
90
Table 5.10: Dynamics top six complexity features
(Overall). 91
Table 5.11: Dynamics top six complexity
features (Agile).
92
Table 5.12: Dynamics top six complexity
features (Waterfall).
92
Table 5.13: Uncertainty top five complexity
features (Overall).
93
Table 5.14: Uncertainty top five complexity
features (Agile).
94
xi
List of Tables
Table 5.15: Uncertainty top five complexity
features (Waterfall).
Table 5.16: Top five and bottom five complexity
features across all construct.
Table 5.17: Top five and bottom five complexity
features across all constructs (Agile).
Table 5.18: Top five and bottom five complexity features
across all constructs (Waterfall).
Table 6.1: Overall factor loadings with Pattern Matrix.
Table 6.2: Model fit data for Overall model for
project success.
Table 6.3: Factors for project success with a
Pattern Matrix (Waterfall).
Table 6.4: Model fit for Waterfall project
success mode.
Table 6.5: Factors for Agile project success.
Table 6.6: Agile model fit measurements.
Table 6.7: Environmental complexity exploratory
factor analysis Patten Matrix.
Table 6.8: Environmental complexity exploratory
factor analysis Patten Matrix (Agile).
Table 6.9: Environmental complexity exploratory
factor analysis Patten Matrix (Waterfall).
Table 6.10: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix.
Table 6.11: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix (Agile).
Table 6.12: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix (Waterfall).
xii
95
96
97
98
106
110
112
114
115
118
120
122
124
127
130
133
List of Figures
Figure 1.1: Information technology services
spending – South Africa.
Figure 1.2: Information technology value framework.
Figure 1.3: International information system
project success rates.
Figure 1.4: South African information system
project success rates.
Figure 1.5: Waterfall model.
Figure 2.1: South African and global information
system project success rates.
Figure 2.2: Five levels of project success.
Figure 2.3: Project outcome and portfolio,
programme and project management.
Figure 2.4: Information technology enabled
operational transformation.
Figure 3.1: Overview of the components of
project complexity (derived from
content analysis).
Figure 4.1: Job description.
Figure 4.2: Type of information system projects.
Figure 4.3: Development method.
Figure 4.4: Crosstab between type of project
and development method.
Figure 4.5: Process success.
Figure 4.6: Process success (Agile vs Waterfall).
Figure 4.7: Cost and time comparison.
Figure 4.8: Scope comparison (Agile vs Waterfall).
Figure 4.9: Deliverable success.
Figure 4.10: Deliverable success (Agile vs Waterfall).
Figure 4.11: Business success.
Figure 4.12: Business success (Agile vs Waterfall).
Figure 4.13: Strategic success.
Figure 4.14: Strategic success (Agile vs Waterfall).
Figure 4.15: Overall success.
Figure 4.16: Longitudinal analysis of information
technology project s uccess rate.
3
5
7
8
13
19
22
24
30
43
63
64
65
65
67
67
69
71
72
73
74
75
76
77
77
78
xiii
List of Figures
Figure 4.17: Overall information technology
project success.
79
Figure 6.1: Symbiosis of information system
project success and information
system project complexity.
101
Figure 6.2: Project success level factors.
108
Figure 6.3: Unconfirmed model for project
success levels.
109
Figure 6.4: Unconfirmed model for Waterfall
project success levels.
113
Figure 6.5: Unconfirmed model for Agile project
success levels.
117
Figure 6.6: Environmental complexity factor
plot diagram.
121
Figure 6.7: Exploratory model for environmental
complexity of information system project. 121
Figure 6.8: Environmental complexity factor plot
diagram when using Agile.
123
Figure 6.9: Exploratory model for environmental
complexity (Agile).
124
Figure 6.10: Environmental complexity factor plot
diagram (Waterfall).
125
Figure 6.11: Exploratory model for environmental
complexity (Waterfall).
125
Figure 6.12: Exploratory model for technical
complexity, dynamics and uncertainty
of information system projects.
128
Figure 6.13: Exploratory model for technical
complexity, dynamics and
uncertainty (Agile).
131
Figure 6.14: Exploratory model for technical
complexity, dynamics and uncertainty
(Waterfall). 134
Figure 7.1: Information system project success levels. 138
Figure 7.2: Symbiotic IS project success and
complexity model.
140
xiv
Notes on Contributors
Carl Marnewick
Prof. Carl Marnewick’s academic career started in 2007 when he
joined the University of Johannesburg. He traded his professional
career as a senior information technology (IT) project manager
for that of an academic career. The career change provided him
with the opportunity to emerge himself in the question why IT
and/or Information System (IS)-related projects are not always
successful and do not provide the intended benefits that were
originally anticipated. This is currently a problem internationally as
valuable resources are wasted on projects and programmes that
do not add value to the strategic objectives of the organisation. It
is an international problem where there is a gap between theory
and practice and he is in the ideal position to address this problem.
The focus of his research is the overarching topic, and his
particular interest is the strategic alignment of projects to the
vision of the organisations. This alignment is from the initiation of
a project to the realisation of benefits. He developed a framework
(Vision-to-Project i.e. V2P) that ensures that projects within an
organisation are linked to the vision. Within this framework, a
natural outflow of research is the realisation of benefits to the
organisation through the implementation of IT and/or IS systems.
Benefits realisation is part of a complex system and his research
to date has identified the following impediments in the realisation
of benefits, (1) IT project success rates as well as IT project
management maturity levels did not improve over the last decade
and these results are in line with similar international research, (2)
IT project managers are not necessarily following best practices
and industry standards, (3) governance and auditing structures
are not in place and (4) IT project managers’ training and required
skills are not aligned. If these four aspects are addressed through
research and practice, then benefits realisation can occur.
His research has given him national and international presence.
He is currently a regular reviewer for national and international
journals. He was actively involved in the development of new
international project management standards ISO21500 and
ISO21503 (portfolio management). Project Management SA
xv
Notes on Contributors
awarded him the Excellence in Research Award as recognition
for his active contribution to the local and global body of
knowledge by conducting and publishing scientific research in
portfolio, programme and project management.
He is currently heading the Information Technology Project
Management Knowledge and Wisdom Research Cluster. This
research cluster focuses on research in IT project management
and includes, amongst others, governance, auditing and
assurance, complexity, IT project success, benefits management
and sustainability. Email: cmarnewick@uj.ac.za
Wikus Erasmus
Wikus Erasmus has been researching and lecturing at the
University of Johannesburg since 2010 in the Department of
Applied Information Systems. He has attained a master’s degree
in Business Management with his undergraduate studies in
Informatics. He is registered as a PhD candidate.
He did a tour of duty as a project manager in the construction
and information technology industry where he primarily focused
on IT infrastructure implementations. These were for major
South African corporate clients, including financial institutions
and retail holding groups.
His experience as a project manager in the IT industry has guided
him to focus on various issues of importance to project management.
These include the governance of projects, programmes and
portfolios, the strategic alignment of projects and the success of
IT projects. He has published various papers that addressed poor
communication and poor risk management practices in IT projects.
He also experienced the importance of stakeholder relations, even
when challenged, in the successful completion of a project.
He is of the opinion that proper governance frameworks
should be implemented if greater project success rates are to
be observed as these would improve the strategic alignment
of projects. This improved strategic alignment would ensure
that projects that contribute to organisational goals will be
attempted. The process needs to be overseen with concurrent
project auditing and a final project audit to impart organisation to
the organisation. These verification methods are yet other areas
that he has found lacking in the practice of project management.
Email: werasmus@uj.ac.za
xvi
Notes on Contributors
Nazeer Joseph
Nazeer Joseph (BCom, BCom Hons, MCom) is a native of
Johannesburg who, while working on his master’s degree, joined
the University of Johannesburg (UJ) as a part-time lecturer for
the Department of Applied Information Systems. The output of
his master’s degree was a predictive model for determining IT
project success. His master’s degree, which he achieved cum
laude, signifies his contribution to the IT project management
body of knowledge. On completion of his MCom, he joined UJ
on a full-time basis. He chose to pursue an academic career once
he completed his MCom and realised that the field of IT project
management requires extensive attention in order to improve IT
project success. The poor performance of IT projects is a global
phenomenon and must be addressed to ensure these projects
deliver the expected benefits to realise organisational goals and
objectives.
His research touches on a number of areas in the IT project
management domain, (1) IT project management processes,
(2) Agile IT project management, (3) IT project performance,
(4) IT project management competencies and (5) IT project
management sustainability. He is currently working on his PhD in
IT management with the primary focus on IT project management
processes. A key aspect why IT projects fail is that current
project management processes are inadequate for IT projects.
The aim of his PhD is to investigate why current processes are
inadequate and what can be done to improve these processes
and subsequently IT project performance.
As a junior lecturer and researcher at UJ, he has established
himself as performer and contributor to the IT project
management body of knowledge. He publishes in international
journals, participates in conferences and strives to continuously
contribute as a journal reviewer. His master’s research was the
only master’s degree presented at the 2014 PMI Research and
Education Conference.
In an effort to improve the state of IT project performance, he
works within a research cluster which has established close ties
with South African organisations to assist them with addressing
this problematic phenomenon. Email: njoseph@uj.ac.za
xvii
Chapter 1
Chapter 1
Introduction
Project success is one of the enigmas within the project
management discipline. No one is sure how to define project
success, what contributes to projects succeeding or failing or
how to measure the success of projects. This is even worse when
it comes to Information System (IS) projects. The deliverables
of IS projects are seldom seen apart from some application that
users and customers use as part of their daily routine. The only
time that the deliverable of an IS project is visible and tangible
is when the focus of the IS project is to replace or upgrade
hardware.
I nvestment in information
technology
Vast amounts of money are spent annually on Information
Technology (IT). The rationale is that organisations cannot
function without IT and therefore it warrants the large amounts
of money that are invested in IT. A report by Lovelock et al.
(2017) indicated that IT spending is rising on an annual basis and
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Introduction’, in The symbiosis
between information system project complexity and information system project success,
pp. 1–17, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2017.itpsc45.01
1
Introduction
TABLE 1.1: Information technology spending world.
Years
Spending (Billions of
dollars)
2014
2015
2016
2017
2018
2019
Data centre systems
166
171
170
175
176
178
181
Enterprise software
310
314
333
355
380
407
436
Devices
649
646
588
589
589
593
593
IT services
897
866
900
938
981
1029
1081
Communications services
Total
2020
1541
1399
1384
1408
1426
1441
1462
3564
3395
3375
3464
3553
3648
3752
Source: Lovelock et al. 2017.
will continue to rise for the foreseeable future. Annual growth
is predicted to be around 2.7%. The prediction is illustrated in
Table 1.1.
It is evident from the amounts in Table 1.1 that companies as
well as governments spend a lot of money on IT-related services.
The annual increase of 2.7% also indicates that IT is a continuous
investment. This continuous investment in IT is also evident
from a South African perspective where it is expected that
South Africa will spend $10.5 billion in 2017. This is 0.3% of the
worldwide spend on IT. Research indicated that South African
companies spend billions of rands on IT services as illustrated in
Figure 1.1.
The South African spend on IT services is 0.5% of the
worldwide spend on IT services. That is an amount of $5bn. IT
services normally include, (1) IS consulting, (2) system integration,
(3) maintenance, support and upgrades, (4) full outsourcing
and (5) hosting. The remainder is spent on devices, enterprise
software and communication services. Given this amount of
money that is spent on IT, the question is raised whether this
adds any value to organisations, irrespective of whether they are
public or government entities. The amount that is annually spent
on IT is a mere 0.7% of South Africa’s gross domestic product.
One of the control objectives within COBIT 5 (EDM02) states
that organisational leaders should receive the optimal value from
2
Chapter 1
IT Spend (Billions rands)
90
87.3
85
80
75
75
70
70
65
63
60
55
65
56.9
50
2015
2016
2017
2018
2019
2020
Source: Lovelock et al. 2017.
FIGURE 1.1: Information technology services spending – South Africa.
their investments in IT services and IT assets (IT Governance
Institute 2012). Even from a governance perspective, IT
investment should make logical sense and contribute to the
overall benefit of the organisation. IT investments are generally
implemented through programmes or projects that create
benefits and ultimately business value (Curley, Kenneally &
Carcary 2016).
Value of IT
IT provides value to entire organisations because they reach
out to the world through IT. IT is not perceived as a stand-alone
entity or division because it is integrated within the organisation,
and organisations cannot perform without IT. When IT does not
deliver value, then the chances are that the organisation will also
not reach its optimum performance.
The questions that organisations need to answer are: Firstly,
What value is IT to the organisation? and secondly, How can this
3
Introduction
value be measured? The value of IT can be determined through
the following equation:
Value of IT = Benefits – Costs
Given this equation, organisations should determine the
benefits that they receive from IT and also how much it costs to
implement, maintain and upgrade IT.
Determining the costs of IT is relatively easy, but organisational
leaders should not just take the direct costs into account but
also the hidden or overlooked costs. Hidden costs include, but
are not limited to, recruiting, training, office space, software
enhancements (upgrades), software maintenance (bug fixes),
hardware upgrades, hardware maintenance and scheduled
outages. Ascertaining the benefits of IT is not easy. The easiest
way might be to shut down the entire IT department for a day or
two and determine the impact on the organisation based on lost
sales and opportunities or the negative impact on the brand of
the organisation.
Irrespective of what metrics are used to determine the
benefits of IT, a general way to determine the benefits is to use
financial calculations such as Return on Investment, Payback
Period or Net Present Value. The results from these financial
calculations normally indicate whether an investment in IT is
a safe and profitable investment. The benefits of IT are also
intangible and these are the challenge that organisational
leaders face. How do organisations quantify the intangible
benefits of IT?
Harris, Herron and Iwanicki (2008) provided a framework
that can be used to determine the value of IT. The value of IT is
determined over a period of time and is based on the investment
in IT and also the benefits of IT to business. A simplified version
of the framework is illustrated in Figure 1.2.
The value of IT to business is determined by the degree
whereby processes are influenced and changed, how sales have
improved and whether there is a growth in revenue at the end
4
Chapter 1
Business operational value
Business process value
IT Application business value
IT investments
IT Infrastructure business value
IT
Managment
responsibility
Business investments
Business
Managment
responsibility
Business financial value
Time for business impact
FIGURE 1.2: Information technology value framework.
of the day. Figure 1.2 actually highlights that everyone in the
organisations are responsible for determining the value of IT.
The IT department provides IT as an enabler for business and
it is up to business to determine to what extent they want to
embrace IT.
IT investments are normally realised through projects and the
more successful the projects, the more value is created from the
IT investments. The following sections briefly discuss the success
rates of IS projects and highlight that organisations do not obtain
value from IT projects and therefore also not from IS.
Information technology is the cumulative word that is used
to describe everything and anything that has vaguely to do with
computers. IT consists of three components, of which the first
is computer science. This discipline focuses on topics such as
discrete structures, human-computer interaction, programming
fundamentals, graphics and visual computing, algorithms and
complexity and programming languages amongst others.
The second layer or component is information technology.
This discipline focuses on the selection, creation, application,
integration and administration of computing technologies.
Computing technologies include networking, databases, web
systems and information security. Information systems is
5
Introduction
the third layer and focuses in general on the improvement of
organisational processes and the design and management
of enterprise architecture. Topics within the IS field focus on
data and information management, enterprise architecture, IT
infrastructure, IS project management, systems analysis and
design as well as IS strategy.
This study focuses specifically on the third layer, that is, the IS
layer and more specifically on IS project management.
IS project success rates
IS projects are the vehicles that organisational leaders use to
implement the IT strategy. The logical conclusion is that when IS
projects fail or are perceived as not delivering on all the benefits,
then the IT strategy is not fully implemented. This then creates
an imbalance where the IT strategy does not fully contribute to
the organisational strategies.
Information system project success has been studied over
the last couple of decades by academics and practitioners
alike. The reason for this almost frenetic research is that there is
enough evidence to indicate that IS projects are still failing at an
alarming rate. This was the case two decades ago, and it is still
the case in the late 2010s. Research is performed internationally
by the Standish group which produces the Chaos Chronicles,
and in South Africa the research on IS project success rates is
called the Prosperus reports (Labuschagne & Marnewick 2009;
Marnewick 2013; Sonnekus & Labuschagne 2003). Results from
the international research are shown in Figure 1.3.
The results indicate clearly that something drastically is wrong
as the rate to successfully implement an IS project is on average
28%. This implies that 70% of IS projects either do not add value
or add limited value to organisations. Of even greater concern is
the fact that the success rates have stagnated at around 30% for
the last decade, implying three things:
6
Chapter 1
40
35
35
32
Percentage
30
27
25
26
28
29
31
29
29
28
27
20
15
16
10
5
0
1994
1996
1998 2000 2004 2006 2009 2011
2012
2013
2014
2015
Year
Source: Labuschagne and Marnewick (2009); Marnewick (2013); Sonnekus and Labuschagne (2003).
FIGURE 1.3: International information system project success rates.
1. IT departments and professionals actually do not care about
these results.
2. We do not understand the complexity of IS projects.
3. We are measuring the success of IT projects incorrectly.
IS projects success rates within South Africa do not look much
better as indicated in Figure 1.4.
Although the South African success rates look better than the
international success rates, South African companies are in the
same boat as international companies where a mere third of IS
projects are perceived as successful.
When these results are translated into monetary value, a
gloomy picture is created as indicated in Table 1.2. The results
indicate that $17 820bn are wasted on IS projects that either do
not deliver or deliver little value to a company.
The South African perspective is just as bleak as indicated in
Table 1.3. On average, 57 cents are wasted for every one rand
spent on IT.
7
Introduction
70
60
59
Percentage
50
40
43
37
34
30
20
10
0
2008
2003
2011
2013
Year
Source: Labuschagne and Marnewick (2009); Marnewick (2013); Sonnekus and Labuschagne (2003).
FIGURE 1.4: South African information system project success rates.
TABLE 1.2: Information technology waste – worldwide.
Year
Billions of dollars
Spending
Waste
2014
3564
2566
2015
3395
2444
2016
3375
2430
2017
3464
2494
2018
3553
2558
2019
3648
2627
2020
3752
2701
Total
24 751
17 820
The results depicted in this section clearly indicate that
companies need to address the success rates of IS projects as
a matter of urgency. Information technology cannot continue
to be seen as a black hole into which money disappears and
little or no value is created for the company and all the relevant
stakeholders.
8
Chapter 1
TABLE 1.3: Information technology waste – South Africa.
Year
Billions of rands
Spending
Waste
2015
56.9
32.4
2016
63
35.9
2017
65
37.1
2018
70
39.9
2019
75
42.8
2020
87.3
49.8
Total
417.2
237.8
Strategic alignment of IT
Projects are generally perceived as the vehicles to implement
strategies (Cooke-Davies 2016; Martinsuo, Gemünden & Huemann
2012; Marnewick & Labuschagne 2010). These strategies can
be organisational strategies or they can be strategies specific
to a division within the organisation. IT strategies are also
implemented through projects.
IT strategies are derived from the organisational strategies
and are therefore aligned with the organisational strategies
(Marnewick & Labuschagne 2011). This implies that when the
organisational strategies change, the IT strategies should also
change and be realigned with the organisational strategies.
Within the COBIT governance framework, EDM01 (Ensure
Governance Framework Setting and Maintenance) focuses on
the alignment of the IT strategy with the organisational strategy
(IT Governance Institute 2012). EDM01 measures three specific
concepts related to the IT strategic alignment:
•• The percentage of organisational strategies supported by IT
strategies.
• The level of stakeholder satisfaction with the intended IT
portfolio. The IT portfolio consists of various programmes and
projects that will implement the IT strategy and ultimately the
organisational strategy.
9
Introduction
• The percentage of IT-value drivers that are mapped to the
organisational value drivers.
Given the notion that projects are the vehicles to implement
the IT strategies, organisational leaders should then be seriously
concerned. The IS project success results clearly highlight the
notion that IT strategies cannot be fully implemented because
of the large number of IS projects that are failing. It is evident
that only a small percentage of the IT strategy is implemented
which in turn implies that IT strategies are not necessarily
supporting the organisational strategies. This raises the
question whether IT adds value to the organisation at large as
suggested by EDM02.
This non-delivery of IT strategies creates a governance
concern. The question that needs to be answered is what the
real value is that IT brings to the organisation at large. There
is no doubt that organisations cannot function without IT, but
the question is whether IT is of strategic value or operational
value. The results suggest that IT is more of operational value
than strategic value.
Types of IS projects
There is no one-size-fits-all solution when it comes to the
implementation of IS projects. IS projects come in different
flavours and IS project managers should take cognisance of
these different types of projects.
Infrastructure
The implementation of IT infrastructure is one of the least
complex projects to realise. These types of projects focus on
the implementation of hardware such as networking equipment
or the installation of desktops and printers. What makes these
types of projects less complex is the simplicity and predictability
to implement. For example, when an organisation needs to
10
Chapter 1
relocate offices, new network points need to be installed. The
project schedule is easily created, as the project manager will
know more or less how long it takes to install a network point
and that the time needed is merely multiplied by the number of
network points. The same logic applies when printers or desktop
workstations need to be installed.
Customisation
Customisation of software is a little bit more complex than
the implementation of infrastructure. Software products
do not necessarily suit the needs of an organisation as is.
To cater for the specific needs of an organisation, software
needs to be customised or changed. This change is more a
cosmetic change to the existing software product than a major
change to the internal workings of the software package.
Customisations might include the change of financial reports
to suit legislation or a change in the look and feel of an order
capture screen.
Integration
Integration on the other hand is more complex than
customisation. Integration focuses on sending data (information)
between two software products. This implies that the
software developer needs to understand the data structure of
both products and the way that data is stored. Integration focuses
on the conversion of data from the one product to the
other product and vice versa. Planning for integration is also
tricky as it is not always that easy to estimate the duration of any
integration.
System implementation (full)
A full system implementation is extremely complex and
contains a lot of uncertainties. A full system implementation
11
Introduction
is typically when organisations decide to replace one system
with another system. This might be the case when an Enterprise
Resource Planning (ERP) system replaces a legacy system.
This type of implementation requires all hands on deck and
normally includes infrastructure replacements, customisations
and integrations with other systems.
System implementation (upgrade)
An upgrade is also complex and consists of a level of uncertainty
but not to the extent of a full system implementation. The
difference between an upgrade and a full implementation is
that the basic building blocks are in place. The upgrade focuses
on staying current with the latest version of the software.
The upgrade might include the upgrade of infrastructure but
definitely some customisations and integrations. Customisations
and integrations can follow different methods of implementation,
that is the traditional Waterfall method or an Agile approach.
Method of implementation
Various methods exist to implement IS projects, but it is not the
purpose of this book to discuss all the different methods. The
two most important methods are the Waterfall model and Agile
and its various variations.
Waterfall model
One of the first structured approaches developed was the
Waterfall process. In this model as illustrated in Figure 1.5, the
process is executed in an orderly sequence (Leffingwell 2011).
Each stage is completed before the next stage starts (Leffingwell
2011). Requirements are agreed, a design is created after which
the coding follows and testing is performed. The final step is
integration. In practice when implementing complex systems, it
is almost impossible to have requirements that do not change
12
Chapter 1
Requirements
Design
Code
Test
Integrate
Source: Dorfman and Thayer (2000).
FIGURE 1.5: Waterfall model.
during the implementation life cycle (Dorfman & Thayer 2000).
The advantage of the model is that it is a simple process to
manage (Sommerville 2001).
An iterative approach is used in the Waterfall model where
each successive step provides feedback to a previous step (Royce
1970). However, the Waterfall model is mostly interpreted as a
sequential linear process (Boehm 2006).
Agile approach
Agile methodologies were initially authored to manage the
development of software development projects, but have been
extended because of their popularity and success with handling
most types of IS projects. Agile software development is a method
of software development that is characterised by an emphasis
on, (1) people, (2) communication, (3) working software and (4)
responding to change.
The working definition of Agile methodologies can be
summarised as a group of software development processes that are
iterative, incremental, self-organising and emergent. Hence from a
theoretical perspective Agile methodologies can be defined as:
13
Introduction
•• Iterative: The word iterative is derived from iteration which
carries with it connotations of repetition. In the case of Agile
methodologies it is not just repetition but an attempt to solve
a software problem by finding successive approximations to
the solution starting from an initial minimal set of requirements.
• Incremental: Each subsystem is developed in such a way that
it allows more requirements to be gathered and used to
develop other subsystems based on previous ones. The
approach is to partition the specified system into small
subsystems by functionality and add a new functionality with
each new release.
• Self-organising: This term introduces a relatively foreign
notion to the management of scientific processes. The usual
approach is to organise teams according to skills and
corresponding tasks and let them report to management in a
hierarchical structure. In the Agile development setup the
‘self-organising’ concept gives the team autonomy to organise
it to best complete the work items.
• Emergent: The word implies three things. Firstly, based on the
incremental nature of the development approach the system
is allowed to emerge from a series of increments. Secondly,
based on the self-organising nature a method of working
emerges as the team works. Thirdly, as the system emerges
and the method of working emerges a framework of
development technologies will also emerge.
It must be noted that for the purpose of this book and study,
reference is made to Waterfall projects and Agile projects. Waterfall
projects are IS projects that make use of the Waterfall method to
deliver the software that forms part of the larger project. Similarly,
Agile projects are projects that make use of Agile methods to
develop software. These terms are strictly not the correct terms
but are used for ease of reading and understanding.
Previous studies uncovered various factors that contribute to
IS project success (Marnewick 2013; The Standish Group 2014).
Although complexity was defined as a factor, complexity as a
construct was never investigated as a factor itself. The purpose
of this study is to understand complexity within the IS domain
14
Chapter 1
and to determine the relationship between IS project success and
complexity. This was achieved through a quantitative approach.
Research methodology
A quantitative approach was used for this study as the primary aim
was to determine current IS project success rates as well as the
relationship with complexity (Denscombe 2010; Thomas 2003).
The rationale for this decision was two-fold. This study builds on
previous studies (Labuschagne & Marnewick 2009; Marnewick
2013; Sonnekus & Labuschagne 2003), and IS success rate
trends need to be established. This can only be done through a
longitudinal study that is embodied within a quantitative approach.
The second reason was that it ensured that each respondent was
presented with the exact same questions in the same sequence.
Moreover, this allowed the researchers to reliably aggregate and
compare the responses between different sample subgroups.
Probability sampling was used as this research focused on
providing a representative view of the unit of analysis for the
purpose of generalisability (Sekaran 2003). Simple random
sampling was selected because it not only provides results which
are highly generalisable, but also adequately represents the
target population. Furthermore, as this form of sampling exhibits
low bias, the results obtained would provide an objective view of
the research problem.
The instrument used for this study was a questionnaire. The
questionnaire was divided into four sections. The first section
focused on the biographical information of the respondent.
The second part focused on the type of IS project that is under
investigation. Two important aspects that form part of an IS
project had to be answered. The first aspect speaks to the type
of IS project and the second aspect speaks to the type of method
that was used to implement the IS project.
The third section of the questionnaire dealt with the notion of
IS project success. This section was designed around the model
of Bannerman and Thorogood (2012). Each component within a
15
Introduction
success level was measured based on a Likert scale. Respondents
could choose between poor, fair, good, very good and excellent.
This was applicable to processes, deliverables, business and
strategic success. Actual figures were provided for cost and time
that form part of project management success.
The fourth section of the questionnaire focused on the
complexity of the project. Five types of complexity had to be
assessed based on a Likert scale. Respondents could choose
between simple, relatively simple, fairly complex, complex
and very complex. Organisational complexity consisted of 34
types of complexity, technical complexity consisted of 12 types,
environmental complexity consisted of 13 types, dynamics
consisted of 6 types and uncertainty consisted of 10 types. The
types of complexity are discussed in detail in Chapter 3.
Book layout
The book is divided into the following chapters for ease of
reading and referencing. Chapter 2 focuses on IS project
success and what constitutes IS project success. The framework
of Bannerman (2008) is used to describe IS project success.
Success is not just a yes or no answer but can be measured at
various levels that might have an impact on one another. This
model or approach provides organisational leaders with a better
way to measure and determine IS project success.
The third chapter unpacks the notion of complexity. This is
done through the lenses of IS projects. The outcome is that IS
projects are complex and that five types of complexity influence
IS projects. Each of these five complexity constructs consists
of elements that in turn consist of features. This makes the
management of IS projects extremely complex.
Chapter 4 analyses the success of IS projects. Each level of
the framework is used to determine project success. For each
level, the overall success is determined as well as the success for
the Waterfall and Agile projects. The results highlight that there
16
Chapter 1
is an improvement in overall IS project success and that Agile
projects might be more successful than Waterfall projects.
Chapter 5 investigates the results of IS complexity. To simplify
the matter, the top five and bottom five elements are provided
for each complexity construct. This is also done for all IS projects
and specifically for the Agile and Waterfall projects.
Chapter 6 focuses on the relationship or symbiosis between
IS project success and complexity. The results indicate that a
symbiotic relationship exists between IS project success and
complexity. The various complexity constructs are mapped to
the levels of IS project success.
Chapter 7 concludes the book. A synopsis is provided to
enable organisational leaders and IS project managers to utilise
the information and make better decisions, increase IS project
success rates and address complexity within IS projects.
17
Chapter 2
Demystifying project
success
Most IS projects fail (Johnson 2014; Marnewick 2013a, 2013b).
In fact, almost two thirds of IS projects evaluated since 2003
could not be classified as success stories. Figure 2.1 indicates the
lack in progress made by project management professionals in
increasing the rate of delivering success.
The South African results approximate the international results,
indicating that there are not simply local conditions at play. There
must be something at the heart of IS project management that is
actively driving these results.
Billions of rands are spent each year on IT services, and
investment is set to grow in this area (Lovelock et al. 2017). No
wonder organisational leaders are losing confidence in project
management methodologies when almost two-thirds of IS
projects fail and investment is lost, or the project does not deliver
on its promise.
Much has been written on why projects fail (Budzier &
Flyvbjerg 2015; Erasmus, Marnewick & Joseph 2014; Joseph
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Demystifing project success’,
in The symbiosis between information system project complexity and information system
project success, pp. 18–32, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2017.itpsc45.02
18
Chapter 2
70
59%
60
Percentage
50
CHAOS Chronicles
Prosperus Reports
43%
40
37%
30
35%
34%
31%
29%
29%
20
10
0
2002
2004
2006
2008
Year
2010
2012
2014
Source: Joseph, Erasmus and Marnewick (2014).
FIGURE 2.1: South African and global information system project s uccess rates.
et al. 2014; Marnewick, Erasmus & Joseph 2016a, 2016b; Ngoma
& Erasmus 2016). This knowledge has been with project
professionals for a very long time. It is known why projects fail.
It is known what should be done to ensure projects are delivered
successfully (Cooke-Davies 2002). Yet, project managers cannot
seem to increase their project delivery success rates. This is the
annunciation of Cobb’s paradox: If we know why projects fail and
how to prevent it, why do we still fail at projects? (Bourne 2011).
The answer could lie in the fact that much research has been
done in the technical aspects of project management, while
limited studies are done in the so-called ‘soft issues’ around project
management. It may very well be that the identified inhibiters
and enablers of project success are only partially responsible for
project outcomes and more remain to be uncovered. What may
complicate matters even more is the possibility that IS projects
do not fit the traditional paradigm of project management as we
know it today. Perhaps IS projects are so different that project
management should be rethought in its entirety in order to deal
with the idiosyncrasies of IS project management.
19
Demystifying project success
What is abundantly clear is that should IS project delivery
continue on the current trajectory, we may very well not
encounter the term ‘IS Project Management’ in future. Investment
decision-makers will look elsewhere to achieve the goals that
formal project management methodologies promised.
The evolution of success
One of the formal definitions of a project is that it is a set of
predetermined activities that need to be completed incrementally
in order to achieve a unique, predefined objective through the
use of resources in a specified time frame (Project Management
Institute 2013; Schwalbe 2016). At face value, it is a relatively
simple task to provide a deliverable in the manner a customer
requests.
Tools, techniques and processes that were already available
to operations were adapted to compensate for the closed-off
time frame in completing these activities. These were harnessed
into formal project management methodologies. This was the
approach of the 1970s, although projects have been attempted
and completed for centuries and millennia before then.
Much of past research was focused on the mechanisms, tools
and techniques for managing a project properly. Bodies such as
the Project Management Institute and Association for Project
Management have developed innumerable toolkits, standards,
methodologies and frameworks to assist project practitioners in
this endeavour.
But that was not the end of the story. Organisational leaders
discovered that even though they had to manage project
managers through strict quantifiable metrics, such as the
triple constraint, customers were often satisfied with the end
product, although they might not have been satisfied in the
manner of its delivery. The product became then the priority
at the end of the day. The end seemed to justify the means
(Davis 2014).
20
Chapter 2
Success varied by industry, yet large amounts were and
are invested in project management training and capabilities.
As organisations continued to grow, so did the scale and
complexity of projects. So much so that megaprojects could
not be managed by a single individual but through committees.
Megaprojects had strategic significance and as such they were
broken down into smaller projects. Programmes emerged.
Some oddball projects were encountered that did not seem
to fit in with the strategic intent of the organisation. Portfolio
management was then required to select and reject projects that
would have the greatest benefit in supporting the organisations’
strategic objectives. However, complexity grew even more as
organisations sought to gain competitive advantage through
projects. Market forces dictated that organisations needed to take
decisive action in attempting to gain and maintain market share.
Project management has now become an important strategyachieving tool through portfolio management. Any selected
project has to contribute to achieving the greater organisational
strategic intent.
Ultimate project success is now characterised by strategically
effective organisations. But what does that mean to the project
manager that is currently experiencing his or her first project
that simply cannot be steered to success, regardless of what
interventions are put in place? The so-called ‘project of death’.
Project outcomes
No discussion on project management success can be held
without referring to the seminal work performed by Paul
Bannerman. He rightly deduced that project success is achieved
on multiple levels and developed a framework to illustrate this
concept (Bannerman 2008; Bannerman & Thorogood 2012).
Figure 2.2 lays out the case that project success is defined
from various perspectives. In Level 1, project success is defined
by the successful implementation of project management tools
21
Demystifying project success
Return on investment
Tactical
(Derived value)
Strategic
Stakeholders
Technical
Project
Client/User
Level 1
Level 2
Level 3
Project
Process
success
PM
success
Product
Deliverable
success
Business: Internal
Level 4
External
Level 5
Organisational benefit
Business
success
Strategic
success
Source: Adapted from Bannerman (2008).
FIGURE 2.2: Five levels of project success.
and techniques. Success at this level is determined through the
selection of appropriate tools and how effective they were used.
In Level 2, success is measured according to whether the
project has met the triple constraint of time, cost and scope.
A failure to meet any of these technical constraints would result
in total project failure at Level 1 and Level 2.
Customers, clients or users are usually less concerned
about whether the projects have used the appropriate technical
tools. They may be somewhat concerned how well the project
fared with regard to the triple constraint. However, users and
customers are mostly concerned about the deliverable the
project produces at the end of the day. Consideration such as
‘fit for use’ or usability are of greater concern at Level 3. Various
examples exist where the product produced by a project can
successfully be used by the project’s customers and has yet
failed on Level 1 and Level 2 criteria (Marnewick 2016; Serra &
Kunc 2015). If a project meets the customer’s specifications, the
project can be termed a success on Level 3. Product success
would then be achieved.
22
Chapter 2
Project success on Level 4 is determined by realised benefits
provided subsequent to project completion. Should the benefits
promised in the initial business case actually accrue or realise as
a direct result of a completed project, then the project would
be a success. Unfortunately, these benefits do not immediately
become apparent as soon as the project is completed (Marnewick
2013b). These benefits would only start to become a reality when
the product delivered by the project has been fully operationalised
and integrated in the organisation. Only after an indeterminate
period of time, and after careful observation and measurement,
would the direct impact of the deliverable become known.
Ultimately, Level 4 project success is determined by whether
or not business goals have been achieved or not through
the successful completion of a project. What one has to bear
in mind is the fact that certain unintended consequences or
benefits may result after the integration of a project product in
the organisation. Where it may be difficult to point to a specific
project to indicate what impact it had on achieving business goals,
it may be simpler to determine where a group of strategically
similar projects have had such an impact. This may be done in
the form of prudent programme management where control and
coordination could be achieved between projects that are aimed
at achieving a particular business objective. In organisations
where no programme management discipline exists, it will have
to make do with strong project management reporting.
Level 5 project success is externally focused in that strategic
success is to result because of successful project delivery. These
concerns are focused on whether the organisation’s position shows
improvement with regard to investors, the competition and the
market in general. This level of success may be extraordinarily
difficult to attribute to any single project. Therefore, portfolio
management may be better suited as this is an attempt to aggregate
all project outcomes throughout the organisation to determine the
strategic success of the project discipline in the organisation. This
will obviously only be of any meaning if an effort was made to align
all projects to the organisation’s strategic intent.
23
Tactical level: Programme management
Level 4: Business success for internal business stakeholders
Level 3: Deliverable success for user/clients
Operational level: Project management
Level 3: Deliverable success for user/clients
Level 2: Project management success for stakeholders
Level 1: Process success for technical stakeholders
Product &
project success
Strategic level: Portfolio management
Level 5: Strategic success for external stakeholders
Level 4: Business success for internal business stakeholders
Organisational benefit
Demystifying project success
FIGURE 2.3: Project outcome and portfolio, programme and project management.
Mapping these perspectives to the traditional three
organisational levels as well as project, programme and portfolio
management provides the following view in Figure 2.3.
Some overlap may exist on Level 3 and Level 4. Deliverable
success may form part of project or programme management,
depending on the structure of the organisation. Level 4 is
most often found under portfolio management (Jenner 2016)
of the organisation but may also be found under programme
management (Serra & Kunc 2015). These adaptations will have
to be considered in organisations that do not have a programme
management office for lack of need.
24
Chapter 2
Success and failure
When one is set to lose a contest one was almost certain to
win through bad judgment and mistakes, one is said to have
snatched defeat from the jaws of victory. In project management,
there seem to be many avenues to attain success, given the five
different available perspectives. Additionally, we know what
causes projects to fail and to succeed, yet we continue to reach
out feverishly towards defeat.
Bannerman (2008) takes great pains to clarify that the
five levels of project success are not related in an aggregated
manner. He indicated that process success does not imply
project management success. A project that was successfully
completed in scope, time and budget does not guarantee that
the deliverable will be accepted or useful to the customer.
A product regarded as useful by the customer does not imply
that business objectives will be met. Achieving business
objectives does not imply that the organisation will be
strategically successful. Clearly success is dependent on a
specific stakeholder’s perception.
Does one need to be successful on all five levels before a
project can be deemed successful? Luckily this seems not to be
the case as it would be a Herculean task. The technical project
team member responsible for a specific process on Level 1 can
in no way be held responsible for the outcome on strategic
success in Level 5. However, is the executive board dependent
on these technical processes being completed successfully in
order to attain strategic success in the long term? The research
determines it need not necessarily be so.
We are left with a conundrum. Vast bodies of literature
extoll the virtues of proper project, programme and
portfolio management. Each academic work enumerates the
seemingly countless processes, procedures, inputs and outputs
for each activity. Is it all for nought when the organisational
leaders above the project manager’s pay grade are unaffected
25
Demystifying project success
by their successes and failures? Why is there such an emphasis
on completing projects successfully when there is little ultimate
significance in the high levels of the strategic hierarchy?
It seems that project management shares certain principles
with alchemy. The alchemists of yore attempted to transform
lead into gold. They never attempted to create gold from
nothing. The same may be true in project management. The
technical processes on Level 1 needed to produce a ‘substance’
that project managers could use to transform into another
‘substance’ in Level 2. This new substance takes on the form
of a project outcome: success or failure. The individuals in
Level 3 need to create this ‘project management substance’
and create a product that could be either a success or a
failure. The Level 4 alchemist needs to transform this ‘product
substance’ into some sort of business benefit and that must be
transformed again into strategic success in Level 5.
Therefore, two items are required in order to perform ‘project
management alchemy’: substance and alignment, success is
not necessarily required. The substance is the output from each
level of project success. In order to guide the transformation
process to ultimately deliver project management ‘gold’ in the
form of strategic success, some sort of strategic alignment is
required.
Without some sort of outcome from the previous levels,
it would not be possible to create an outcome that could be
ultimately usable in Level 5. And even if a high-quality outcome
is delivered at lower levels, if it cannot be taken to ultimately
further strategic objectives, the effort is futile.
Evidently, the terms ‘success and failure’ only have meaning
on Level 5 as they relate to ultimate project outcomes. On
Level 1 to Level 4, ‘success and failure’ only serve as a basis for
organisational governance to ensure that resources are used
appropriately in order to deliver a ‘substance’ of higher quality
that could more easily be transformed in the next level.
26
Chapter 2
Outcome influencers
What would enablers and inhibitors of success be at each level in
this ‘process’ view? The discussion focuses on the three grouping
of success as identified by Bannerman (2008):
1. Project success including technical process and project
management success.
2. Product success.
3. Organisational benefit including benefits realisation and
strategic success.
Project success
The vast body of research focuses its attention on the mechanism
and processes of project management and what these contribute
to delivering successful projects. The main enablers of success
in this section primarily deal with the skills and knowledge of
project managers.
Regarding specific technical processes, the main aspects
that project managers and their team members need to focus
on is in risk management and change control (Marnewick
& Erasmus 2014). Of these two, risk management is the
knowledge area in the PMBOK® Guide that is the least matured
in practice:
•• Proper risk management practices increase the quality of
project management in that eventualities are planned for in
budget, schedule and scope. This would decrease variances in
the triple constraint, resulting in a greater chance of project
management success.
• When certain parameters of the project are changed,
depending on whether specific technical processes are
completed correctly, the knock-on effect impacts the triple
baseline constraint. Change control must be present as change
is a given in the vast majority of projects. The impact of
uncontrolled changes is impossible to fully quantify. The effect
on the project, however, is devastating.
27
Demystifying project success
The skill that most project managers agree is the greatest
contributor to success is communication with the project team
(Marnewick et al. 2016a, 2016b; Monteiro de Carvalho 2013). This
stands to reason as all interaction in a project concerns the flow
of accurate information.
Inhibitors to success would include the antecedents of the
contributors to project success as discussed. However, when
organisational leaders recognise the need for additional training
something very counterintuitive happens. Project managers who
are sent for certification courses seem to develop a reduced
ability to deliver projects successfully once they are certified in
a formal project methodology (Joseph et al. 2014). The reasons
behind this are unclear, but as it stands, formal certification
seems to be an inhibitor of project success.
Another great inhibitor to project success is an organisational
culture that does not allow for or value prudent project
management practices (Mir & Pinnington 2014; Rosemann
& Vom Brocke 2015). This would include undue pressure on
project managers to shorten the planning phase of their project
in order to get to execution more rapidly. This rush may leave
many risks and challenges unidentified, resulting in chaos during
execution.
Product success
Product success implies the user and/or customer have their
needs met through the project deliverable, regardless of how it
came into their hands (Bannerman 2008). The greatest success
enabler here is effective communication with stakeholders, more
specifically between the project team and the user or customer
(Barclay 2015; Davis 2014). This is to ensure that correct client
specifications are used in designing the product or service to
be delivered. This entails that proper requirements management
takes place. Regular customer feedback is required to ensure
that all stated needs are met in the deliverable.
28
Chapter 2
Another enabler of product success is the active involvement
of an individual that could fulfil a customer relations role that
further facilitates communication. This is especially important
when project management failure is looming.
An inhibitor to product success is, of course, miscommunication
and changing requirements. It will obviously be much more
difficult to meet customer requirements should these be in
flux. Unreasonable customers may also decide not to accept
the product even if all signed-off requirements are met, but the
actual product is not what was expected by the customer (Turk,
France & Rumpe 2014).
Organisational benefit
The organisational benefits are achieved as a result of successfully
completed projects or programmes in the organisation that
impart a strategic advantage.
Benefits realisation is a perspective internal to the organisation
that could overlap the strategic and tactical organisational levels.
This perspective takes a longer view of the effect of projects in the
organisation in that benefits can only accrue after a project has
been completed. These benefits are not immediately apparent. In
order to internalise these benefits, the project deliverable needs
to be integrated into the organisation. This would imply that some
level of organisational change management must be initiated. This
process could be illustrated as in Figure 2.4 (Coombs 2015).
For the implementation of an IS deliverable, operations need to
be adapted to accept and effectively utilise the new deliverable.
The premise is that business benefits will only accrue once business
change has occurred through the use of IT. This seems eminently
reasonable in an IS context (Whyte, Lindkvist & Jaradat 2016).
For the implementation of an IS-type deliverable, the following
main inhibitors to benefits realisation are identified (Coombs
2015):
29
Demystifying project success
Enablers
IT enabled operational transformation
IT
Business
change
Business
benefits
Inhibitors
FIGURE 2.4: Information technology enabled operational t ransformation.
•• Staff not engaging with new ways of thinking: This speaks
directly to the difficulty in changing organisational culture
and the individual’s resistance to change.
• Poor design of the new system: Clearly this links to product
success. A poorly designed product or deliverable will not be
readily accepted by its intended users. Expected benefits will
only accrue once these deficiencies are corrected after the
closure of the project.
• Poor performance of the system: This is another productrelated metric that would inhibit the use of the system and its
subsequent realised benefits.
Here we see a much stronger link between levels of
project success in Level 3 and Level 4, benefits realisation. The
results imply that a poor product deliverable could negatively
impact benefits realisation. A poor quality deliverable in
Level 3 implies an inhibitor to benefits realisation in Level 4.
Enablers of benefits realisation include the following:
• Training in the use of the deliverable. Users cannot immediately
accept the new deliverable. Initial acceptance would be
dependent on training and ensuring users and customers are
used to the new systems. However, this would only account
for product success on Level 3. Enhancing the chances of
success at Level 4 requires ongoing training for users to
use the new system to its fullest potential. A change in
organisational culture is required in order to sustain the
30
Chapter 2
transformation effort and to prevent users from falling back
into old patterns of behaviour that may have necessitated the
creation of a new system.
It seems in benefits realisation that inhibitors are more technically
oriented, while enablers are more organisationally oriented. It
would, therefore, be appropriate that transformation activities
take place under the auspices of an organisational entity that
is responsible for mapping and tracking benefits. Strategic
success on Level 5 has an external perspective where all project
activities, from Level 1 to Level 4, culminate in some impact on
the market. This is only possible where strategic alignment has
taken place where all projects are part of a concerted effort to
support strategy (Gerow, Thatcher & Grover 2015).
With this lofty goal in mind, it may stand to reason that project
practitioners have very little to do with strategic impact external
to the organisation. Instead, very senior members of the board
tasked with portfolio management are the key role players that
have to ensure that the organisation’s strategic intent is achieved
through the support of the entire organisation. The delivery of
a product through project management methodologies, while
essential, is only one small part of the entire exercise (Kaiser, El
Arbi & Ahlemann 2015).
An enabler of strategic success from a projects perspective
is a concerted strategic alignment initiative that ensures that all
projects are selected on their probability of success and envisaged
contribution to the organisation. Without such an alignment
effort an impact on the market can still be made, however, the
degree of impact would be very uncertain. Unexpected benefits
or issues may arise more frequently in such a case.
Inhibitors to strategic success may include actions to avoid
such as failure to establish a clear strategy and frequently
changing strategy. Both these situations require the entire ship
that is the organisation to change tack, while all its efforts are
focused on achieving and supporting a different strategy.
31
Demystifying project success
External market condition will also influence the degree to
which the current strategy is effective, if the organisation’s chosen
strategy has not been developed with this in mind. Inhibitors and
enablers for the success of Level 5 are much more dependent on
strategic management thinking than purely project management
considerations.
Conclusion
How project success and failure is defined depends greatly
on individual interpretation. When taking the organisational
perspective, perhaps project management success should be
viewed on a continuum and not on a binary scale of ‘success’ and
‘failure’. When drilling down into the details of what technical
and product success actually imply, lower orders of management
need to be aware of what metrics are being used to determine
and track how their scarce resources are being utilised.
Ultimately, the organisation exists to provide value to its
shareholders. This is most significantly achieved through
strategic impacts. However, there is something to be said for
laying the foundation for such success. Success on lower levels
of project management in no way guarantees success on higher
levels. Likewise, failure on lower levels does not guarantee failure
on higher levels. There is, however, an implication that success
on lower levels contributes in some way to success on higher
levels. Failure on lower levels may make success on higher levels
more difficult, yet not impossible.
What is important is that an actual deliverable is created that
can be used to eventually attempt to achieve strategic success
through strategic alignment. In such a way, the organisation can
attempt to snatch victory from the jaws of defeat, and not vice
versa.
32
Chapter 3
Chapter 3
Complexity of
information system
projects
Complexity is a concept which is now more prevalent than
ever (Derbyshire 2016; Vidal & Marle 2008). Geraldi (2008:4)
proclaims that ‘mastering complexity is not a new challenge
but an old challenge that is being increasingly recognized
and accepted.’ Project management literature traditionally
emphasise the success criteria and success factors that are
necessary to understand project performance (Belassi & Tukel
1996; Cooke-Davies 2002; Ika 2009; Pinto & Slevin 1987). Project
management research has evolved over the years to include
the concept of project complexity (Ahern, Leavy & Byrne 2014;
Baccarini 1996; Cooke-Davies et al. 2007). The increased focus
on project complexity is the result of attempts to address
the fluctuating performance of various projects regardless
of industry and type. This chapter aims to elaborate on the
concept of project complexity and constructs which constitute
project complexity.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Complexity of information
systems projects’, in The symbiosis between information system project complexity and
information system project success, pp. 33–61, AOSIS, Cape Town. https://doi.org/10.4102/
aosis.2017.itpsc45.03
33
Complexity of information system projects
The concept of project complexity
Project complexity involves identifying and understanding the
various intricacies embedded in a project. Baccarini (1996:201)
introduced project complexity within the context of construction
projects and argued that project management is ‘associated with
management of complexity.’ The research of Baccarini (1996)
subsequently resulted in the development of a conceptual model
of project complexity. Similarly, Xia and Lee (2004) applied the
concept of project complexity to IS projects and produced a
conceptual model for IS project complexity. Similar literature
works have developed models for project complexity to enlighten
how projects are understood and perceived. Four key models
are identified and discussed in the sections that follow.
omplexity model for new development
C
products
New product development (NPD) projects are commonplace in
many industries but suffer poor performance with regard to time
and cost (Kim & Wilemon 2003, 2009). Kim and Wilemon (2003)
investigated these projects and developed a complexity model
for NDP projects. They argue that NDP projects consist of several
functions and technologies which add to the level of complexity.
Furthermore, the level of complexity faced by functional groups
varies during projects which influences the ‘complexity curve’ of
a project (Kim & Wilemon 2003:18). Kim and Wilemon (2003)
discovered the following sources of complexity:
•• Technological complexities: This source focuses on challenges
with tasks and uncertainties around technology or a
technological approach. Component integration and
technological newness underpin the challenges and
uncertainties. Component integration addresses the complexity
of integrating the various technological parts, systems and
subsystems at the software and hardware level. The aim is to
integrate all components correctly and ensure the system
34
Chapter 3
•
•
•
•
operates effectively. Alternatively, technological newness
looks at how new technology can be used to solve technological
issues. If new technology is not understood, the implementation
of such technology could be detrimental. This applies to the
novel use of existing technology and the introduction of
cutting edge technology. Introducing new technology also
introduces other complexities such as the requirement of new
skills and resources for effective exploitation.
Environmental complexities: The markets in which
organisations and product developers operate are dynamic as
they follow a rapid pace and are unpredictable at the best of
times. These external complexities require organisations to
process data and information more efficiently to remain
competitive and relevant in their industries. It is therefore of
paramount importance to understand market size and growth,
market variability (e.g. regulatory changes), challenges in
predicting competitors and weakness in adapting to market
change.
Development complexities: Complications and complexity
around the research and development processes are the core
of development complexities. Factors underlying research
and development process complexities include, integration of
multiple research decisions, predicting effort, money and time
required for new product development, component
integration, evaluating process requirements for development,
identifying and obtaining quality suppliers and management
of supply chain relationships.
Marketing complexities: Introducing products into new,
untapped markets requires organisations to apply new and
novel marketing skills to penetrate the market. This often
involves conducting intense market and consumer tests. Risk
appetite is an indicator of how organisations will approach
entering a new market. Multiple considerations must be taken
into account such as customer education regarding the
product, introducing new distribution channels, understanding
and managing the needs of a new market, establishing pricing
policies, developing advertising campaigns, user adaptation
and capability level as well as incompatible technologies.
Organisational complexities: The organisational structure
plays a defining role in rolling out NPDs. NPDs require interaction
35
Complexity of information system projects
between multiple business units, departments and employees
which increases the level of complexity. Education and
communication strategies must be thought out as these will
ease the management of organisational complexity.
Furthermore, effective knowledge management and transfer
must exist within the organisation as this enables the application
of new tools, techniques and technologies. Another important
aspect to organisational complexity is that of forming and
managing project teams which include multiple specialists.
Team dynamics such as cultural differences, geographical
location and competency must also be taken into account.
• Intra-organisational complexities: These complexities arise
when organisations partner to achieve a common goal and
pursue NPD projects. The original notion is that collaboration
will not only mitigate other complexity areas but, in turn,
generate other new complexities. Similar to organisational
complexities, intra-organisational complexities consider
aspects such as degree of formality and/or informality,
dependency issues, communication and relationship
management challenges, measuring a collaborator’s
contribution and distributing outcomes equitably.
ovelty, Technology, Complexity and
N
Pace model
Shenhar et al. (2016:68) developed the ‘Diamond of Innovation’
model as a means to tackle project complexity. The model is
also referred to as the Novelty, Technology, Complexity and
Pace (NTCP) model (Frank, Sadeh & Ashkenasi 2011). The model
focuses on project management style selection by assessing the
four dimensions of NTCP. The four dimensions are defined as
follows (Frank et al. 2011):
•• Novelty: The newness of the product is the focus of this
dimension. Three subdomains underpin the novelty dimension,
(1) derivative, (2) platform and (3) breakthrough. Derivative
projects have minor improvements over other products, while a
new generation of products is developed through platform
36
Chapter 3
projects. Innovation projects produce unique and niche products
which are significantly differentiated in the marketplace.
• Technology: Technology and uncertainty are inseparably
linked in this dimension as the use of technology introduces
varying levels of uncertainty. The aim is to reduce the level of
uncertainty by effectively managing the technology employed
in a project. Four types of technological projects exist, (1) low
tech, (2) medium tech, (3) high tech and (4) super high tech.
The more sophisticated the project, the higher the level of
uncertainty and complexity. Alternatively, uncertainty also
determines, amongst other things, duration and scheduling of
tasks and activities, articulating and defining product
requirements, planning precision and risk mitigation strategies.
• Complexity: This dimension specifically looks at product
scope and the interdependencies between various project
components. Complexity directly influences the level of
formality by which the project will be managed as well as the
processes employed.
• Pace: Pace stresses the importance of time goals during a
project as this will influence the project structure and the level
of management attention. There are four apparent levels of
timed goals, (1) regular, (2) fast, (3) time-critical and (4) blitz.
They follow a progressive scale on haste and importance.
Project Complexity Model
The Project Complexity Model (PCM) was developed to
capture the various dimensions of project complexity (Hass
2009). The aim of the PCM is to provide a framework to identify
and analyse complexity elements of a project and facilitate
decision making amongst the project team. Hass (2009) argues
that specific project management tools, methods and approaches
will be determined by which dimensions apply to the project.
The complexity dimensions within PCM are as follows:
•• Strategic importance, political implications and multiple
stakeholders: It is clear there are three subdomains within this
dimension. Strategic importance is associated with the level of
executive support and impact on the mission statement set out
37
Complexity of information system projects
within the organisation’s strategy. Political implications relate
to the internal political landscape of the organisation. Political
issues are often bureaucratic issues and red tape which hinder
or inhibit the project from being performed as initially planned.
If these issues are visible at all levels of management, the project
becomes increasingly complex to manage. Stakeholders play
an important role during projects and the higher the number of
them, the higher the level of project complexity. Multiple
stakeholder groups introduce communication and coordination
challenges as well as conflicting expectations.
• Level of organisational change: The dimension looks at how
the project influences and contributes to organisational
change. Less complex projects have minimal influences such
as impacting one department, business process or IS. Highly
complex projects have widespread influences when the entire
organisation is impacted including internal business units,
multiple business processes, external joint ventures and
information systems. Inevitably, the organisation has to
transform as a result of a highly complex project.
• Level of commercial change: Commercial change pertains to
how the organisation adapts and changes the way they interact
within their industry, including activities such as advertising,
marketing and collaboration. The level of project complexity
directly influences how the organisation implements commercial
change.
• Risks, dependencies and external constraints: Risk increases as
the level of complexity increases. High risk projects carry
increased risk with regard to the above-mentioned dimensions.
Projects are always influenced by internal and external factors.
Dependencies assess the relationship between the various
factors as well as the impact they have on one another. Project
integration efforts are also associated with dependencies as
challenging integrations are often caused by large-scale projects
where multiple elements must be integrated to realise the
project’s goals. External constraints relate to regulatory
requirements within an industry or sector. Operating within a
familiar regulatory environment implies less complexity, whereas
highly regulated environments introduce multiple complexities
when embarking on a new, novel project such as NPDs.
38
Chapter 3
• Level of IT complexity: Information technology is a powerful
tool to implement and be used in projects. This dimension
determines what technology is used for any project type.
Similar to the NPD model, existing and understood technologies
traditionally lead to less complex projects. While innovation
may be the key, the usage of unproven and immature
technology creates complexity where specialist skill sets are
required from external vendors.
I nformation systems development
projects complexity model
The previous models have approached project complexity at a
generic level. The information system development project (ISDP)
complexity model was specifically developed for IS projects as
they ‘are inherently complex because they deal not only with
technological issues but with organizational factors largely
beyond the project team’s control’ (Xia & Lee 2004:70). Xia and
Lee (2004) dissect ISDP complexity into four components:
•• Structural organisational complexity: A number of elements
exist within this component. The level of project manager
control over resources is the most important element as lack of
control implies that the project is driven by other individuals
who are not actively and continuously involved in the project.
User support is the second element. IS projects preferably need
continuous user support and feedback to ensure the output is
a solution which the users need. Insufficient staffing is the third
element identified for structural organisational complexity. The
project cannot meet simple goals such as time and cost if
insufficient staff exists. The fourth element focuses on the
specialised staff and skills required during IS projects. A
deficiency of such staff will have detrimental effects on all IS
project types. The final element, insufficient top management
support, assesses how much support is garnered from senior
management, such as the project sponsor. IS projects cannot
be correctly aligned to organisational strategy if top
management support is lacklustre or non-existent.
39
Complexity of information system projects
• Structural IT complexity: Emphasis is placed on more technical
elements within structural IT complexity. Firstly, the
involvement of multiple user units influences this complexity
component as the different users will have different
perspectives and needs. Cross-functional teams are an
inevitable prerequisite for IS projects. The second element
assesses what level of cross-functionality is apparent as
various internal and external team members are required to
perform the project. Multiple software environments are the
next element within the structural IT complexity component.
IS projects often span various software environments that
further influence how the project is developed and installed.
The next element focuses on multiple technology platforms as
IS projects use a wide range of technologies to realise the
project’s goal. The inclusion of multiple technologies implies
that knowledge and skill are required to implement the
technologies effectively. This also directly relates to the next
element of integration with other systems as compatibility of
technology platforms and software environment come to the
fore. Enterprise-wide IS projects, for example, require full
integration across all systems and platforms to ensure the
users’ needs are met. The final element addresses the
complexity of multiple contractors and vendors. Outsourced
interventions during IS projects are commonplace as the
contractors and vendors assist with the implementation of the
project. Communication and collaboration must be effectively
managed to ensure the project delivers as initially proposed.
• Dynamic organisational complexity: This complexity component
places emphasis on pattern and rate of change during ISDPs.
Change in business processes is the first area of assessment as
IS projects introduce new ways of performing business tasks
and thus re-engineer business processes. Frequency of
information change must be managed as the users’ information
needs change rapidly during IS projects. Patterns regarding
information change must be identified and understood to ensure
the correct information is relayed to users at all times. Similar to
changes in business processes, how the processes are changed
from a user’s perspective is important to understand given that
they are the ones most likely to use the system for day-to-day
activities. Certain IS projects also change the structure of the
40
Chapter 3
organisation itself through the change and/or introduction of
new business processes and functions. Alternatively, a different
view is how a constantly changing organisational structure
influences the project itself. Organisations which rapidly change
structure during an IS project bring about added complexities
to the execution of the project.
• Dynamic IT complexity: The IT infrastructure changes
throughout its lifetime in an organisation. IT infrastructures
can change rapidly given the rapid rate of development within
IT. Constant changes in infrastructure add technical
complexities to IS projects as it becomes difficult to make
decisions when technological uncertainty arises. Furthermore,
there must be careful cognisance of the IT architecture as this
often dictates and influences structural IT complexities.
Software development is a high-paced environment with rapid
movement. Programming languages and tools are constantly
evolving to enhance IS functionality. Rapid change in languages
and tools must be considered at all times as these influence
how the project is executed, implemented and tested.
The above-mentioned project complexity models provide an
overview of project complexity and its subsequent components.
The following section takes an in-depth look at what exactly
constitutes project complexity and applies it to IS projects.
Constituents of project complexity
There are various views on project complexity and no clear
definition or understanding of what exactly constitutes this
phenomenon. This section goes beyond the project complexity
models and analyses in depth how multiple publications
conceptualise project complexity. Textual analysis was performed
through content analysis to identify the underlying components
of project complexity (Flick 2014; Martens & Carvalho in press;
Pade, Mallinson & Sewry 2008). The following research protocol
was applied when conducting the content analysis (Schön,
Thomaschewski & Escalona 2017). Key concepts were first
identified and articulated to develop search terms, for example
41
Complexity of information system projects
‘project complexity, project management complexity, complex
project management.’ Six databases were targeted as they were
identified as the primary databases which cover the key concepts.
Forward and backward sampling were used to enhance content
availability. Forward snowballing searches literature which has
cited the literature in question, while backward snowballing
searches the reference list for literature (Badampudi, Wohlin &
Petersen 2015; Jalali & Wohlin 2012; Schön et al. 2017). The final
step involved manual examination of literature sources to ensure
the concepts were well represented and articulated (Asher 2013;
Dube & Marnewick 2016; Schön et al. 2017).
Five underlying components were identified from the content
analysis, (1) organisational complexity, (2) technical complexity,
(3) environmental complexity, (4) uncertainty and (5) dynamics
(Baccarini 1996; Bakhshi, Ireland & Gorod 2016; Bosch-Rekveldt
et al. 2011; Dunović, Radujković & Škreb 2014; Floricel, Michela
& Piperca 2016; Geraldi, Maylor & Williams 2011; Remington &
Pollack 2007; Senescu, Aranda-Mena & Haymaker 2013; Vidal &
Marle 2008; Williams 1999). An overview of project complexity
components is illustrated in Figure 3.1. Each component
contributes to the level of project complexity to some degree.
The identification of the components is, however, only the first
step as more investigation is required to illuminate what exactly
these components consist of. The content analysis revealed that
each component consists of various elements which, in turn,
consist of various features. The following section delves deeper
into each component and their applicable elements and features.
Organisational complexity
Projects are generally seen as ‘temporary endeavors’ (Schwalbe
2013:4) within an isolated context, but this is far from reality as
they have a greater role within the organisational context. The
organisational context implies that all projects are influenced by
organisational aspects which are rarely taken into account during
all projects and especially IS projects. This section presents the
42
Chapter 3
Organisational
complexity
Technical
complexity
Dynamics
Project
complexity
Uncertainty
Environmental
complexity
FIGURE 3.1: Overview of the components of project complexity (derived from content
analysis).
multiple elements and features which contribute to project
complexity:
1. The first element of organisational complexity centres on
vertical
differentiation
(Baccarini
1996).
Vertical
differentiation deals with the formal structure of the
organisation, that is, whether the organisation has, amongst
others, a functional, matrix or flat structure. Each structure
has varying views on hierarchy as a functional structure has
strict levels of command, whereas a flat structure has no
43
Complexity of information system projects
levels of command effectively (Hobday 2000). The varying
structures influence project execution particularly as
communication and collaboration is different depending on
the structure (Geraldi et al. 2011).
2. Horizontal differentiation is the second element within
organisational complexity (Baccarini 1996). Two features form
the foundation of this element, that is organisational units and
task structure. Regardless of structure, each organisation has
organisational units which serve a particular purpose. The
number of units varies in each organisation and must therefore
be taken into account from a project complexity perspective
(Dunović et al. 2014). Task structure places focus on how
project tasks are divided and distributed to the relevant
responsible parties (Lu et al. 2015). This is particularly
important during the planning stage of a project, and thus
particular attention should be paid to defining tasks as best as
possible. Tasks are, however, not set in stone and are prone to
change during the project.
3. Organisational complexity’s third element is that of size, which
consists of multiple features:
•• Project duration: This feature relates to the constraint
of time (Bosch-Rekveldt et al. 2011). Time is commonly
used as a criterion for determining project success. Its
representation within project complexity is arguably
less vital given the sheer number of other complexity
elements and features to consider. Nevertheless, the
inclusion of duration is important as all projects have a
time goal in which they want to be operational. With
regard to IS projects, time is an important feature to
consider as these projects are launched to achieve or
maintain competitive advantage.
• Project method and tool variety: The project
management landscape is awash with various methods
and tools. Information system projects, for example, are
more commonly adopting the philosophy of Agile as a
new approach to deliver projects (Chan & Thong 2009).
The Agile landscape, however, is not simple as there
are multiple methods which can be chosen and used, for
example scrum, extreme programming, rapid application
44
Chapter 3
•
•
•
•
•
development and dynamic systems development
methods to name a few. Selecting from multiple methods
can become difficult especially when there is a lack of
understanding and knowledge amongst the project team
regarding the details of the method. Methods cannot be
adopted based on ‘buzzword’ status as this negates any
potential benefit from adopting the method(s).
Capital expenditure: This feature relates to the
constraint of cost (Bosch-Rekveldt et al. 2011). Significant
sums of money are spent on IS projects, which implies
their strategic importance to many organisations
(Joseph & Marnewick 2014). Cost is therefore an
important feature as failed projects do occur at the cost
of millions and reflect badly on the implementation of
other IS projects.
Work hours: Many hours are spent on projects of all
types to realise the project and business goals (Thomas
& Mengel 2008). The number of work hours is determined
by the scale of the project as well as the task structure.
Work hours should be meticulously managed during
large-scale IS projects particularly as there are a
multitude of interdependencies. Moreover, the number
of work hours is heavily influenced by IS projects which
span geographical regions.
Project team: The size of a project team directly
influences project complexity (Bosch-Rekveldt et al.
2011). Large teams include individuals from multiple
departments, thus introducing heightened levels of
complexity. The management of large teams can become
cumbersome for project managers as communication
and collaboration breakdowns are highly likely.
Site area: The physical size of the project site(s) is
important to identify as this will influence certain aspects
of the project (Bosch-Rekveldt et al. 2011). While the
initial plans dictate project activities amongst other
things, careful attention must be paid to how the physical
attributes of the site will influence these activities.
Number of locations: As mentioned previously,
geographically dispersed projects are commonplace
45
Complexity of information system projects
within multinational organisations particularly. These
dispersed projects affect project complexities such as
logistics where travel and access must be considered
when executing the project (Padalkar & Gopinath 2016).
IS projects often implement systems which span
offices across the globe and thus should be fully
integrated. Full integration, therefore, requires a robust
understanding of the locations where the system must
function.
4. The element of resources emphasises tangible and intangible
resources required for any given project. The following
features must be considered for the fourth element of
organisational complexity:
•• Project drive: Strategic goals underpin the need and
execution of IS projects. Project drive, therefore, pertains
to the level of strategic importance and support required
for a project (Milis & Mercken 2002). Inadequate support
implies that the project will not be aligned to the overall
goals of the organisation and thus not deliver the
benefits as initially stipulated. The drive of the project
must therefore be sound and understood by all parties
involved to ensure it realises the greater strategic goal.
• Resources and skills availability: Different projects
require different skills and resources even if the projects
seem similar on paper (Baccarini 1996). Specific
resources with regard to raw materials must be clearly
identified and acquired to implement the project
correctly. Project complexity is aggravated when
projects such as IS projects require very specialised
skills which need to be sourced externally. External
vendors are often brought in to provide these skills,
which add other complexity layers such as project team
composition, capital expenditure and work hours.
• Experience with parties involved: Stakeholder
management and its importance are documented in
project management standards such as the PMBOK®
Guide (Project Management Institute 2013). Experience
with involved stakeholders and parties creates somewhat
of a more predictable landscape during a project as
46
Chapter 3
•
•
•
•
there is a better understanding of the parties involved
(Bosch-Rekveldt et al. 2011). Unknown parties require
extra effort from the project manager and team as they
will have to engage more to ensure they perform as
required.
Health, safety, security and environment (HSSE)
awareness: HSSE is traditionally associated with
construction projects and not IS projects. HSSE should,
however, be applied to all projects as there are national
regulations overseeing the implementation of HSSE
(Bosch-Rekveldt et al. 2011). Project managers in
particular should be aware of all HSSE concerns in a
project as this will mitigate any possible litigation arising
from regulatory bodies.
Interfaces between disciplines: Cross-disciplinary
integration is inevitable in projects as specialists from
various fields are required to execute certain tasks
(Baccarini 1996). The interfaces or interactions between
the various disciplines must be identified and managed
accordingly as this influences other areas such as skills
availability, works hours, capital expenditure and project
duration, to name a few. The more disciplines required
for the project, the higher the level of project complexity.
Financial resources: Projects cannot be executed
without sufficient availability of financial resources
(Killen & Kjaer 2012). Financial resources, however,
should be managed in a sustainable manner to ensure
they are distributed correctly and not squandered on
ineffective tasks and resources. As mentioned before, IS
projects require significant expenditure but do not
always translate these financial resources into
organisational benefits.
Contract types: Resources are procured from various
suppliers, whether internal or external. Regardless,
contracts are negotiated and signed to ensure the required
resources are available for a project. Contractual
agreements and arrangements often become intricate and
complex and thus add to the complexity of a project
(Bosch-Rekveldt et al. 2011).
47
Complexity of information system projects
5. Intricacies relating to the project team are the fifth element
within the organisational complexity and consist of the
following features:
•• Different nationalities: Projects do not need to be
geographically dispersed to have the complexity of
different nationalities working on the project. The key to
different nationalities is that of understanding national
cultures and ensuring that they are understood and not
offended (Geraldi et al. 2011). Productive project teams
understand their boundaries and limitations when
working with different nationalities. Furthermore, it is the
responsibility of the project manager to manage these
cultural relations and mitigate any possible conflicts.
• Different languages: Different nationalities also
introduce difficulties associated with language (BoschRekveldt et al. 2011). Language barriers imply that team
members and stakeholders cannot understand one
another enough to effectively execute the project.
Language issues also arise when the main language
used for a project is not the first language for some
parties involved. It is therefore important that this social
aspect is identified early on and possibly before the
project initiates as this will ensure the project does not
experience difficulties during the project.
• Joint-venture cooperation: Many projects are executed
as a joint venture between two or more organisations
(Geraldi & Adlbrecht 2007). The roles and responsibilities
of each organisation must be clearly articulated before
project initiation and planning as they will dictate the
way forward for the project. Organisations could
perform the same tasks differently as they have varying
management styles and structures. Cooperation
between the parties involved should therefore be
documented and made transparent to all to ensure a
common understanding between all parties.
• Office hour overlaps: Overlapping of office hours
primarily occurs in projects which are executed in
multiple time zones. The project manager and team
48
Chapter 3
must be cognisant that certain tasks and activities can
only occur when there is office hour overlap between
time zones (Geraldi et al. 2011). On the other hand,
there could be instances where overlapping hours
could be minimal thus creating a heightened level of
complexity. It is therefore imperative that there is a clear
understanding amongst those operating within different
hours to ensure effective communication occurs during
the project.
6. The sixth element focuses on two features of trust, that is trust
within the project team and in the contractor (Bosch-Rekveldt
et al. 2011). The project team must operate as efficiently as
possible to ensure they deliver what is expected by the business.
The team would thus work best when trust is apparent between
all those involved (Geraldi & Adlbrecht 2007). Moreover, this
relates to the feature of experience with involved parties as
more experiences can arguably translate to increased trust to
perform certain tasks and activities. Similarly, trust must exist
with the contractor or outside vendor (Geraldi et al. 2011).
Trust in a contractor does not only entail trusting that they
play their part but, more importantly, that they provide the
required skills and knowledge needed for executing the
project. Trust is a social paradigm which is more focused on
soft aspects such as people management than on hard aspects
such as technical requirements management.
7. Risk is the seventh element within organisational complexity
where emphasis is placed on organisational risk specifically
(Bosch-Rekveldt et al. 2011). Thamhain (2013) asserts that there
are four categories of risk, (1) no impact on project performance,
(2) actual impact on project tasks and subsystems, (3) actual
impact on project performance and (4) actual impact on project
and enterprise performance. Category four of risk therefore
implies that the entire organisational performance is at
stake if project risk is not addressed. Risk can, however, be
mitigated through continuous stakeholder communication and
collaboration (Floricel et al. 2016).
8. Projects are fraught with interdependencies which further
complicate matters. Interdependencies are thus the eighth and
49
Complexity of information system projects
final element of organisational complexity. Interdependencies
consist of the following features:
•• Environmental dependencies: These span the internal
and external operational environment in which the
organisation operates (Vidal & Marle 2008). The
implication is that both environments must be surveyed
and understood as best as possible to ensure the project
is not negatively affected by underestimating its
environmental dependencies.
• Resource sharing: Organisations execute multiple
projects at once and thus share resources between them
(Vidal, Marle & Bocquet 2011). Furthermore, the same
resources are often shared with day-to-day activities
which further escalate project complexity. Resources are
not infinite and must be managed accordingly between
all relevant parties. It is predominantly the project
manager’s responsibility to ensure that required resources
are available when needed and to liaise with other project
managers for effective resource management.
• Schedule dependencies: Similar to resource sharing,
schedule dependencies require the same attention as
certain project activities, and tasks are conducted
sequentially while other tasks are run in parallel. A lack
of schedule dependency understanding inevitably
introduces increased complexity which could lead to
chaos within a project and subsequent project failure
(Baccarini 1996).
• Interconnectivity and feedback loops in task and project
networks: Communication is at the heart of this feature
as the emphasis is on feedback loops between the parties
involved (Vidal et al. 2011). There must be a clear level of
transparency amongst all stakeholders as this enlightens
and reassures what tasks have been performed as well as
the status of the task.
• Dependencies between actors: All project stakeholders
have some form of dependency on one another (Padalkar
& Gopinath 2016). Any project which is not cognisant of
that will perform poorly and not as intended. It is,
however, important that there are not an exorbitant
50
Chapter 3
•
•
•
•
•
number of communication and collaboration channels
and platforms as this will compromise and distort any
work being done.
Information systems dependencies: Various information
systems are used as a source of information during a
project (Baccarini 1996). The relationship between these
systems is important as not all systems provide the
same functionality. Furthermore, the technical nature of
information systems is important to understand to
ensure the most benefit is gained from them. There is
arguably a link between this element and skills availability
as the use of these information systems often requires
specialised skills to extract the maximum benefit.
Objective dependencies: Each project has goals which
are linked to greater strategic goals. The relationship
between them is important as there should be clear
and strict alignment between the project and strategic
goals (Vidal et al. 2011). Furthermore, the relationship
between the various project goals must be clearly
articulated as they work in tandem to realise strategic
goals.
Process interdependencies: Project management is a
process-based activity where each process serves a
function and feeds into another. Alternatively, projects
operate within daily business processes, and thus the
relationship between project and business processes
must be identified and managed accordingly to reduce
increased project complexity (Padalkar & Gopinath
2016).
Stakeholder interrelations: Both internal and external
stakeholders interact during a project’s lifecycle. These
interactions and interrelations directly influence the
level of project complexity as information and resources
are shared between these stakeholders to realise the
project’s goal (Baccarini 1996).
Team cooperation and communication: There is constant
reference to communication and cooperation in multiple
project complexity features, especially with regard to the
project team (Geraldi & Adlbrecht 2007). Internal feedback
51
Complexity of information system projects
loops amongst team members is critical to ensure the
project delivers as expected and project complexity is
managed effectively.
Technical complexity
Technical complexity originated from technological complexity
where the emphasis was on technology and its intricacies
(Baccarini 1996; Brown 2008). Over time, however, technical
complexity expanded to include elements and features which
place more emphasis on detailed aspects of a project (BoschRekveldt et al. 2011; Floricel et al. 2016). The following elements
constitute technical complexity:
1. Differentiation regarding inputs and outputs is the first
element of technical complexity (Green 2004). Project
processes and activities have various inputs and outputs
during the project’s lifecycle. The number and diversity of
inputs and outputs must be considered under the greater
umbrella of project complexity (Baccarini 1996). A large
number of inputs and outputs implies that there are multiple
interconnected parts which must be managed accordingly in
a process-driven environment such as project management.
On the other hand, the diversity and scale of the inputs and
outputs play a role in the level of importance of each
overarching process in which they operate. Project complexity
is therefore influenced by the number and diversity of inputs
and outputs as they underpin the project management
process itself.
2. The second element of technical complexity focuses on
project goals (Bosch-Rekveldt et al. 2011). Project goals
have been referred to in the project drive and objective
dependencies features in organisational complexity and,
again, in technical complexity which reiterates the
importance of understanding the project goal dynamic. The
first feature within project goals is that of the number of
goals. The more goals there are to achieve the more complex
the project becomes (Gällstedt 2003). This leads directly to
52
Chapter 3
the second feature, goal alignment, where the goals should
be aligned to one another and the strategic goals (Geraldi &
Adlbrecht 2007). Project goals which contradict one another
imply that the project is destined for failure as there is no
common ground or vision on what the project must achieve.
Goal alignment subsequently leads to the third feature of
goal clarity. Goals which are understood and transparent
to all the stakeholders are the key to the successful delivery
of a project (Shenhar, Levy & Dvir 1997). Conflict and
contradicting goals should be avoided at all costs as
previously mentioned.
3. Scope is the third element and focuses on scale of scope and
quality of requirements (Bosch-Rekveldt et al. 2011; Floricel
et al. 2016). The requirements dictate what a project should
achieve once they are completed. The scale of scope therefore
refers to what requirements must be successfully implemented
for the project to deliver business benefits (Vidal & Marle
2008). On the other hand, the quality of requirements is more
specific as it looks at whether the documented requirements
are well detailed and understood (Floricel et al. 2016). Quality
requirements should be correct, unambiguous, complete,
consistent, prioritised for importance and/or stability, be
verifiable, modifiable and traceable (Marnewick 2013). The
omission of any of these attributes implies that the level of
project complexity will be raised and that the project will not
deliver as initially planned.
4. Technical complexities relating to project tasks is the fourth
element to consider. Firstly, the number of tasks plays an
influential role as projects with many interconnected tasks
are more cumbersome to manage, as discussed in the
interdependencies element of organisational complexity
(Heaslip 2015). The number of tasks also relates to the
number of inputs and outputs as certain tasks act as inputs
while others act as outputs. Secondly, the variety of tasks
speaks to the varying difficulty and speciality of tasks as not
all tasks are equal and some are more specialised than others
(Senescu et al. 2013). Thirdly and finally is the feature of
conflicting norms and standards (Bosch-Rekveldt et al.
2011). This feature focuses on the misunderstanding of
53
Complexity of information system projects
organisational standards and procedures other than project
management ones. Although organisations strive to achieve
congruence amongst all standards there are spaces where
this is not the case. It is essential to discuss any conflicting
standards and decide on the best way forward before the
project is adversely affected.
5. Experience within technical complexity refers to technological
experience specifically. Experience with regard to new and
current technology is the focus of this element. New
technology is often punted as performing the same tasks
better and more efficiently, but the problem arises when the
new technology needs to be implemented as part of the
project (Tatikonda & Rosenthal 2000). A barrier to adopting
new technology is that of understanding as the project team
should understand the technology and how it will influence
the entire project if implemented. Experience with technology
is therefore important as the more experienced the team is
with the technology, the more likely they will be able to
implement it correctly (Tatikonda & Rosenthal 2000). Projects
which boldly implement new technology often suffer many
side effects such as integration issues and lacklustre user
acceptance as the technology is not thoroughly investigated
and understood.
6. The final element is that of technical risk where the focus is on
technological risks (Deutsch 1991). Technological risks include,
amongst others, what technology will be used, will the
technology integrate correctly, availability of technology and
whether technology will be obsolete before project completion
(Ahmed 2012:343). Furthermore, the frequency and impact of
these risks must be taken into account to ensure the project is
not adversely affected.
Environmental complexity
Organisations operate within various industries, and the projects
they initiate are influenced by the dynamics of these environments
(Bosch-Rekveldt et al. 2011). This project complexity component
54
Chapter 3
further illustrates that projects are not entirely isolated
endeavours as traditionally believed.
1. The first element focuses on stakeholders specifically and
their intricate role in projects. The stakeholder element
consists of various features:
•• Number of stakeholders: Stakeholder numbers have
a positive relationship with the level of project
complexity, that is, the more stakeholders there are, the
more complex the project becomes (Vidal & Marle
2008). Management of all stakeholders is important to
ensure there is consistent understanding by all the
participants.
• Varying stakeholders’ perspectives: Management of
stakeholders must also include an awareness of varying
perspectives, that is each stakeholder views the project
and its status in a different light (Bosch-Rekveldt et al.
2011). For example, senior management views the
project in a strategic light, while operational staff
assess the project with regard to how it will influence
their daily activities.
• Political influence: This can be viewed from both an
internal and an external perspective (Floricel et al. 2016).
The internal perspective looks at political influence
within the organisation, such as when the project team
is pushed by senior management to implement the
project as soon as possible for strategic goal realisation.
Alternatively, external political influences focus on
politics at the national and international level (Vidal &
Marle 2008). This is often through regulation and
legislation by which the organisation and project must
abide.
• Internal support: Projects must benefit from some
form of internal support for them to be successfully
implemented (Geraldi & Adlbrecht 2007). Senior
management in particular, should be heavily
involved in and continuously support the project
throughout its lifecycle. Lack of support has often
55
Complexity of information system projects
reared its head as a key factor influencing project
failure (Hastie & Wojewoda 2015; Joseph, Erasmus &
Marnewick 2014).
• Required local content: Many nations require
organisations to make use of local content and resources
as a means to ensure the organisation contributes to
economic growth and does not merely exploit national
resources.
2. The second element of environmental complexity centres
on the location of a project. The first feature deals
with interference with an existing site where any possible
interference with the project site is identified and understood
(Bosch-Rekveldt et al. 2011). Once identified and understood,
these interferences can be managed accordingly to avoid
adverse impacts on the project. Weather conditions are the
second feature within the location element. Projects operate
in geographically dispersed regions, and the effect the
weather has on the projects must be analysed beforehand
as weather can have a detrimental effect during project
execution particularly (Sohi et al. 2016). Alongside weather is
the remoteness of the location where some project locations
are isolated from business hubs and thus require special
attention regarding resources and logistics (Nguyen et al.
2015). The final feature focusses on country experience.
Similar to experience with involved parties in organisational
complexity, organisations which initiate projects in regions of
which they have experience are more likely to have fewer
hurdles than when introducing a project in a completely new
region (Floricel et al. 2016).
3. Market condition is the third element. A more specific
political influence of internal strategic pressure is the first
feature within market conditions (Bosch-Rekveldt et al.
2011). The project manager and team are prone to increased
pressure especially when the project in question is the
primary driver of a new strategic direction in the organisation.
The stability of the project environment also plays a role and
is the second feature to consider. Project environment
stability is primarily determined by the organisation’s
56
Chapter 3
stability regarding operations (Geraldi et al. 2011).
Organisations which are unstable and barely functioning
imply that the project has a minimal chance of being
executed correctly. The final feature is that of competition
level with regard to the organisation’s competitors (Senescu
et al. 2013). Increased competition requires an organisation
to act swiftly by using projects to push out products and
services quickly to ensure they remain competitive in their
relevant industry.
4. Environmental risk is the final element in environmental
complexity. Environmental risk focusses on man-made and
natural disaster risks (Floricel et al. 2016; Thomé et al. 2016).
On the other hand, risks associated with the elements and
features of environmental complexity should also be
considered within this element.
Uncertainty
Uncertainty is a concept centred on doubt with regard to the
various elements and features of project complexity (Williams
1999). The question, however, is how any level of doubt will
be managed to ensure any negative effect is mitigated during
a project. The first step is to identify the main elements of
uncertainty as this will assist doubt management. Various
elements constitute uncertainty in the project complexity
context:
1. Uncertainty regarding the traditional project management
triple constraint should be evaluated (Bosch-Rekveldt et al.
2011; Geraldi et al. 2011; Thomé et al. 2016). Uncertainty
about scope is arguably embedded in the scope element of
technical complexity as much emphasis is placed on project
requirements. Furthermore, scope creep and poor scope
management are commonplace during projects where
strategic pressure coerces the project team to take on a
project which is unfeasible or unrealistic. The same could be
argued for the next two features of cost and time uncertainty
where unrealistic budget and schedule expectations are set
57
Complexity of information system projects
for the project which are not met. Alternatively, cost and time
uncertainty also comes to the fore when there are outside
influences which were not expected such as Brexit (Dhingra &
Sampson 2016).
2. The second element of uncertainty concerns project
activities. Multiple project methods are available for
managing projects and uncertainty regarding these methods
inevitably arise (Vidal & Marle 2008). As mentioned
previously, this is particularly the case when adopting new
methods. On the other hand, it cannot be assumed that
all parties understand the method being used when
introducing new stakeholders and/or project team members
during a project. Method uncertainty leads to the next
feature of task uncertainty as project tasks are directly
influenced by the method being used (Maylor, Vidgen &
Carver 2008). Task and method uncertainty can be mitigated
by having adequate support structures and platforms in
place to which stakeholders and project team members can
refer.
3. Goal uncertainty is the third element which focuses
specifically on project goals and objectives (Geraldi et al.
2011; Maylor et al. 2008). This speaks to goal alignment and
clarity in technical complexity as uncertainty can be alleviated
by ensuring these two features are correctly addressed. The
core idea is that all parties are on the same page throughout
the project. Furthermore, effective communication and
collaboration will underpin transparent understanding
amongst all the participants.
4. Technological uncertainty is very specific and speaks to all
technological elements and features discussed previously.
Technological maturity and novelty are the two features
which underpin this uncertainty element. Whitney and
Daniels (2013) assert that a key feature of complex IS projects
is that of new technology which has not yet been fully
developed and tested, that is immature and novel technology.
Many projects, however, are deemed failures as the immature
and novel technology was not implemented correctly and
thus did not deliver expected business benefits. It is therefore
essential that novel and immature technology is understood
58
Chapter 3
and that there is a balance between new and old technology
for projects pursuing this route (Tatikonda & Rosenthal
2000).
5. Stakeholder uncertainty is the fifth element and refers to
undisclosed participants and competency. The overarching
nature of projects such as IS projects requires involvement
from multiple departments and business units. This could
arise when certain participants are not identified and their
presence is not disclosed and disclosed until later in the
project (Maylor et al. 2008). Omitting participants could lead
to incorrect or incomplete information being sourced. The
project manager must therefore continuously check if all the
required participants have been disclosed during the early
stages of the project. Competency is also a key feature which
is underestimated (Maylor et al. 2008). Many projects go
ahead on the assumption that all stakeholders have the
knowledge required for executing the project successfully.
This may not necessarily be the case, however, as key
individuals could be left out as mentioned previously.
Furthermore, competency research argues that although IS
project stakeholders deem themselves competent, the
mediocre performance of IS projects questions that notion
(Marnewick, Erasmus & Joseph 2016). If there are questions
around competency, support structures and materials must
be in place to mitigate any negative influences.
6. Information uncertainty is the last element to consider and
the focus is on incomplete information. Accurate and
complete information is an undeniable prerequisite for all
projects as this ensures the project is driven correctly (Vidal,
Marle & Bocquet 2007). Incomplete information can arise in
many forms such as, amongst others, undisclosed participants,
conflicting norms and standards, unclear goals, cooperation
and communication as well as trust.
Dynamics
Dynamics concerning project complexity refer to the element of
change management specifically. The change process is the first
59
Complexity of information system projects
feature to consider as it should be as robust and adaptable as
possible (Whyte, Stasis & Lindkvist 2016). Poorly defined change
processes imply that changes are not instituted correctly or
managed effectively thus negating any possible improvements
to a project. The number of changes is also important as projects
which exhibit multiple changes at once imply the project was
poorly planned from the outset (Geraldi & Adlbrecht 2007). A
combination of poorly-defined change processes and a high
number of changes points to an inevitable outcome for a project.
Changes are initiated for various reasons which influence the
scope of changes. For example, some changes might be minor
while others are widespread and more important (Whyte et al.
2016). Frequent changes are also a red flag during projects as
the implication is that there was poor planning and/or previous
changes were not carried out correctly thus resulting in high
levels of reworking (Muller, Geraldi & Turner 2012). Along with
the above-mentioned change management dynamics is that of
impact. The impact of changes must be clearly understood and
analysed before implementation as some changes are too risky
to the outcome of the project and should rather be deferred to
future projects or project support activities (Geraldi et al. 2011).
The final feature assesses change over time. Change over time is
the monitoring and controlling of the above-mentioned features
to ensure the project continues in the correct direction (Maylor
et al. 2008).
Conclusion
This chapter revealed that project complexity is ironically
complex to catalogue and understand. Five complexity
constructs were identified based on an extensive literature
review, that is organisational complexity, technical complexity,
environmental complexity, uncertainty and dynamics. Within
each construct there are various elements and features.
A total of 75 features across all constructs were identified
and discussed. Organisational complexity makes up the bulk
60
Chapter 3
of complexity features as this construct has 34 in total. The
remaining four constructs were fairly evenly divided, which
implies that organisational complexity is the one construct that
needs considerable attention.
61
Chapter 4
Insights into
information system
project success
This chapter focuses on project success and how the respondents
perceived project success within their respective environments.
The first section of the chapter focuses on the general information
with regard to the type of respondents and the type of projects
that organisations implement. This analysis provides us with a
general understanding of what the IS project landscape looks like.
The second part of the chapter focuses on project success itself
and how successful IS projects according to the five levels as per
Bannerman and Thorogood (2012) are. Specific attention is given
to the difference between Agile and Waterfall as methodologies
to implement IS projects.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Insights into information
s ystem project success’, in The symbiosis between information system project complexity
and information system project success, pp. 62–80, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.04
62
IT
s
es
in
1.6
2.3
3.4
3.7
4.1
4.4
6.0
6.5
9.6
Pr
oj
an
al
ys
t
m
an
ag
Pr
og
er
ec
ra
tl
m
ea
m
de
e
Po
r
m
an
rt
fo
a
ge
lio
r
m
an
a
A
ge
ss
Pr
r
is
oj
t
Pr
an
ec
oj
t
t
ec
PM
co
ti
or
Ite
m
di
ra
Pr
pl
na
tio
em
oj
to
ec
n
en
r
m
tm
ta
an
tio
an
ag
ag
n
er
m
em
an
en
ag
tc
er
on
su
lta
nt
10.7
13.0
15.9
PM
er
or
ni
O
th
Se
us
B
Pr
oj
ec
tm
an
ag
er
18.7
Chapter 4
FIGURE 4.1: Job description.
General information
The results in Figure 4.1 illustrate that various job titles exist
within the IS project management domain. The majority of
the respondents (31.7%) are either project managers or senior
project managers. The results also highlight that each and every
one of the respondents is involved in IT and specifically within
the discipline of project management.
Figure 4.2 indicates that organisations are involved with
various types of IS projects covering the full spectrum. The
majority of the projects (46%) are concerned with either the
full implementation of IS systems or solutions or the upgrade
of these systems (17%). This highlights that organisations are
permanently in turmoil as they are constantly changing or
upgrading the systems. This places enormous pressure on the IT
division as well as the users of the various systems.
63
Insights into information system project success
Integration,
11%
Customisation,
11%
System implementation
(full), 46%
Infrastructure,
15%
System implementation (upgrade)
17%
FIGURE 4.2: Type of information system projects.
The results in Figure 4.2 also highlight that customisations
and integrations are only about a fifth of the IS projects. It
must be noted that these are specific IS projects focusing on
customisation and integration. There might be customisations
and integrations within the full system implementations as well
as the upgrades.
Customisations and integration make use of various
development methodologies, and this is displayed in Figure 4.3.
The majority of these types of IS projects make use of either
the Agile method (41%) or the more traditional Waterfall method
(31%). A small percentage (8%) are starting to embrace Lean
and DevOps as ways to implement software solutions. A fifth of
IS projects incorporate other methodologies to customise and
integrate software solutions.
A cross-tabulation between the type of project and the
development method resulted in Figure 4.4. An interesting point
of observation is that full systems implementation incorporate
Agile as a method almost three times more than when an upgrade
64
Chapter 4
Other, 20%
Lean, 2%
Agile, 41%
DevOps, 6%
Waterfall, 31%
FIGURE 4.3: Development method.
Agile
System implementation:
upgrade
8%
System implementation:
full
22%
Integration
Infrastructure
2%
5%
2%
DevOps
4%
4%
Customisation
Waterfall
2%
4%
Lean
1%
Other
3%
17%
1% 5%
2%
3%
0%
2%
3%
6%
FIGURE 4.4: Crosstab between type of project and development method.
is performed. This might have to do with the fact that full systems
implementation is more pressured for delivery than upgrading
the system.
The next section focuses on IS project success, and the
discussion is based on the five levels of IS project success where
the first level focuses on the technical processes of an IS project.
65
Insights into information system project success
Project success
This section analyses the success of IS projects based on the
model of Bannerman (2008). Each level is analysed to determine
the level’s success. This analysis is done for the overall results
but also for IS projects that used Agile and Waterfall as a method
within the IS project.
Process success
This level focuses on the various technical and managerial
processes that are important at different times throughout
the project life cycle (Bannerman 2008). Technical processes
in this context refer to conducting the actual work to produce
a deliverable, while managerial processes refer to the oversight of
the afore-mentioned processes. On average, IS projects are 64%
successful in the deployment of either a technical or managerial
process. The detailed breakdown is illustrated in Figure 4.5. The
results indicate that IS project managers actually spend time
and effort on the selection, implementation and integration of
technical and managerial processes. In two-thirds of the instances,
these processes are aligned with the project’s overall processes.
However, two-thirds of IS projects cannot be perceived as
successful as they do not incorporate technical and managerial
processes into the IT project.
The results in Figure 4.5 compare the Agile and Waterfall
methods. Figure 4.6 clearly indicates that IS projects that use
Agile as a method are successful in incorporating technical and
managerial processes. In 88.25% of the instances, technical and
managerial processes are successfully incorporated. In 92%
of the cases, Agile processes are aligned with the project and
organisational strategies.
The results portrayed in Figure 4.6 are in stark contrast to
the results portrayed in Figure 4.5. The results highlight the
underlying factor why IS projects continue to fail. The Waterfall
66
Chapter 4
70%
65%
66%
64%
64%
63%
60%
55%
50%
Alignment
Implemented
Chosen
Integrated
FIGURE 4.5: Process success.
Agile
Chosen
86%
48%
Integrated
87%
45%
Implemented
88%
47%
Alignment
92%
48%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Waterfall
90%
100%
FIGURE 4.6: Process success (Agile vs Waterfall).
67
Insights into information system project success
processes are not successfully managed and in only 47% of the
cases are the processes successfully managed. This is a difference
of 41.25% compared to the Agile processes indicating that Agile
processes are better managed than the Waterfall processes.
The results of the study indicate that Agile as a method
provides an advantage and that the integration, implementation
and alignment of Agile processes are more successful than the
integration, implementation and alignment of Waterfall processes.
The second level of success is based on the project itself, that
is, was the project delivered within the constraints of time, cost
and scope?
Project success
The constraints of time, cost and scope are the original project
constraints (Marnewick & Labuschagne 2012). The IT industry
adopted these constraints from the engineering discipline and IS
projects should also be delivered within these constraints. Most
of the research that focuses on IS project success rates use the
triple constraint as the basis for their analysis.
Figure 4.7 compares the cost and time constraints against the
type of IS projects. In four of the instances, IS projects do cost
more than what was originally budgeted. The only difference is
with integration projects where the actual cost is 133% cheaper
than the budgeted cost. When these types of projects are left
out of the equation, then IS projects are on average 16% more
expensive than originally budgeted. This implies that 16 cents
must be added for every one rand that is budgeted.
The time constraint shows the same kind of tendency as that
of the cost constraint. The results indicate that IS projects, on
average, take almost 2 months longer. The biggest discrepancy
occurs with the implementation of full IS systems. These projects
take 3 months longer than anticipated.
The results do not paint such a bleak picture. Although IS
project managers should strive to deliver the project within
68
Chapter 4
Actual Cost
Orginal Budget
Planned Time
Actual Time
18.00
30%
20%
10%
R 8 865 278.86
R 29 389 832.93
40%
9.37
R 12 102 987.69
12.46
11.51
10.06
0%
14.00
12.00
10.00
6.00
4.00
2.00
pl
(u em
pg en
ra ta
de tio
) n
em
(f en
ul ta
l) ti
o
pl
Im
Im
n
n
ra
tio
te
g
In
C
us
to
m
tr
is
uc
at
tu
io
re
n
0.00
fr
as
In
16.00
8.00
R 8 921 321.34
10.51
50%
12.87
11.32
R 20 751 185.76
60%
11.85
15.29
R 17 685 095.86
70%
13.98
R 43 288 878.07
80%
R 9 567 182.51
R 35 083 112.24
90%
R 18 553 474.98
100%
FIGURE 4.7: Cost and time comparison.
the constraints of time and cost, the deviance is not as bad
as anticipated. IS projects are delivered 3 months later at an
additional cost of 16 cents to a rand.
Table 4.1 presents the comparison between Agile and
Waterfall methods. It is interesting to note that Agile projects are
30% more expensive than the original budget. Waterfall projects
are, on the contrary, 11% cheaper than originally budgeted. When
Agile and Waterfall projects are compared with each other about
time, then Waterfall projects take 18% longer than estimated and
Agile projects take 12% longer than estimated.
The results presented in Table 4.1 convey a mixed message.
According to the literature, Agile projects should be delivered
quicker and cheaper than Waterfall projects but this is not the
case in this instance. This study itself was of a quantitative
69
Insights into information system project success
TABLE 4.1: Cost and time comparison: Agile versus Waterfall.
Cost and time
Agile
Waterfall
Original budget
R 5 526 876.09
R 39 398 302.94
Actual cost
R 7 882 681.12
R 35 396 477.77
Original time
9.60
15.22
Actual time
10.91
18.63
nature and no evidence is uncovered why these discrepancies
exist. It might be useful to conduct interviews with the
various IS project managers to uncover the truth behind these
discrepancies.
The third constraint is the scope of the project. In the context
of a project, scope is defined as the features and functions that
characterise the project’s deliverable (Project Management
Institute 2013). The majority of IS projects deliver on the scope
of the project with 87.5% of these projects delivering on the
scope between 60% and 100% of the time. Figure 4.8 shows the
comparison between Agile and Waterfall projects. There is no
difference between these two methods when it comes to the
delivery of the scope. Agile projects deliver in 87.5% of the cases
between 61% and 100% of the scope in comparison with Waterfall
projects that deliver 89.5% of the scope.
When Agile and Waterfall methodologies are compared with
each other with regard to the triple constraint, then there is not
much difference between the two methods. Project success is
therefore not dependent on the method that was chosen.
The third level of success measures the product itself and
focuses on aspects such as meeting the specifications, meeting
requirements, meeting client and/or user expectations and the
final acceptance of the project deliverable by the user.
Deliverable or product success
The success of the project deliverable or product was measured
around seven criteria as illustrated in Figure 4.9. A weighted
70
Chapter 4
Agile
70
Waterfall
62.3
60
50
40
30
27.2
61
20
26.5
7.4
10
0
1
2.5
3
8.5
< 20%
21%–40%
41%–60%
61%–80%
> 80%
FIGURE 4.8: Scope comparison (Agile vs Waterfall).
average score was calculated for each of the seven criteria.
The results show that the deliverable is only perceived as 68%
successful when success is determined across all seven criteria.
This implies that close to a third of the users are not satisfied with
the project deliverable and that they are actually not using it at all.
The results indicate that business analysts are fairly competent
in determining the product’s specifications (71%) as well as the
users’ requirements (70%). They still cannot determine in 30%
of the instances either the specifications or the requirements.
This has a direct result on the remaining five criteria where the
product is used and accepted in only 68% of the cases. A third
of the users feel that they are not satisfied with the project
deliverable and that their expectations were not met.
71
Insights into information system project success
75%
70%
71%
70%
68%
68%
65%
67%
67%
67%
60%
55%
ns
re
xp
e
at
rs
U
se
se
U
its
ef
en
B
ct
at
io
ie
is
f
lis
re
a
ta
cc
ep
ra
se
U
d
ed
nc
e
d
se
uc
tu
Pr
od
ui
eq
R
Sp
ec
ifi
ca
t
io
re
m
en
ts
ns
50%
FIGURE 4.9: Deliverable success.
The results in Figure 4.10 are also not as promising as anticipated.
On average, Agile projects are only successful 71% of the time in
delivering a product that meets all the criteria. One of the principles
of the Agile Manifesto focuses on involving the users or customers
from the onset. The rationale is that when users or customers are
involved from the onset, then the chances are better that they will
accept the project deliverable and actually use it. This builds onto
the notion that they are involved from the beginning of the project
and should provide accurate requirements and specifications.
The concern highlighted by the results is that a quarter of the
users are not satisfied with the requirements and specifications
of the project deliverable. This means that the Agile principles
are not adhered to and that the project team is not trained in the
various Agile methodologies.
The average product success for Waterfall projects is 65%, which
is 6% lower than that of Agile projects as depicted in Figure 4.10.
72
Chapter 4
Agile
Benefits realised
69%
65%
User expectations
69%
65%
Product used
70%
62%
User satisfied
70%
64%
User acceptance
71%
64%
Specifications
73%
69%
Requirements
74%
75%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Waterfall
90%
100%
FIGURE 4.10: Deliverable success (Agile vs Waterfall).
The results highlight that in two-thirds of IS projects that follow
the Waterfall method, the deliverable does not meet the criteria.
This creates a serious concern as this implies that business and
strategic success cannot be achieved.
The next section focuses on business success and how the
deliverable of an IS project contributes to the overall success of
the business. Six criteria contribute to the success of the business.
Business success
Organisational leaders invest in a project to gain some benefits.
Criteria that organisational leaders interrogate are whether the
project meets the business and project objectives, is the business
case validated and are the benefits realised as indicated in the
business case?
The results in Figure 4.11 indicate that business success is
not that easily achieved. Business success is achieved in 62% of
73
Insights into information system project success
75%
70%
71%
65%
65%
64%
63%
60%
55%
54%
52%
ct
s
s
de
nt
en
ni
U
U
ni
nt
en
G
de
d
d
be
ov
er
na
ne
im
pa
fit
nc
e
io
n
at
B
en
ef
B
its
us
in
re
a
es
liz
s
G
pl
oa
ls
an
50%
FIGURE 4.11: Business success.
IS projects. The business success rate increases to 66% when
the criteria ‘Unintended benefits’ and ‘Unintended impacts’ are
removed. It is not always that easy for the project manager to
plan for these two criteria. The implication is still that a third of all
IS projects are not perceived as successful at this level.
In the remainder of the IS projects, IS project managers can
align the project with the organisational goal (71%) and this results
in the realisation of benefits (64%). This figure is still extremely
low given the fact that there is an emphasis on benefits realisation
in the last couple of years (Aguilera 2016; Bennington & Baccarini
2004; Marnewick 2016). Adherence to corporate and project
governance is also disappointingly low (63%) implying that IS
project managers are not always doing the right thing.
When the results are analysed based on the method that was
used, then it seems as if there is no difference between whether
a project used Agile or Waterfall as a method. The results in
Figure 4.12 illustrate that there is no difference between these
two methods.
74
Chapter 4
Agile
Unintended impacts
51%
52%
Unintended benefits
55%
54%
Benefits realization
65%
63%
Governance
63%
62%
Business plan
65%
63%
Goals
71%
70%
0%
20%
40%
60%
80%
Waterfall
100%
FIGURE 4.12: Business success (Agile vs Waterfall).
Using Agile as a method improves the chances of
achieving business success by 1% on average (Agile = 62% vs
Waterfall = 61%). The results raise more questions. One of the
questions that needs to be answered is whether IS projects
actually follow Agile methods or is it merely a lip service?
The last level of IS project success is determined at a strategic
level.
Strategic success
Investment in an IS project is perceived as a strategic success
when the project’s deliverable has a positive impact on the market,
competitors, investors and industry at large. The strategic success
rate is also not as high as one would hope for. The average success
75
Insights into information system project success
rate is 61% implying that two-fifths of IS projects are failures in
achieving strategic success for the organisation at large.
IS projects using an Agile method are far more strategically
successful than IS projects that are using Waterfall as a method
(Figure 4.14).
IS projects using Agile as a method are on average 41%
more successful than IS projects that use Waterfall as a
method. The reason is quite obvious. Project deliverables are
delivered quicker through Agile opening the opportunity for
quicker impact on the environment at large. The results portrayed
in Figure 4.14 corroborate the results displayed in Table 4.1. The
results highlight that Agile projects are delivered 7.7 months
quicker than projects that use Waterfall as a method.
Overall IT project success
People are not necessarily interested in the detail and want to
know what the overall success rates are of IS projects. The overall
70%
65%
62%
60%
62%
60%
60%
60%
55%
FIGURE 4.13: Strategic success.
76
ct
pa
im
ry
In
du
st
im
pa
ct
pa
im
y
ul
at
or
eg
R
In
ve
st
or
ct
t
im
ke
t
ar
M
C
om
pe
tit
iv
e
im
pa
c
pa
ct
50%
Chapter 4
Agile
Waterfall
Investor impact
81%
44%
Regulatory impact
83%
45%
Competitive impact
86%
45%
Industry impact
86%
41%
Market impact
87%
43%
0%
20%
40%
60%
80%
100%
FIGURE 4.14: Strategic success (Agile vs Waterfall).
59%
Strategic success
62%
Business success
68%
Deliverable success
Process success
50%
64%
52%
54%
56%
58%
60%
62%
64%
66%
68%
70%
FIGURE 4.15: Overall success.
success rate for IS projects are displayed in Figure 4.15. The project
success level is not included as it is difficult to convert time, cost
and scope into mere percentages. None of the four levels are
above 70%, and the average success rate is 63%.
77
Insights into information system project success
The success rate of 63% is a dramatic change from the 2013
figure of 34% (Marnewick 2013). It is a positive increase of
29%. This dramatic increase can be attributed to the way that
project success was measured in this study. Previous studies
focused on the success of an IS project with regard to time,
cost and scope. They did not focus on the other levels of
success.
The longitudinal analysis of IS project success is displayed in
Figure 4.16.
The overall success rates are further analysed based on the
method that was used, that is Agile or Waterfall. The comparison
is illustrated in Figure 4.17. The two major distinctions between
Agile and Waterfall are when process and strategic success
are measured. IS projects making use of Agile principles are
88% successful when process success is measured and 85%
successful when strategic success is measured. This is in stark
contrast with the results of IS projects that made use of the
Waterfall method.
70%
63%
60%
59%
50%
43%
40%
37%
34%
30%
20%
10%
0%
2002
2004
2006
2008
2010
2012
2014
2016
FIGURE 4.16: Longitudinal analysis of information technology project success rate.
78
2018
Chapter 4
Agile
Waterfall
Overall
100%
90%
43%
47%
80%
65%
70%
64%
60%
61%
68%
62%
59%
50%
40%
85%
88%
30%
71%
62%
20%
10%
cc
es
s
ss
su
su
cc
e
ic
s
B
us
in
St
ra
te
g
es
le
iv
er
ab
D
el
Pr
oc
es
s
su
su
cc
e
cc
es
s
ss
0%
FIGURE 4.17: Overall information technology project success.
TABLE 4.2: Overall information technology project success rates.
Item
%
Overall
Agile
Waterfall
Success average
63
77
54
Overall rule of 9’s
16
33
8
The concept of the ‘Rule of 9’s’ appears in the discipline of IT
service management (ITSM) (Schiesser 2010). Table 4.2 presents
the average IS project success rates, and it is evident that IS
projects using the Agile principles are 77% successful versus the
54% of IS projects that used the traditional Waterfall method.
The table also illustrates that the success rate of IS projects
drops from 63% to a mere 16% when the Rule of 9’s is applied.
This is also the case with Agile and Waterfall where the success
rates drop to 33% and 8% respectively.
79
Insights into information system project success
Conclusion
IS projects are still not out of the woods although there is an
increase in the success rates. The results highlighted two
important aspects. IS project success cannot be measured based
on the triple constraint and a new way of measuring is needed.
The results underline this principle where a strategic approach
is needed to measure IS project success. The aim is to deliver a
product or service that can be used by the customer and that
provide benefits to the organisation. This new way of thinking
has seen the increase of IS project success rising to 63%.
Secondly, it seems that incorporating Agile principles do have
a positive impact on the success of IS projects. Throughout the
analysis, projects that incorporate Agile principles do perform
better. This confirms the results of the 2015 Chaos Chronicles
where there is a 28% positive difference when Agile principles
are applied. The South African results indicate a difference of
23% when Agile principles are applied.
80
Chapter 5
Chapter 5
Insights into
information system
project complexity
IS project complexity does not have extensive exposure within
literature and thus requires further empirical investigation.
Chapter 3 revealed that IS project complexity was found to
have 75 features in total with 34 associated with organisational
complexity, 13 with technical complexity, 12 with environmental
complexity, 6 with dynamics and 10 with uncertainty. This
chapter aims to provide an initial analysis of IS project complexity
constructs and their respective features. Initial analysis provides
an overview of which complexity features to be aware of in
an IS project environment. Furthermore, analysis on IS project
complexity and IS project development method is also employed
for further insight.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Insights into information
system project complexity’, in The symbiosis between information system project
complexity and information system project success, pp. 81–99, AOSIS, Cape Town. https://
doi.org/10.4102/aosis.2017.itpsc45.05
81
Insights into information system project complexity
I nformation system project
complexity features
Each IS project complexity construct was analysed to identify
the top five features.
Organisational complexity
The construct of organisational complexity is directly associated
with internal complexities in an organisation and consists of the
most complexity features. Table 5.1 displays the top five features
within organisational complexity.
Schedule dependencies is the number one feature to consider
as it relates to how project tasks and activities are planned and
allocated. Furthermore, an IS project must be scheduled within
the context of the organisation so that it has minimal impact
on day-to-day operations. Skills availability is ranked second
and implies that the appropriate skills are available to perform
project tasks. IS projects often require extensive technical
skills particularly during implementation, as well as soft skills
for effective management throughout the project (Marnewick,
Erasmus & Joseph 2016). Capital expenditure is ranked third
and reiterates the importance of understanding the financial
support required to execute the project. Experience is ranked
fourth and relates to experience with involved parties. This
implies that IS projects perform better if there is some form
of previous experience with all involved parties as there is a
better level of understanding and collaboration amongst all.
TABLE 5.1: Organisational complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Schedule dependencies
2
Skill availability
3
Capital expenditure
4
Experience
5
Project duration
82
Chapter 5
Finally, project duration is ranked fifth amongst organisational
complexity features. The duration of a project is a key factor to
consider when embarking on a new project as this is dictated
by the strategic importance of the project. As per Table 4.1, it is
complex to allocate project duration as IS projects are infamous
for their poor performance regarding the time constraint.
Further analysis was performed to determine whether there
was any difference in the organisational complexity feature
ranking with regard to the IS project development method, that
is Agile and Waterfall. Table 5.2 shows the top five rankings for
IS projects using Agile as a method.
The top two features are the same as the overall ranking of
organisational complexity features. Project duration moved to
position three compared to position five. This implies duration
is more of a complexity feature for Agile projects. It could be
argued that Agile places more emphasis on delivering quick
iterations to facilitate a faster project delivery rate. Task
structure is ranked fourth, which is somewhat surprising given
that Agile places less emphasis on structure and more on
deliverables. Conversely, task structure could be more pivotal
for Agile projects as the project team must continuously reevaluate their progress and realign task structures to meet
the ever-changing IS project environment. Information system
dependencies is the fifth ranked feature. The drive to deliver
iterations to realise project goals requires the support of
information systems which facilitate an enhanced solution
development. It is therefore logical that IS dependencies are
considered as a complexity feature.
TABLE 5.2: Organisational complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Schedule dependencies
2
Skill availability
3
Project duration
4
Task structure
5
Information system dependencies
83
Insights into information system project complexity
TABLE 5.3: Organisational complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Organisational structure
2
Schedule dependencies
3
Resource sharing
4
Skill availability
5
Organisational units
The ranking of organisational complexity features for IS
projects using Waterfall as a method is depicted in Table 5.3.
Waterfall complexity features are considerably different to the
Overall and Agile views.
Firstly, organisational structure is ranked as the highest
complexity feature to consider for IS projects which apply the
Waterfall method. Given that the Waterfall method is heavily
structured approached and sequential in nature, it could
be implied that IS projects must be more cognisant of the
structure when planning and executing the project. Schedule
dependencies come out second, which aligns closely to the
Overall and Agile views. It therefore can be concluded that,
regardless of the method, scheduling is of utmost importance.
Resource sharing is ranked third and is closely associated with
the organisational structure as the structure must be understood
to ensure resources are shared accordingly. Multiple projects
of various types are executed at any single point in time, thus
making resource allocation important for Waterfall projects as
they require significant upfront planning and task delegation.
Skills availability is ranked fourth and is comparable to the Overall
and Agile views. Organisational units is ranked fifth for Waterfall
projects. Similar to the organisational structure’s importance to
the Waterfall method, understanding what role each unit plays
during a project is important to ensure the project delivers
accordingly. IS projects span multiple departments and units
thus making them increasingly complex to manage.
The next section analyses the IS project complexity construct
of technical complexity and its inherent features.
84
Chapter 5
Technical complexity
Technical
complexity
assesses
strategic
and
tactical
characteristics which directly influence the project. Table 5.4
shows the top five technical complexity features for IS projects.
Risks associated with the technical aspects of an IS project
are ranked first. Technical project characteristics are usually
considered during the initiation and planning phases but are
influenced during a project as well. The implication is that
technical characteristics must be part of the continuous risk
management as these add to the complexity of managing a
project. IS projects thrive on technology and employ new
technology wherever possible. Newness of technology is ranked
second and confirms that the use of new technology poses risks
as increased complexity arises. Chapter 4 notes that 71% and 70%
of specifications and requirements are met respectively (refer to
Figure 4.9). Scale of scope is ranked third and implies that project
scope is an important feature to consider to ensure a project
does not become overly complex. Not only must the scope be
well defined but also realistic to ensure the project can actually
be delivered. The number of tasks is ranked fourth. Project tasks
form the basis of any project and the number of them should not
be overwhelming and make the project increasingly difficult to
execute. The number of tasks is associated with the task structure
in organisational complexity as these work in tandem. It could be
argued that the number of tasks could be attributed to IS projects
deviating from the original time and cost (Table 4.1). Finally, the
variety of tasks is ranked fifth for technical complexity features.
Variety of tasks speaks to the skills availability of organisational
TABLE 5.4: Technical complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Technical risks
2
Newness of technology
3
Scale of scope
4
Number of tasks
5
Variety of tasks
85
Insights into information system project complexity
complexity as many tasks require different skill sets at different
proficiency levels. The project can only be delivered if the
appropriate skills are available or sought after.
The top five features of technical complexity when Agile is
adopted are presented in Table 5.5.
Technical risks and newness of technology are once again
ranked first and second for Agile projects respectively. Variety of
tasks is ranked third and implies that Agile projects include more
task variety during a project. The adaptive and flexible nature of
Agile suggests that there will be more task variety as solution
development will go through multiple iterations based on user
feedback particularly. Diversity of inputs and outputs is ranked
fourth and relates to the argument around the variety of tasks
as well. Furthermore, inputs and outputs are not predefined for
Agile projects implying that there is more inherent diversity which
contributes to complexity. Scale of scope is ranked fifth and
implies that although Agile projects also rely on well-documented
scope, they are more open to scope changes and alterations to
ensure the project delivers as intended. Furthermore, Chapter 4
revealed that Agile projects meet specifications and requirements
more successfully than Waterfall projects.
The ranking of technical complexity features for IS projects
using Waterfall as a method in Table 5.6 is very similar to the
Overall view of complexity features albeit in different order.
Technical risks is ranked first for the Overall, Agile and
Waterfall views of IS projects which confirms its importance
from a complexity perspective. Scale of scope is ranked second
highest in Waterfall projects. The Waterfall method is much more
TABLE 5.5: Technical complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Technical risks
2
Newness of technology
3
Variety of tasks
4
Diversity inputs/outputs
5
Scale of scope
86
Chapter 5
TABLE 5.6: Technical complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Technical risks
2
Scale of scope
3
Number of tasks
4
Newness of technology
5
Variety of tasks
procedural and thus requires significant time spent on planning
and designing an IS project solution. The scope is expected to
be more detailed and complete, which makes it a significant
technical complexity feature. Alternatively, Figure 4.10 contends
that Waterfall projects deliver less on requirements and
specifications, which contrasts with its approach of well-defined
scope development. The number of tasks is ranked third and is
more important for Waterfall projects as the number of tasks is
defined early and is not as flexible as Agile projects. Waterfall
projects rank newness of technology fourth implying that,
although it is an important feature, it does not have the same
significance as in the Overall and Agile views. It could be that new
technologies are intensively evaluated up front before adoption
to decrease possible project complexities. Finally, the variety of
tasks is ranked fifth and implies that Waterfall projects consider
task variety somewhat less than Agile projects. This does not,
however, negate the importance of understanding the various
tasks required to execute an IS project.
An analysis of environmental complexity features is performed
in the following section.
Environmental complexity
Environmental complexity assesses the internal and external
organisational environment in which the project operates. The top
five environmental complexity features are shown in Table 5.7.
Stakeholder perspectives can vary during IS projects thus making
it difficult to satisfy all stakeholders. Stakeholder perspectives is
ranked number one for IS projects in general, which implies it is
87
Insights into information system project complexity
TABLE 5.7: Environmental complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Internal strategic pressure
3
Number of stakeholders
4
Stability of project environment
5
Political influence
increasingly complex to manage stakeholder expectations and
to realise stakeholder satisfaction across the board. Constant
communication and interaction with all stakeholders are a means
to limit the complexity associated with varying perspectives.
Internal strategic pressure results from the pressure of senior
management expectations regarding the project. This feature
is ranked second and implies that IS projects experience higher
levels of complexity because of internal strategic pressure. As
mentioned, meeting all expectations is difficult and should be done
as best possible. The number of stakeholders is ranked third and
speaks to the complexity managing multiple internal and external
stakeholders involved in a project. Project communication is
more difficult than previously believed and is a skill set required
to ensure all stakeholders have an equal understanding of the
project at hand (Marnewick et al. 2016). IS projects which have
a large number of stakeholders increase complexity given the
communication challenges. Projects should operate within a
stable environment and with minimal negative impacts occurring.
The stability of project environment is ranked fourth implying
that it is a challenge maintaining a stable environment for the
project to thrive and exist freely. The organisational environment
has a direct impact on the project environment as any instability
would influence how a project is executed. Political influence is
ranked fifth and relates to internal politics particularly. Internal
politics primarily arise from stakeholders with senior authority,
such as executives. There could be cases where executives insist
on changing business requirements and scope without fully
understanding the intricacies and influences on other complexity
constructs and features.
88
Chapter 5
The top ranking environmental complexity features when
using Agile as a method, is shown in Table 5.8.
Stakeholder perspectives remain top, which further iterates
the importance of stakeholder management. The number
of stakeholders is ranked second, one position higher than
the Overall view. The implication therefore is that Agile
projects are more complex with regard to the management of
stakeholders given the top two rankings. Furthermore, this is
in line with the Agile Manifesto, which stresses a people rather
than a process focus (Beck et al. 2001). Internal strategic
pressure is ranked one position lower but still indicates that
the organisation at large has a direct influence on IS project
management. Although Agile IS projects are more flexible
and adaptable, there must still be the semblance of a stable
operating environment. Stability of the project environment
is ranked the same at position four and further solidifies its
importance for Agile projects. Interestingly, Agile projects
are more complex with regard to understanding the level of
competition in the industry as it is ranked fifth. Agile projects
aim to deliver projects rapidly so that business value can be
realised as soon as possible. Complexity arises when competing
within the organisation’s industry as this requires even more
focus delivering solutions rapidly to gain or expand market
share. This notion is further support by findings in Chapter 4,
which confirm that Agile has greater market and industry
impact (refer to Figure 4.14).
The environmental complexity features for Waterfall projects
are shown in Table 5.9.
TABLE 5.8: Environmental complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Number of stakeholders
3
Internal strategic pressure
4
Stability project of environment
5
Level of competition
89
Insights into information system project complexity
TABLE 5.9: Environmental complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Internal strategic pressure
3
Number of stakeholders
4
Political influence
5
Internal support
Stakeholder perspectives is still ranked number one and
confirms that it is a complexity feature which needs the utmost
attention. Internal strategic pressure maintains its top three
ranking as it is ranked second for Waterfall projects. The number
of stakeholders also holds its top three position as it is ranked
third. The top three for the Overall, Agile and Waterfall views
is particularly focused on stakeholder management, which is
more prevalent in modern project success literature (Joseph &
Marnewick 2014; Todorović et al. 2015; Williams 2016). Political
influence is included for Waterfall projects and is ranked fourth.
Internal politics seem to affect the Waterfall project complexity
more and must therefore be mitigated and managed as
effectively as possible. Finally, internal support is introduced
for the Waterfall projects as it is ranked fifth. Waterfall
projects arguably suffer from a lack of management support
from stakeholders such as project sponsors. This introduces
increased complexity as management support is required to
ensure the project aligns to the greater organisational goals.
Project complexity includes the construct of dynamics, which
is analysed in the next section.
Dynamics
The construct of dynamics focuses specifically on change
management practices and characteristics within an IS project.
Rather than ranking the top five, Table 5.10 ranks all the features
as there are only six features within the dynamics construct.
The number of changes is ranked first overall and implies
that the actual quantity of changes is complex to manage.
90
Chapter 5
TABLE 5.10: Dynamics top six complexity features (Overall).
Ranking
Complexity feature
1
Number of changes
2
Impact of changes
3
Change process
4
Scope of changes
5
Change over time
6
Frequency of changes
IS projects inherently have multiple changes throughout the
project, but the number of these changes should not be high
as multiple changes could imply that the project was not
completely understood and thus poorly developed. The impact
of changes is ranked second and should not be ignored as small
changes can have a large impact either positively or negatively.
Complexity increases particularly when negative changes occur
which derail the project, especially with regard to time and
cost. Complexity around the actual change process is ranked
third. Given that change is inevitable, an appropriate and welldesigned change process should exist to ensure changes are
managed effectively and are predominately positive. Scope of
changes is ranked fourth and focuses on the detail around the
expected changes. Similar to number and impact of changes,
the scope of changes should not be overwhelming as this would
suggest poor design. Although there are multiple changes
throughout a project, changes should have a fluctuation
pattern rather than maintain a continuous high level of changes.
Change over time and frequency of changes is ranked fifth and
sixth respectively and are comparable to scope of changes.
It becomes increasingly complex to manage a project with
frequent changes which change significantly over time.
The top six dynamics features when adopting Agile as a
method are presented in Table 5.11.
Managing the number of changes is still complex for Agile
projects as it is again ranked first. Change process has more
emphasis in Agile projects, which is logical given that Agile uses
continuous feedback to update and enhance the solution. The
change process must therefore be expedited to maintain iterative
91
Insights into information system project complexity
releases. Scope of changes is ranked one position higher at third
and implies that Agile projects face complexities around change
scope when delivering the various iterations. The impact of
changes is ranked lower at fourth, which arguably is consistent
with the fact that Agile minimises change impact through iterative
releases. Change frequency is important regardless and is ranked
one position higher for Agile at fifth. Interestingly, change over
time is considered the least complex for Agile projects, which
also corresponds with the notion that iterative releases facilitate
change management more effectively.
Dynamic complexity features for IS projects using the
Waterfall method, is ranked in Table 5.12.
The impact of changes is ranked top for Waterfall projects
which is significantly higher than the Agile project rankings. This
implies Waterfall projects face greater challenges when managing
change impact. The number of changes maintains its top two
ranking for the Overall, Agile and Waterfall views. This confirms
that it is important to not have too many changes at any single
point in time as this could detract from IS project execution and
negatively affect realising the project goals. Complexity around
TABLE 5.11: Dynamics top six complexity features (Agile).
Ranking
Complexity feature
1
Number of changes
2
Change process
3
Scope of changes
4
Impact of changes
5
Frequency of changes
6
Change over time
TABLE 5.12: Dynamics top six complexity features (Waterfall).
Ranking
Complexity feature
1
Impact of changes
2
Number of changes
3
Change process
4
Change over time
5
Scope of changes
6
Frequency of changes
92
Chapter 5
the change process is also apparent for Waterfall projects and thus
signifies the importance of having a well-designed change process
regardless of the project methodology employed. Waterfall
projects consider it more complex to manage change over time
as it is ranked fourth. This could be that Waterfall projects mainly
address changes towards the end of the project rather than
continuously and throughout the project. Interestingly, scope of
changes is ranked fifth and is considered not as complex compared
to the previously discussed features. Waterfall projects arguably
do not worry as much about the scope of changes because they
expect to implement multiple changes during the final project
stages. Frequency of changes maintains its low ranking at sixth
and serves to confirm that complexity around this feature is low as
the previous features aim to mitigate frequent changes.
The following section analyses the final project complexity
construct of uncertainty.
Uncertainty
Uncertainty assesses the level of doubt and vagueness inherent
in IS projects, and the Overall ranking for IS projects is showed
in Table 5.13.
Uncertainty regarding time is the most highly ranked
complexity feature overall. Time is one of the triple constraints
which are often argued as a key success criterion within project
management. Complexity around managing time uncertainty
therefore makes logical sense. Incomplete information is ranked
second and implies that IS projects experience significant
TABLE 5.13: Uncertainty top five complexity features (Overall).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Cost
4
Competency
5
Scope
93
Insights into information system project complexity
complexity regarding poor information dissemination. Incomplete
information such as poor requirements and specifications has a
detrimental effect on project delivery and subsequent success.
Cost is another component of the triple constraints which is
argued as important. It is ranked third from an uncertainty
perspective. Doubt around cost escalates quickly as it has a
knock-on effect on the project as a whole and can easily overshoot
planned estimates. Project competency is a strongly debated
topic in the IS project realm and brings to question whether IS
project managers have the appropriate skills and knowledge to
execute projects (Joseph & Marnewick; Marnewick et al. 2016).
Competency is ranked fourth and implies that it is increasingly
complex to ensure adequate competency exists for the project to
be executed correctly. Scope is ranked fifth within the uncertainty
construct of the IS project complexity. Scope uncertainty exists
predominantly when poor understanding and design exists.
Quality requirements is somewhat of a misnomer as literature
argues that practitioners do not take a holistic view during the
design of a solution and subsequently produce mediocre inputs
for development (Fernandez et al. 2015; Tamai & Kamata 2009).
Agile projects’ top uncertainty features are shown in Table 5.14.
The top three features are identical to the Overall view signifying
their importance. Scope is ranked one position higher at fourth,
implying Agile environments are slightly more complex regarding
the management of scope uncertainties.
Agile’s iterative and flexible environment suggests that scope
must be managed more carefully, otherwise the project could
become disjointed and not deliver as expected. Interestingly,
Agile introduces the feature of technological maturity as it is
TABLE 5.14: Uncertainty top five complexity features (Agile).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Cost
4
Scope
5
Technological maturity
94
Chapter 5
TABLE 5.15: Uncertainty top five complexity features (Waterfall).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Scope
4
Competency
5
Cost
ranked fifth. Agile arguably prefers using mature technology as
this would facilitate the fast-tracking of solutions to the market
as the team would have experience with adopted technology.
Conversely, it is complex to manage Agile projects which use
innovative and untested technology as experience will be lacking.
Table 5.15 shows the top five rankings for uncertainty features
for Waterfall projects. Time and incomplete information maintain
their top two positions once again.
It is therefore clear that that these two features add to IS
project complexity regardless of the methodology employed.
Furthermore, time uncertainty is arguably apparent in Table 4.1
where actual time deviates significantly from originally planned
time. Scope uncertainty is ranked highest for Waterfall projects,
which implies there is considerable doubt regarding upfront
scoping activities and that these projects battle with scope issues
throughout. Similar to the Overall view, competency is ranked
fourth when adopting the Waterfall method. Cost uncertainty
is ranked fifth implying that Waterfall projects do not consider
cost as a complex feature. This aligns to the findings in Chapter
4, which argue that Waterfall projects’ actual cost is less than the
original budget (Refer to Table 4.1).
The following section provides a holistic view of complexity
features by analysing them across all constructs.
Overall complexity view
The previous sections focus on the rankings of features within
a single complexity construct. The aim of the section is to
95
Insights into information system project complexity
elaborate on the previous findings by investigating the top five
and bottom five rankings across all five constructs. Table 5.16
provides an overview of the top and bottom five ranked features
of all constructs regardless of the method of orientation.
Technical risks ranked top overall implying that IS projects
complexity is primarily driven by project technicalities, that is
project goals, scope, tasks and technology experience. Schedule
dependencies is ranked second, which is logical given that project
management is a culmination of tasks required to deliver a successful
project. IS projects often face the dilemma of selecting technology
to adopt and implement. This is confirmed by the ranking of
newness of technology at third. Scope has been argued in previous
sections as a contentious issue which plagues IS projects. IS
projects face significant complexities regarding the scale of scope
as it is ranked fourth. Finishing off the top five is skill availability and
speaks directly to one of the most important resources required
for delivering a project. The project team particularly requires
extensive skills to not only manage an IS project but also implement
it. Interestingly, the top five features are predominantly technical
complexity features implying that IS projects should focus more
on technical aspects than anything else. It could be argued that
dealing with technical complexities could have a positive effect on
other complexity constructs and features.
The bottom five begins with undisclosed participants. IS
project environments do not consider this a complexity feature
which requires much attention. It has previously been argued
that all stakeholders should be accounted for to ensure the
TABLE 5.16: Top five and bottom five complexity features across all construct.
Ranking
Top 5
Bottom 5
1
TC technical risks
U undisclosed participants
2
OC schedule dependencies
OC HSSE
3
TC newness of technology
OC different languages
4
TC scale of scope
EC remoteness
5
OC skill availability
EC weather conditions
HSSE, health, safety, security and environment; TC, technical complexity; OC, organisational complexity;
EC, environmental complexity.
96
Chapter 5
project delivers accordingly. Yet, this feature is ranked as one of
the lowest. This could possibly be a fundamental indication why
IS projects perform poorly because they merely move forward
without comprehensive input from all involved. The second
lowest ranked feature is health, safety, security and environment
awareness implying that IS project environments omit complexities
associated with health and safety. Different languages used in a
project is considered the third lowest complexity feature, which
is surprising in the South African context given that the diverse
nature of the country includes the use of multiple languages.
Nevertheless, complexity around language is considered mediocre
and does not contribute sufficiently to IS project complexity. The
fourth lowest ranking is remoteness regarding the location or site
of the project deployment. The implication is that team members
and stakeholders do not face any difficulties accessing the project
site and logistics are not as complex. Weather conditions was
ranked the lowest of all the complexity features and implies that
IS projects continue regardless of the weather.
Similar to the individual assessment of complexity features,
this section will analyse features when different methodologies
are employed. Table 5.17 indicates the top and bottom five
feature rankings in an Agile project.
Schedule dependencies is the most highly ranked complexity
feature, which confirms that IS projects battle to manage their
schedule as the environment continuously changes during the
project. Agile projects view technical risks as the second most
important and is comparable to the overall view of complexity
features. Newness of technology retains its position at third
TABLE 5.17: Top five and bottom five complexity features across all constructs (Agile).
Ranking
Top 5
Bottom 5
1
OC schedule dependencies
U undisclosed participants
2
TC technical risks
OC different nationalities
3
TC newness of technology
EC remoteness
4
OC skill availability
OC different languages
5
D number of changes
EC weather conditions
OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics.
97
Insights into information system project complexity
and further iterates the importance of technology adoption and
implementation. Fourth is skill availability, which arguably confirms
that skills development and exploitation is a prerequisite in the IS
project realm. Agile projects are known for their iterations based on
feedback which lead to evolving changes. The number of changes
is ranked fifth and confirms that Agile projects face complexity
challenges regarding the management of multiple changes. Even
though Agile proclaims adaptation, multiple changes can become
cumbersome and adversely impact an IS project.
Undisclosed participants is once again ranked first further
implying its lack of complexity. Agile projects rank different
nationalities as the second lowest suggesting that organisations
have embraced the inclusion of multiple nationalities working
together given the modern landscape in which they operate.
Remoteness is ranked third while different languages is ranked
fourth. Weather conditions continues not to be a complex matter
as it is once again ranked last.
Table 5.18 indicates the top and bottom five feature rankings
in Waterfall projects.
Waterfall projects rank technical risks as top, which confirm
their complex nature to manage. Varying stakeholder perspectives
are introduced as a high-ranking complexity feature at position
two. It seems increasingly difficult to maintain and manage
various perspectives for Waterfall projects, which could be a key
attributing feature influencing IS project performance. Scale of
scope appears again as it is ranked third. The rigid nature of the
Waterfall method could be the reason why scope continues to be
a complex issue as the idea is that the scope is defined upfront
TABLE 5.18: Top five and bottom five complexity features across all constructs (Waterfall).
Ranking
Top 5
Bottom 5
1
TC technical risks
U undisclosed participants
2
EC stakeholder perspectives
OC HSSE
3
TC scale of scope
OC different languages
4
TC number of tasks
EC remoteness
5
TC newness of technology
EC weather conditions
OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics.
98
Chapter 5
and should not change. The fourth-ranking feature combines
some tasks that imply that Waterfall projects are not as adept at
task management compared to Agile projects. Although ranked
lower than the Overall and Agile views, newness of technology
maintains its position in the top five complexity features. IS
projects emphasise technology and it is, therefore, logical that
new technology complexities inherently exist for IS projects.
Technical complexities make up four of the five top ranked
features, which is similar to the argument made for the Overall IS
project complexity view.
The bottom five features are comparable to the Overall and
Agile views, which confirms that they are far simpler to manage
than other complexity features.
Conclusion
The aim of this chapter was to indicate which features in an IS
project are considered most complex so that practitioners can
make adequate provision for managing them. The rankings
for the overall and individual views of constructs show that no
environment is the same and that each view complexity in a
different light. Many features align with the environment they
operate in, that is, Agile and Waterfall. The analysis of the top
five complexity features does not show one construct as more
complex than another construct. What is evident is that features
from technical complexity construct occur nine times within the
top five features with organisational complexity in the second
place. IS project managers should analyse the various complexity
constructs and address the features one by one in order to
reduce the overall complexity of the project.
The subsequent question is: How does one manage these
complexity features to ensure they do not adversely affect
project delivery? Ironically, understanding IS project complexity
is complex in itself, which is why further analysis is required to
illuminate its inherent intricacies.
99
Chapter 6
Symbiosis between
IS project success
and complexity
All the constructs related to IS project success and IS project
complexity are represented in Appendix A. The various respective
elements and features are also included for ease of reference.
Moreover, observed variable names were defined as this would
act as a cross-referencing tool for the data analysis below.
onceptualising the symbiosis
C
between information system project
success and complexity
Project success and complexity are often viewed in isolation with
no real link argued between the two. However, in the real world
there is an indefinite association between the two concepts.
Chapters 2 and 3 discussed the concepts separately in detail as
these formed the foundation of articulating the symbiosis which
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Symbiosis between IS project
success and complexity’, in The symbiosis between information system project complexity
and information system project success, pp. 100–136, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.06
100
Chapter 6
inherently exists. The models represented in this chapter are based
on the logical mappings depicted and argued in this section.
The concept of project success has many definitions which
have varying perspectives and thus create an element of
incongruity in the project management landscape. Chapter 2
presented the five level model of project success to encapsulate
the concept from an IS perspective. The concept of project
complexity has also resulted in multiple views being developed,
which has culminated in a multidimensional perspective of the
concept. Chapter 3 subsequently presented a five dimensional
view for IS project complexity based on an extensive literature
review. The question posed here is how these views relate
theoretically and logically prior to further data exploration.
A conceptual theoretical model for the symbiosis between
IS project success and IS project complexity is presented in
Figure 6.1.
Organisational complexity spans the entire five level view of
project success as IS projects are executed within the organisational
context to facilitate the realisation of the business and strategic
goals. An organisation’s structural orientation affects everything
Organisational complexity + Environmental
complexity
Project
Process
success
Project
management
success
Product
Deliverable success
Organisational benefit
Business
success
Strategic
success
Technical complexity +
Dynamics + Uncertainty
FIGURE 6.1: Symbiosis of information system project success and information system
project complexity.
101
Symbiosis between IS project success and complexity
from the project process to long-term strategic success as the
organisational structure and business units directly influence how a
project is executed. The element of size pertains to attributes of an
IS project such as project duration, variety of methods and capital
expenditure, for example. Size thus plays a role that influences
process and project management success as each attribute pertains
to the groundwork that is performed for a project. Resources within
organisational complexity elaborate areas which pertain to business
and strategic success distinctly, such as project drive. Areas such as
resource and skills availability as well as experience with involved
parties align to project management and deliverable success as
both embrace effective project management execution to deliver
valuable product output. The project team and trust elements have
implications regarding process and project management success as
social dynamics propel and support the execution of an IS project.
Interdependencies and risk span the entire five level landscape as
each feature influences one or multiple success levels.
Environment complexity comparably covers all five levels of
project success as well. Process and project management success
are encapsulated by the elements of stakeholders and location.
The location element speaks to attributes and intricacies regarding
the project site. Process and project management success is
dependent on these environmental attributes as they influence the
activities required to execute a project. Stakeholders is an element
which emphasises stakeholder management, which is key to
realising process and project management success. Furthermore,
stakeholders aligns to deliverable success as the management of
stakeholders such as the end user aims to ensure the project delivers
its output goal. Business and strategic success is driven by the need
to compete within a competitive global landscape. These two levels
of organisational benefit are affected by complexities surrounding
environmental stability, strategic pressure and competition
level, which are represented in the market conditions element of
environmental complexity. Environmental risks span all success
levels as risks are inherent regardless the status of each level.
Technical complexity is inherently focused project management
as each of the features revolve around project management activities
102
Chapter 6
specifically. Inferences exist, therefore, that technical complexity
engages with the levels of process and project management
success. Differentiation relates to input and output diversity, which is
intrinsic of project management as a whole and the processes which
support it. Goals is specific to project goals and their alignment to
greater strategic initiatives. This is dealt with on the ‘ground’ level
where project activities are executed as each activity is aligned to
the greater project goal. The realisation of the project goal is not
the main concern during the project management phase as the
focus is on delivering the project with assessment done later on.
The elements of scope and task once again focus on actual activities
and how they are performed, which is project management itself.
Experience from a technical complexity view regards the challenges
dealing with technology in an IS project. This experience, therefore,
relates to project management success as the focus is on how
technology is used in the project to realise the project goal. Similar
to organisational and environmental risks, technical risks appeal to
process and project management risks at the ‘ground’ level.
Uncertainty incorporates elements and features around doubt
and vagueness, which is directly associated with process and
project management success. The triple constraints of time, cost
and scope are a project management assessment tool and are
specific to an individual project. Method and task uncertainty has
a process and project management orientation that is particular
to hands-on activities. The elements of goals, technology and
stakeholders uncertainty are project management specific as
they all deal with characteristics of the project itself and not
success areas after the project. This, however, does not negate
any possible propagating effect to the following project success
levels. Information uncertainty and vagueness occur regardless
of the various project management processes in place, which is
why it relates to process and project management success.
Project experience changes throughout
change management practices to maintain
Change management is covered in the
and is particular to the project itself, which
and requires robust
project momentum.
dynamics construct
implies that process
103
Symbiosis between IS project success and complexity
and project management success are once again influenced.
Change management is particularly important for IS projects as
methodologies have different approaches which influence its
practice. For example, Agile projects profess adaption and iteration
which require robust change management practices and processes.
The discussion above argues the logical mapping of IS project
success and complexity to convey symbiosis of the two concepts.
The subsequent model development and analysis is based on
these mappings to illuminate the symbiosis.
evelopment and analysis of IS
D
project success models
The third section of the questionnaire requested the respondents
to provide their impressions regarding what affects project
success on various levels. These five levels were identified from
the research performed by Bannerman (2008):
•• Level 1: Process success. The need to consider technical and
managerial aspects in completing the project task.
• Level 2: Project management success. The immediate
performance of the project with regard to budget, scope
and schedule.
• Level 3: Deliverable success. The measures of information
quality, system quality, service quality, intention to use, actual
use, user satisfaction, and net benefits.
• Level 4: Business success. The ability of the project to
successfully meet the needs or solve a business problem the
customer is experiencing.
• Level 5: Strategic success. This criterion represents the highest
level of benefit achieved by a project, despite the possibility of
failures against lower level criteria, as recognised by external
stakeholders such as investors, industry peers, competitors, or
the general public, dependent upon the nature of the project.
One level is omitted in the discussion that follows, that is Level 2
that focuses on project management success. The questionnaire
requested specific data from the respondents which is not
104
Chapter 6
conducive for modelling. The other four levels were measured
using a 5-point Likert scale. Suffice to say that various other studies
have been able to determine the various critical success factors and
causes of failure (Marnewick, Erasmus & Joseph 2016).
What follows is a discussion on the Overall factors and model
as well as an investigation into the differences between Agile
and Waterfall projects.
Overall results
The Overall results closely reflected the research done by
Bannerman (2008) in that three of the levels were clearly
identified. The following factor loading is the result of factor
analysis through statistical software (Figure 6.1).
All the relevant variables associated with the different levels
associated with four factors. Factor 1 included all the variables of
deliverable success. These were:
••
•
•
•
•
•
•
requirements met
specifications met
client and/or user specifications met
client and/or user acceptance
product and/or system used
client and/or user satisfied
client and/or user benefits realised.
These clearly relate to Level 3 of the Bannerman (2008) model
and therefore Factor 1 can confidently be labelled as Deliverable
success. However, there are other variables, not thought of
as part of deliverable success in the original model, that are
associated with this factor. These are:
•• goals and/or objectives
• business plan
• benefits realisation.
These variables are identified as forming part of Business
success or Level 4. On examination it would seem these three
variables bear some relation to product success in the mind of
the respondents.
105
Symbiosis between IS project success and complexity
TABLE 6.1: Overall factor loadings with Pattern Matrix.
Observed
variablea
DS_06
Factor
1
2
3
4
0.851
DS_04
0.842
DS_03
0.800
DS_02
0.748
DS_07
0.728
DS_05
0.648
DS_01
0.626
BS_04
0.574
BS_01
0.561
BS_02
0.370
SS_03
0.756
SS_04
0.734
SS_01
0.722
SS_02
0.690
SS_05
0.603
SS_06
0.587
PS_01
0.772
PS_03
0.735
PS_02
0.698
PS_04
0.654
BS_05
1.018
BS_06
0.587
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
Factor 2 contained all the variables associated with strategic
success on Level 5 of Bannerman’s model. These are:
••
•
•
•
•
•
market impact
industry impact
competitive impact
investor impact
regulator impact
other impacts.
Therefore, Factor 2 can be labelled as Strategic success and
correlates strongly with what literature determines.
106
Chapter 6
Factor 3 includes all the variables labelled as part of process
success. These are:
••
•
•
•
Processes
Processes
Processes
Processes
appropriately chosen for the intended purpose.
aligned with project objective.
appropriately integrated with one another.
effectively implemented.
Therefore, Factor 3 correlates strongly with what Bannerman
(2008) identified as Level 1 and can be labelled as Process
success.
Two remaining variables are grouped into Factor 4. These
variables are:
•• Extent to which the project achieved unintended benefits.
• Extent to which the project achieved unintended consequences.
These variables are associated with business success in
literature. However, on their own, it may not be apparent that
they belong there. Given the ‘unknown’ description of both of
these variables, perhaps the data can be interpreted differently.
This factor is labelled as the Unknowns of project success as it
refers to impacts and consequences of conducting project work.
These impacts are difficult to plan for or to anticipate without
extensive due diligence activities.
These factors are all confirmed with Cronbach Alpha values
of 0.9 and above (Field 2013). Therefore, the researchers are
confident about the validity of the four identified factors. These
could be depicted as per Figure 6.2.
The next step is to attempt to determine a model. The purpose of
such a model is to ascertain whether there are links between these
different factors and whether or not there are correlations between
one another. This is done through the process of Structural
Equation Modelling (SEM). The following model (Figure 6.3)
emerged after numerous iterations.
This model clearly indicates that these different levels have
medium to strong relationships to one another, the strongest
being between Process success and Deliverable success. This is an
107
Symbiosis between IS project success and complexity
Deliverable
success
Unknowns
(of project
success)
Project
success
Strategic
success
Process
success
FIGURE 6.2: Project success level factors.
expected result as it would be difficult to imagine that a deliverable
can be produced without completing proper processes. Recall
that Bannerman (2008) indicated that these levels need not
necessarily be related to achieve success on higher levels. While
these results do not directly contradict Bannerman (2008), they
indicate that there is a relationship nonetheless. The outcome on
lower levels would seem to have an impact on the outcome on
higher levels.
108
Chapter 6
DS_06
DS_04
.80
DS_03
.80
DS_02
.80
.79
DS_07
DS_05
.71
.64
Deliverable
success
.74
DS_01
BS_04
.73
.68
.64
BS_01
.67
BS_02
SS_03
.76
SS_04
SS_01
.72
.74
SS_02
SS_05
.76
.65
.50
Strategic
success
.63
.63
SS_06
.52
PS_01
.68
PS_03
.76
PS_02
.72
.57
Process
success
.79
.45
PS_04
BS_05
.84
.76
BS_06
‘Unknown’
of success
FIGURE 6.3: Unconfirmed model for project success levels.
109
Symbiosis between IS project success and complexity
This model can be confirmed as valid. The following model
fit data was obtained from the SEM process as depicted in Table 6.2.
Therefore, for the purposes of this data set, we can confidently
conclude that IS project managers take cognisance of the
following levels of project success:
•• Level 1: Process success.
• Level 2: Project management success as determined by previous
studies.
• Level 3: Deliverable success.
• Level 4: Strategic success.
TABLE 6.2: Model fit data for Overall model for project success.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
Relative fit
measures
Fit measures
based on the
non-central
chi-square
distributions
Cut-off
levels
employed
≤5
Results
RMR
≤ 0.05
0.04
GFI
≥ 0.9
0.92
NFI
≥ 0.9
0.93
TLI
≥ 0.9
0.94
CFI
≥ 0.95
0.95
RMSEA
≤ 0.08
0.06
2.82
Reference
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney
et al. (2002); Roh, Ahn and
Han (2005) ; Ullman (1996);
Yatim (2008)
Roh et al. (2005);
Tabachnick and Fidell (1996);
Doloi, Iyer and Sawhney
(2011); Kim et al. (2009); Roh
et al. (2005);Tabachnick and
Fidell (1996)
Doloi et al. (2011); Stahl
(2008); Tabachnick and
Fidell (1996); Yatim (2008);
Doloi et al. (2011); Hair et al.
(2006); Stahl (2008); Yatim
(2008)
Anglim (2007); Doloi et al.
(2011); Gaskin (2013e); Hair
et al. (2006); Roh et al.
(2005); Tabachnick and
Fidell (1996); Stahl (2008);
Yatim (2008)
Hoyle (2011); Marsh, Hau and
Wen (2004); McQuitty and
Wolf (2013); Nunkoo and
Ramkissoon (2012); Reisinger
and Mavondo (2007)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit
Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean
Square Error of Approximation.
110
Chapter 6
The variables for business success (Level 4) are distributed
between Process success and Deliverable success. However,
project professionals also take note that unintended impacts
and consequences somehow form part of the model of project
success. It does, however, seem that these are separated from
other measures of project success considerations in that they
cannot be taken into account.
Results for Waterfall projects
The data can be separated into projects conducted using the
Waterfall and Agile methods, the purpose being to determine
if there are differences in how project success is perceived and
determined between the two methods.
Four factors closely mirroring those of the Overall results
were obtained. The factors were once again confirmed as
valid with a Cronbach alpha value of above 0.9 for all of them.
Table 6.3 indicates the factors loading for each variable and their
associated factors.
Slightly less clarity is obtained from this analysis because the
number of responses is now less than in the Overall view. On the
face of it, the result is very similar to that of the Overall result.
The factor groupings remain the same as in Table 6.1:
•• Factor 1: Deliverable success. The only difference is the
omission of the Goals and Objectives variable, which is now to
be found in Factor 3, Process success. This could be because
Waterfall projects are very structured and are initiated with the
goal of the project in mind right from the start.
• Factor 2: Strategic success. Is identical to that of the Overall
result.
• Factor 3: Process success. Is identical except for the variables
discussed above and for the addition of one variable associated
with business success. Interestingly enough, this variable is
Governance. In order for the factors and model to make sense,
governance is required. As a Waterfall project follows a very
rigid and formalised approach, strong governance lies at the
heart of it.
111
Symbiosis between IS project success and complexity
TABLE 6.3: Factors for project success with a Pattern Matrix (Waterfall).
Observed
variablea
DS_04
Factor
1
2
3
DS_03
0.861
DS_06
0.794
DS_07
0.694
DS_05
0.672
DS_02
0.653
BS_04
0.517
DS_01
0.393
BS_02
0.363
0.304
0.360
SS_05
0.834
SS_06
0.746
SS_04
0.725
SS_01
0.721
SS_03
0.590
SS_02
0.517
PS_01
0.803
PS_04
0.767
PS_03
0.766
PS_02
BS_01
BS_03
4
0.898
0.678
0.398
0.462
0.319
BS_05
0.812
BS_06
0.738
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
• Factor 4: Unknowns. Of a project success also remains
unchanged.
The SEM model (Figure 6.4) for these factors is also generated
and revealed to be as such.
Here even stronger interrelationships are identified, the
strongest relationship once again being between Process success
and Deliverable success. This correlation is very strong. This
would imply that the outcome in the preceding level of Process
success would directly and very strongly impact Deliverable
success. This is a clear indication on how the Waterfall method
impacts the outcome. The Waterfall method is initiated with a set
112
Chapter 6
DS_04
DS_03
DS_06
DS_07
DS_05
.79
.80
.78
.68
.57
.79
DS_02
.76
BS_04
.76
DS_01
Deliverable
success
.64
.67
BS_02
SS_05
.63
SS_06
.63
.66
SS_04
.72
SS_01
.94
Strategic
success
.76
.51
.75
SS_03
SS_02
.57
PS_01
.56
PS_04
.58
.69
PS_03
PS_02
BS_01
.63
.66
Process
success
.69
.51
.49
BS_03
BS_05
.85
.76
BS_06
‘Unknown’
of success
FIGURE 6.4: Unconfirmed model for Waterfall project success levels.
113
Symbiosis between IS project success and complexity
goal in mind to deliver a specific product. To obtain this product,
many processes are performed in an iterative fashion.
The model fit measures for this results were obtained as
depicted in Table 6.4.
The proposed model can be confirmed given the model fit
measures. It is clear that the conclusions for the Overall model
also apply to Waterfall projects. The one aspect that that is
different is how strongly goals and objectives are associated
with Level 1, Process success.
Results for Agile projects
The Agile method requires that its adherents only do what is
required to successfully complete the delivery of a product. This
TABLE 6.4: Model fit for Waterfall project success mode.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
RMR
GFI
Relative fit
measures
NFI
TLI
CFI
Fit measures
based on the
non-central
chi-square
distributions
RMSEA
Cut-off
Results Reference
levels
employed
≤5
2.7
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney et al.
(2002); Roh et al. (2005); Ullman
(1996); Yatim (2008)
≤ 0.05
0.04
Roh et al. (2005); Tabachnick and
Fidell (1996)
≥ 0.9
0.92
Doloi et al. (2011); Kim et al.
(2009); Roh et al. (2005);
Tabachnick and Fidell (1996)
≥ 0.9
0.93
Doloi et al. (2011); Stahl (2008);
Tabachnick and Fidell (1996);
Yatim (2008)
≥ 0.9
0.94
Hair et al. (2006); Doloi et al.
(2011); Stahl (2008); Yatim (2008)
≥ 0.95
0.95
Anglim (2007); Doloi et al. (2011);
Gaskin (2013e); Hair et al. (2006);
Roh et al. (2005); Stahl (2008);
Tabachnick and Fidell (1996);
Yatim (2008)
≤ 0.08
0.06
Hoyle (2011); Marsh et al. (2004);
McQuitty and Wolf (2013);
Reisinger and Mavondo (2007);
Nunkoo and Ramkissoon (2012)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit Index;
NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean Square
Error of Approximation.
114
Chapter 6
approach in no way absolves its adherents of the requirement of
a formalised approach.
The results in this data set once again yielded the same
four factors as found in the Overall and Waterfall models. All
four factors were confirmed as valid with a strong Cronbach
alpha above 0.9. The factor loadings obtained are depicted in
Table 6.5.
•• Factor 1: Deliverable success. Is identical to that of the Overall
model. This of course differs from the Waterfall project factors
where objectives and goals are excluded in favour of Factor 3:
Process success. For Agile projects, it seems that objectives
TABLE 6.5: Factors for Agile project success with Pattern Matrix.
Observed
variablea
Factor
1
DS_06
0.851
DS_03
0.834
DS_02
0.782
DS_01
0.737
DS_04
0.735
DS_07
0.671
BS_01
0.633
BS_04
0.574
DS_05
0.545
BS_02
0.421
2
SS_03
0.745
SS_02
0.729
SS_01
0.723
SS_04
0.714
SS_06
0.500
SS_05
0.433
PS_03
3
4
0.749
PS_04
0.733
PS_01
0.667
PS_02
0.607
BS_05
1.019
BS_06
0.509
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
115
Symbiosis between IS project success and complexity
and goals form part of Factor 1: Deliverable success. This may
be because, in Agile projects, not all requirements are
immediately visible or identified but only developed during
further iterations of the process.
• Factor 2: Strategic success. Is identical to all previous results.
• Factor 3: Process success. Is identical to the Overall result and
only differs from the Waterfall projects’ results in two aspects.
The model for Agile project success does (1) not require
governance or (2) goals and objectives variables must be
coherent. This is an interesting result, given the propensity for
many Agile adherents to summarily dispense with valuable,
formalised techniques. Governance is the activity of guiding
behaviour to achieve a desired outcome and objective (Joseph,
Erasmus & Marnewick 2014). The fact that the respondents to
this questionnaire who practice Agile principles do not see value
or need for governance as a contributing factor project success
is cause for concern.
The Agile project success model was derived as in Figure 6.5.
This model once again indicates medium to strong relationships
between the four factors that were confirmed. Table 6.6 shows
the model fit measurements that were obtained.
This model is also confirmed as valid and can be accepted.
The medium to strong relationship indicates that once again
there are influences amongst the levels of project success that
cannot be ignored.
evelopment and analysis of IS
D
project complexity models
It must be noted that, unlike the IS project success models
presented above, no viable or feasible SEM models were
possible for all complexity constructs. Exploratory models are
subsequently presented as they still provide insight regarding
what complexity features to consider for IS projects.
116
Chapter 6
DS_06
DS_03
.80
DS_02
.80
.79
DS_01
DS_04
DS_07
BS_01
BS_04
.74
.80
.71
Deliverable
success
.68
.73
.64
.64
DS_05
.67
BS_02
SS_03
.76
SS_02
SS_01
.72
.65
SS_04
SS_06
.76
.74
.50
Strategic
success
.63
.63
SS_05
PS_03
PS_04
PS_01
.52
.57
.76
.79
.68
Process
success
.72
.45
PS_02
.84
BS_05
.76
‘Unknown’
of success
BS_06
FIGURE 6.5: Unconfirmed model for Agile project success levels.
117
Symbiosis between IS project success and complexity
TABLE 6.6: Agile model fit measurements.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
Relative fit
measures
Fit measures
based on the
non-central
chi-square
distributions
Cut-off
levels
employed
≤5
Results
RMR
≤ 0.05
0.04
GFI
≥ 0.9
0.92
NFI
≥ 0.9
0.93
TLI
≥ 0.9
0.91
CFI
≥ 0.95
0.95
RMSEA
≤ 0.08
0.06
2.8
Reference
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney et al.
(2002); Ullman (1996); Roh
et al. (2005); Yatim (2008)
Roh et al. (2005); Tabachnick
and Fidell (1996)
Doloi et al. (2011); Kim et al.
(2009); Roh et al. (2005);
Tabachnick and Fidell (1996);
Doloi et al. (2011); Stahl (2008);
Tabachnick and Fidell (1996)
Yatim (2008)
Doloi et al. (2011); Hair et al.
(2006); Stahl (2008); Yatim
(2008)
Anglim (2007); Doloi et al.
(2011); Gaskin (2013e); Hair
et al. (2006); Roh et al. (2005);
Stahl (2008); Tabachnick and
Fidell (1996); Yatim (2008);
Hoyle (2011); Reisinger and
Marsh et al. (2004); Mavondo
(2007); McQuitty and Wolf
(2013); Nunkoo and
Ramkissoon (2012)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit
Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean
Square Error of Approximation.
rganisational complexity and project
O
success
Organisational complexity was identified as the IS project
complexity construct with the most features at 34. Furthermore, it
was depicted and discussed that organisational complexity spans
across all the project success levels. Exploratory factor analysis
(EFA) was performed to determine the latent constructs within
organisational complexity from an Overall, Agile and Waterfall
perspective. However, the EFA process was unsuccessful as a valid
and reliable exploratory model could not be determined based on
the current dataset. It was therefore established that future studies
will have to be performed to gain a better understanding and clarity
around the organisational complexity construct for IS projects.
118
Chapter 6
The irony that organisational complexity is complex to articulate
further iterates the importance of understanding this construct.
Environmental complexity
Failure of the organisational complexity EFA process resulted
in environmental complexity being analysed independently as
this would still provide value regarding what complexities to
assess from an environmental perspective. Similarly, EFA was
performed from an Overall, Agile and Waterfall perspective.
verall exploratory factor analysis modelling
O
of environmental complexity
Various measures were applied when validating the discovered
exploratory models. Firstly, the Kaiser-Meyer-Olkin (KMO) was
assessed at 0.848, which is a very good adequacy measure
(Field 2009; Gaskin 2016; Kaiser 1974). The KMO value was
also significant (0.000), which further validates this adequacy
measure. Extraction values from the communalities results are
also used to determine adequacy and are required to be above
0.3 (Gaskin 2016). This was confirmed as all values were above
the acceptable threshold. The total variance explained is another
adequacy measure which needs to be assessed. The threshold
for this measure is preferably above 50% (Gaskin 2016; Reio &
Shuck 2015), but the result was 44.4%. For the sake of research,
the results of this EFA will still be discussed as the other validity
and reliability measures were acceptable. Convergent validity was
established via factor loadings, which are required to be above 0.5
with an average loading, within a factor, of above 0.7 (Ferguson
& Cox 1993; Gaskin 2016; Hair et al. 2006). Table 6.7 presents
the factor loadings and reveals that further validation is required
to confirm the loading values. Cronbach’s alpha was used as a
reliability check with the threshold set at 0.7 (Badewi 2016; Chow
& Cao 2008; Hair et al. 2006). Cronbach values are represented in
Table 6.7 next to the factor number in brackets. Both values are
119
Symbiosis between IS project success and complexity
TABLE 6.7: Environmental complexity exploratory factor analysis Patten Matrix.
Observed variablea
Factor
1 (0.860)
EC_09
2 (0.811)
0.779
EC_08
0.701
EC_07
0.678
EC_13
0.664
EC_06
0.542
EC_12
0.542
EC_10
0.513
EC_05
0.496
EC_11
0.470
EC_04
0.419
EC_01
0.867
EC_02
0.835
, Variable names and associations are presented in Appendix A.
a
acceptable as Factor 1 and Factor 2 have a score of 0.860 and
0.811 respectively and confirm the factor loadings. Discriminant
validity was assessed via the factor correlation matrix where there
should be no correlations above 0.7 (Gaskin 2016). The correlation
between Factor 1 and Factor 2 was below the threshold at 0.533.
A factor plot is also used to visualise the groupings for each
factor (Figure 6.6). It must be noted that factor plot diagrams can
only represent three factors effectively as they are limited to three
dimensions. The groupings are distinct and confirm the loadings.
An exploratory model for the environmental complexity of IS
projects is depicted in Figure 6.7. The EFA revealed that one
factor had to be removed, that is political influence (EC_03).
Political influence, therefore, has no effect on IS project
complexity and subsequently IS project success. Political
influence could be a feature which must be handled by external
parties such as senior management, as the project should be
left to its own devices to deliver as required. Factor 1 is labelled
strategic and tactical conditions as the inherent features revolve
around strategic aspects such as internal strategic pressure
and level of competition. Strategic aspects focus on the greater
project goal and its relation to strategic intent. Tactical aspects
120
Chapter 6
Factor plot in rotated factor space
1.0
EC_01
EC_02
0.5
Factor 2
EC_11
EC_04
EC_05
EC_06
0.0
EC_10
EC_12
EC_13
EC_09
EC_08
EC_07
–0.5
–1.0
–1.0
–0.5
0.0
Factor 1
0.5
1.0
FIGURE 6.6: Environmental complexity factor plot diagram.
Strategic and tactical conditions
Stakeholder management
• Internal support
• Required local content
• Weather conditions
• Interference with existing site
• Remoteness of location
• Experience in country
• Internal strategic pressure
• Level of competition
• Stability of project environment
• Environmental risks
• Number of stakeholders
Environmental
complexity
• Variety of stakeholder
perspectives
FIGURE 6.7: Exploratory model for environmental complexity of information system project.
include, amongst others, remoteness of location, experience in
the country, risks and weather conditions. Tactical aspects focus
on practices and considerations around ground level activities of
the project itself.
121
Symbiosis between IS project success and complexity
gile exploratory factor analysis modelling of
A
environmental complexity
The Agile EFA model of environmental complexity applies the
same acceptance criteria as before. The KMO was significant
(0.000) and accepted at 0.849. All extraction values are above
the 0.3 threshold. Total variance explained is accepted on the
limit at 50%. Factor loadings presented an issue again, thus
Cronbach alpha was applied. The results were 0.823 and 0.832
for Factor 1 and Factor 2 respectively (Table 6.8). Reliability and
factor loading validity are therefore accepted and confirmed.
The correlation between Factor 1 and Factor 2 was below the
threshold at 0.558.
Distinct groupings are represented in the factor plot diagram
(Figure 6.8). Complexity features EC_05, EC_06, EC_07 and
EC_09 were removed to enhance EFA model validity and
reliability.
The results imply required local content, interference with
existing site, weather conditions and experience in a country
are not complexity features for Agile projects. Local content
TABLE 6.8: Environmental complexity exploratory factor analysis Patten Matrix (Agile).
Observed variablea
Factor
1 (0.823)
EC_09
0.892
EC_13
0.687
EC_10
0.644
EC_11
0.628
EC_08
0.526
EC_12
0.447
EC_03
2 (0.832)
0.829
EC_02
0.772
EC_01
0.737
EC_04
0.596
, Variable names and associations are presented in Appendix A.
a
122
Chapter 6
Factor plot in rotated factor space
1.0
EC_03
EC_02
EC_01
EC_04
Factor 2
0.5
EC_12
EC_10
EC_11
EC_13
EC_08
0.0
EC_09
–0.5
–1.0
–1.0
–0.5
0.0
Factor 1
0.5
1.0
FIGURE 6.8: Environmental complexity factor plot diagram when using Agile.
requirement is arguably not an issue for Agile projects as they
adapt and reconfigure where necessary to accommodate the
use of local content-based policies where the project is being
executed. Similarly, the same could apply for interference with
the existing site. Protest action for example does not influence
Agile projects as it is dealt with on an ad hoc basis and initiative
is taken to continue where possible and minimise productivity
loss. Weather conditions was continuously ranked in the bottom
five features in Chapter 5 and is confirmed here as a poorly
represented complexity feature. Experience in a country may not
effect Agile projects as the projects draw on their own experience
from various projects to accommodate for country differences.
The exploratory model for Agile projects is similar to the Overall
model as the latent factors remain stakeholder management as
well as strategic and tactical conditions (Figure 6.9).
123
Symbiosis between IS project success and complexity
Stakeholder management
Strategic and Tactical conditions
•
•
•
•
•
Remoteness of location
Internal strategic pressure
Stability of project environment
Level of competition
Environmental risks
Environmental
complexity
(Agile)
• Number of stakeholders
• Variety of stakeholder
perspectives
• Political influence
• Internal support
FIGURE 6.9: Exploratory model for environmental complexity (Agile).
TABLE 6.9: Environmental complexity exploratory factor analysis Patten Matrix (Waterfall).
Observed variablea
Factor
1 (0.799)
EC_01
0.971
EC_02
0.747
EC_11
0.575
EC_03
0.525
EC_09
a
2 (0.793)
0.787
EC_07
0.722
EC_08
0.667
EC_13
0.610
, Variable names and associations are presented in Appendix A.
aterfall exploratory factor analysis modelling
W
of environmental complexity
The Waterfall EFA model came in at a KMO of 0.720, which is
low but acceptable. Extraction values were sufficiently above
the 0.3 threshold. Total variance was 53% and met adequacy
criteria. Individual factor loadings were above 0.5 where
Factor 1 averaged 0.704 and Factor 2, 0.696 (Table 6.9). This
discrepancy was addressed via Cronbach alpha tests where
the results were 0.799 and 0.793 for Factor 1 and Factor 2.
respectively. The correlation matrix revealed a low, accepted
correlation of 0.303.
The groupings are further reiterated in Figure 6.10.
The exploratory model for Waterfall projects is presented in
Figure 6.11 and shows a different take on environmental complexity
124
Chapter 6
Factor plot in rotated factor space
1.0
EC_09
EC_07
EC_08
EC_13
0.5
Factor 2
EC_11
EC_03
0.0
EC_02
EC_01
–0.5
–1.0
–1.0
–0.5
0.0
0.5
1.0
Factor 1
FIGURE 6.10: Environmental complexity factor plot diagram (Waterfall).
Stakeholder management
Project site and location
•
•
•
•
Weather conditions
Remoteness of location
Experience in country
Environmental risks
Environmental
complexity
(Waterfall)
• Number of stakeholders
• Variety of stakeholder
perspectives
• Political influence
• Stability of project
environment
FIGURE 6.11: Exploratory model for environmental complexity (Waterfall).
Stakeholder continues to manifest for Waterfall projects,
which arguably confirms its importance regardless of project
methodology. Waterfall projects include complexity related to
project environment stability and implies that Waterfall projects
are affected more significantly when the environment is unstable.
This could be attributed to the rigid, structured nature of the
125
Symbiosis between IS project success and complexity
Waterfall method where a systematic approach is adopted and
complied with from the outset. Project site and location is the
second latent factor identified which differs significantly from the
Overall and Agile views. Interestingly, Waterfall projects place more
emphasis on weather conditions, location remoteness, experience
in country and environmental risks. The remaining complexity
features were omitted. Environmental risks in the context of
Waterfall projects arguably pertain to site and location risks more
than anything else. Waterfall projects thrive on extensive upfront
planning which aims to negate future issues. This could be why
physical environmental aspects plan such an important role as
they are often underestimated or not completely understood.
The following section covers the remaining IS project
complexity constructs and their EFA analysis.
echnical complexity, dynamics and
T
uncertainty
Technical complexity, dynamics and uncertainty were mapped
within the process and project management success scope.
This formed the basis for the next EFA analysis as these three
constructs were analysed together to determine complexities
which are associated with the first two IS project success levels.
verall exploratory factor analysis
O
modelling of technical complexity,
dynamics and uncertainty
Similar to previous modelling practice, the same validity and
reliability measures were adopted. The KMO is 0.933 while all
extraction values are above 0.3. The five factors presented in Table
6.10 provide a total variance of 56% which is acceptable. Factor
loadings meet the acceptance criteria thus Cronbach’s alpha is
used to determine further reliability. The results are 0.901, 0.883,
0.848, 0.835 and 0.812 for Factor 1 to Factor 5 respectively. All
results are sufficiently above the acceptance level of 0.7 and thus
126
Chapter 6
TABLE 6.10: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix.
Observed
variable*
U_05
Factor
1 (0.901)
2 (0.883)
4 (0.835)
5 (0.812)
0.869
U_06
0.791
U_04
0.788
U_01
0.738
U_10
0.651
U_08
0.637
U_07
0.629
U_02
0.613
U_09
0.547
U_03
0.516
D_02
1.067
D_04
0.772
D_03
0.731
D_01
0.547
D_05
0.473
D_06
0.459
TC_07
3 (0.848)
0.948
TC_08
0.911
TC_06
0.576
TC_12
0.529
TC_05
0.391
TC_09
0.326
TC_03
0.870
TC_04
0.780
TC_02
0.542
TC_11
0.969
TC_10
0.667
, Variable names and associations are presented in Appendix A.
a
confirm the identified factors. Discriminant validity is achieved as
the factor correlation matrix reveals no correlations above 0.7.
As discussed previously, a factor plot diagram cannot be used
where more than three factors exist as the diagram is no longer
decipherable and provides no extra analysis value.
As per Figure 6.12, the EFA results revealed five factors, (1)
technology experience, (2) project goals, (3) project scope and
tasks, (4) dynamics and (5) uncertainty.
127
Symbiosis between IS project success and complexity
Technology experience
Project goals
• Newness of
technology
• Number of goals
• Experience with
technology
• Clarity of goals
Change management
• Change process
• Number of changes
• Scope of changes
• Frequency of changes
• Impact of changes
• Change over time
• Goal alignment
Technical,
Dynamics
and Uncertainty
complexity
Project scope and tasks
• Scale of scope
• Quality requirements
• Number of tasks
• Variety of tasks
• Conflicting norms and
standards
• Technical risks
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Uncertainty of goals and
objectives
• Technological maturity
and novelty
• Undisclosed participants
• Competency
• Incomplete information
FIGURE 6.12: Exploratory model for technical complexity, dynamics and uncertainty of
information system projects.
IS projects experience complexities regarding technology
usage as experience and adoption are the two features to be
constantly monitored. Given that IS projects thrive on technology
usage, whether as a project tool or for project implementation,
technology plays a pivotal role as experience is necessary for
effective usage. Furthermore, experience should be facilitated
through continuous development of project team members to
ensure they use appropriate technology for any given IS project.
The latent factor of project goals was apparent and signified the
importance of effective goal management. The number of goals
together with goal clarity and alignment are three prerequisites
required for any project, regardless of the methodology
employed. Complexities associated with these three features are
arguably the key reasons why IS projects perform poorly and
128
Chapter 6
do not deliver planned benefits. IS project managers and their
teams become so obsessed with delivering within time and cost
that key fundamentals like goal delivery are negated. Moreover,
project goals relate directly to the next factor of project scope
and tasks. Project tasks are based on the project scope, which
in turn is directly influenced by the set goals. The scale of the
scope determines the number and variety of tasks required
to execute the project. Conflicting norms and standards do,
however, hinder tasks and activities as various stakeholders
abide by different policies and procedures especially with regard
to their requirements. This is arguably evident by the inclusion of
technical risk in the project scope and tasks factor as risks arise
when transitioning from scoping activities to actual project task
execution.
The fourth factor perfectly maps the six features of dynamics
to change management as argued in the theoretical mappings
presented in Chapter 3. Change management is paramount to IS
projects as the intangible nature of these projects often results in
multiple changes as required particularly during implementation.
Change practices therefore have to be sound and promote
effective change regardless of what is required. Furthermore,
not all changes are positive as previously mentioned, thus these
changes must be mitigated and addressed through a robust set
of practices. The following question can thus be posed: What
change practices should be in place for IS projects to maintain
their momentum and experience minimal disruption? Future
research should address this contentious question. The final
factor of uncertainty also fully encapsulates the theoretical
mappings presented in Chapter 3 and confirms the role of
uncertainty in IS projects. Rather than focusing on what is
known, IS projects should be cognisant of what is unknown so
that when the uncertainty arises a more proactive mindset is
instilled for addressing uncertainty. Awareness does not imply
that a plan exists for any uncertainty incident, it implies that the
overall impact is recognised and will not be a ‘shock’ for parties
involved.
129
Symbiosis between IS project success and complexity
gile exploratory factor analysis modelling
A
of technical complexity, dynamics and
uncertainty
The Agile EFA has a KMO of 0.858 and all extraction values are
above 0.3. Total variance explained equalled 58%, which is well
within the threshold criterion. Only Factor 1 has factor loading
lower than 0.5 but Cronbach’s alpha was performed regardless
as part of the reliability check. Factor 1 to Factor 5 have Cronbach
alpha’s of 0.892, 0.856, 0.786, 0.800 and 0.782 respectively.
Factor loading validity and reliability is therefore confirmed.
The factor correlation matrix (Table 6.11) also confirmed
discriminant validity as no correlation above 0.7 exists.
TABLE 6.11: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix (Agile).
Observed
variablea
Factor
1 (0.892)
TC_07
0.991
TC_12
0.769
TC_08
0.754
TC_06
0.685
TC_01
0.599
TC_05
0.594
TC_09
0.434
2 (0.856)
U_05
0.804
U_04
0.778
U_01
0.737
U_10
0.594
U_02
0.573
U_07
0.532
U_03
0.521
U_08
0.515
3 (0.786)
D_02
1.054
D_04
0.583
4 (0.800)
TC_11
1.014
TC_10
0.556
5 (0.782)
TC_04
1.033
TC_03
0.534
, Variable names and associations are presented in Appendix A.
a
130
Chapter 6
The five factors are identified as per Figure 6.13:
••
•
•
•
•
Factor
Factor
Factor
Factor
Factor
1: Project scope and tasks.
2: Uncertainty.
3: Change management.
4: Technology experience.
5: Project goals.
Although the factors are similar to the overall view of IS
projects, their composition is somewhat different.
Agile projects seem to have the added complexity of multiple
inputs and outputs. IS projects use and produce various inputs and
outputs throughout until final delivery. Agile projects arguably have
more inputs and outputs as the iterative philosophy leads to multiple
instances of these events. Furthermore, managing multiple inputs
and outputs can become a cumbersome process and escalate to a
point where the Agile mindset is its own worst enemy. Uncertainty
is the second factor which also has a different composition as goal
and objective as well as competency uncertainty are omitted.
Goal and objective uncertainty is possibly less of a ‘bugbear’ as
Agile embraces changes through flexible adaptive practices. More
interestingly is the exclusion of competency uncertainty which
contends that competency deficiencies could hamper a project’s
Project scope and tasks
• Number and diversity of
inputs and/or outputs
• Scale of scope
• Quality requirements
• Number of tasks
• Variety of tasks
• Conflicting norms and
standards
• Technical risks
Technology experience
• Newness of technology
• Experience with technology
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Technological maturity
and novelty
• Undisclosed participants
• Incomplete information
Technical,
Dynamics
and Uncertainty
complexity
(Agile)
Change management
• Number of changes
• Scope of changes
Project goals
• Goal alignment
• Clarity of goals
FIGURE 6.13: Exploratory model for technical complexity, dynamics and uncertainty (Agile).
131
Symbiosis between IS project success and complexity
progress. Agile projects also embrace competency deficiencies by
identifying these as they occur and addresses them while continuing
with the project. Furthermore, the flexibility promoted by Agile
allows resources reallocation especially for skill set acquisition.
Change management is only represented by the number and scope
of changes for Agile projects. The omission of other features implies
Agile projects are only concerned with the number and scope of
changes. Logically this makes sense given the iterative approach
adopted. An argument could be made that an overwhelming number
of changes and/or extensive change scopes could derail change
management practices. Addressing these two complexities would
indirectly address the omitted features of change management.
Technology experience remains stable as the two features are the
same as the Overall view. Project goals, on the other hand, have also
changed relatively as only goal alignment and clarity are considered
complexities for Agile projects. The number of goals is no longer
an issue as the Agile method promotes incremental development
where multiple goals are addressed efficiently. However, there
has to be clear alignment between goals to ensure Agile practices
deliver the correct project and business benefits.
aterfall exploratory factor analysis modelling
W
of technical complexity, dynamics and
uncertainty
The EFA process for Waterfall projects has an acceptable KMO of
0.876 and extraction values above the 0.3 threshold (Table 6.12).
Total variance explained is an excellent 62%. The factor loadings
required reliability confirmation using Cronbach’s alpha. Factor 1
to Factor 5 have alphas of 0.884, 0.888, 0.827, 0.747 and 0.863
respectively. Discriminant validity is accepted as no correlations
above 0.7 exist in the factor correlation matrix.
The five factors are once again similar as presented in Figure 6.14:
•• Factor 1: Uncertainty.
• Factor 2: Change management.
• Factor 3: Technology experience.
132
Chapter 6
TABLE 6.12: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix (Waterfall).
Observed
variablea
U_04
Factor
1 (0.884)
2 (0.888)
3 (0.827)
4 (0.747)
5 (0.863)
0.813
U_06
0.809
U_05
0.804
U_01
0.674
U_08
0.625
U_10
0.606
U_03
0.595
U_02
0.575
TC_05
0.300
D_02
1.015
D_03
0.821
D_04
0.732
D_01
0.552
D_06
0.475
U_09
0.394
TC_11
0.898
TC_10
0.809
TC_12
0.595
TC_08
0.996
TC_07
0.485
TC_03
0.723
TC_04
0.664
, Variable names and associations are presented in Appendix A.
a
• Factor 4: Project scope and tasks.
• Factor 5: Project goals.
The composition has once again changed for Waterfall projects.
The uncertainty factor now includes uncertainty of goals and
objectives but omits competency and technological maturity
and novelty. This implies competency is not a complexity feature
and that technological maturity and novelty do not influence
Waterfall projects. Interestingly, scale of scope is included
which is commonly associated with project scope complexities.
This grouping implies that scale of scope has inherent
uncertainties regardless of project requirement size. Change
management excludes the impact of changes but encapsulates
133
Symbiosis between IS project success and complexity
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Uncertainty of goals and
objectives
• Undisclosed participants
• Incomplete information
• Scale of scope
Project scope and tasks
• Number of tasks
• Variety of tasks
Change management
Technology experience
• Change process
• Number of changes
• Scope of changes
• Frequency of changes
• Change over time
• Competency
• Newness of technology
• Experience with
technology
• Technical risks
Technical,
Dynamics
and Uncertainty
complexity
(Waterfall)
Project goals
• Goal alignment
• Clarity of goals
FIGURE 6.14: Exploratory model for technical complexity, dynamics and uncertainty
(Waterfall).
the remaining five features based on the theoretical mappings.
The surprising inclusion of competency in change management
begs the question of whether adequate competencies exist for
addressing any change request in Waterfall projects. It could be
that competencies required to implement changes are inadequate
and lacking thus resulting in deferred delivery date. Technology
experience expands to include technical risks, which is arguably
a logical inclusion given that technology inherently has risks
associated with it regardless of experience or newness. Waterfall
projects are only concerned with the number of tasks and variety
of task complexities. These low level complexities pertain to the
planning phase of project management as the Waterfall method
places emphasis on extensive details. Any planning discrepancies
which arise during subsequent phases result in derailing the
project as tasks have to be reallocated and realigned on an ad
hoc basis. This inadvertently delays other aspects of an IS project.
Project goals is the fifth and final factor for Waterfall projects.
Similar to Agile projects, goal alignment and clarity are the two
pillars supporting project goal complexity. Given that Waterfall
projects emphasise upfront planning, any volatility with either
feature results in adverse effects on all project activities.
134
Chapter 6
Conclusion
The gathered data indicated that, in the information systems
project industry, we are dealing with various levels of project
success. How they operate in practice may differ slightly in detail.
Regardless of which method or approach is followed, IS project
managers are aware of process success, strategic success,
project management success and, most vitally, deliverable or
product success. It can be surmised that this is the focus of IS
project management when it is viewed holistically.
Remarkably very few differences are observed between Agile
and Waterfall projects. In most respects they are very similar.
The following differences are observed:
1. The overall correlations between the factors in Waterfall
projects are stronger than in those of Agile projects. This
could indicate that the structured and more formalised
approach of Waterfall projects have greater effects on
subsequent levels of projects success.
2. Objectives and goals seem to be important to Waterfall
projects in the process success factor, while in Agile projects
these considerations are important in the deliverable success
factor. This may point to a difference in focus between the
two methods.
3. The aspect of governance seems to play a role with Waterfall
projects and not at all with Agile projects. This may once again
be a symptom with regard to the underlying philosophy of
each. What could be at issue here is the fact that the
respondents indicated their own perceptions and as such
improperly utilise governance in projects.
What holds for all three confirmed models is the fact that there
does seem to be medium to strong interrelationships between
all these factors. As these factors can be mapped to Bannerman
(2008) levels, this dataset indicates that the outcome of lower levels
could have an impact on higher levels. Therefore it is important
to successfully complete project processes in order to facilitate
project deliverable success as well as ultimate strategic success.
135
Symbiosis between IS project success and complexity
The EFA analysis of the various constructs clearly and
interestingly showed that, although each environment has the
same number of latent factors, the composition of factors is often
different. Arguing that project complexity is uniform regardless
of type is clearly rejected, as these results show that within the
IS project landscape there are variations when adopting the
prevalent approaches of Systems Development Life Cycle and
Agile. IS project complexity is clearly not uniform or consistent as
different complexities are evident depending on methodology.
The exploratory nature of the complexity results suggests further
investigation to validate the above claims as more variation could
occur upon further analysis. The EFA models presented act as
preliminary results and form the foundation of further studies.
136
Chapter 7
Simple, complicated,
complex and chaos
The conclusion that one can make at the end of this book is that
IS project success and IS project complexity is not about absolute
numbers but more about a mindset. This mindset should be
focused on two aspects: The first aspect is that IS project success
is measured on a continuum and the second aspect is that IS
project complexity needs to be appreciated for what it is, that is
complex.
The framework of Bannerman (2008) is used to create this
mindset of IS project success as a continuum. Five levels exist
within this framework, and an IS project can be successful
at any one of these levels. The preference is that the project
should be successful at all five levels but this is not possible
in real life. Each level addresses a different aspect of success.
More importantly, the framework forces all the stakeholders
to take ownership for IS project success. IS project success is
not the responsibility of just the project manager but it is the
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Simple, complicated,
complex and chaos’, in The symbiosis between information system project complexity
and information system project success, pp. 137–140, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.07
137
Simple, complicated, complex and chaos
responsibility of all the stakeholders. Specific stakeholders will
have different inputs, insights and influences at the different
levels, but at the end of the day it is everyone’s responsibility to
ensure IS project success.
The results depicted in Chapter 4 highlight that the success
rates have improved. This improvement is directly related to the
fact that success is measured on a continuum. When the results
are interrogated a little further, it is evident that success at a
business and strategic level is still at 62% and 59% respectively.
This creates an opportunity for organisational leaders to improve
the success rates and reap more benefits and value from the
investment in IT. The results also indicate that Agile projects
are more successful than Waterfall projects. This can result in
a product that is delivered by an Agile project being released
quicker to the market, thereby creating faster business and
strategic success than Waterfall projects. It might be worthwhile
for organisational leaders to invest in Agile as a method to deliver
IS projects quicker. This said, the emphasis should still be on
delivering these types of projects successfully at all five levels.
The modelling of the success levels reduced the five levels
to four levels. The last two levels (business and strategic) are
merged into one level, that is strategic success. IS project success
can then ultimately be measured as per Figure 7.1.
Although the framework of Bannerman indicates that there
is not necessarily a relationship between the different levels,
that is one level does not necessarily affect the outcome of the
next level, the results of SEM indicate that there are positive
correlations between the different levels. This implies that the
outcome of lower levels influences the outcome of higher levels.
Process
succes
Project
management
success
Deliverable
success
FIGURE 7.1: Information system project success levels.
138
Strategic
success
Chapter 7
IS project complexity itself is complex. Five constructs of
complexity were identified simplifying the view of complexity.
But beyond this simplified view, there are still 75 complexity
features that need to be taken into consideration. The problem is
that these 75 complexity features can appear in any combination
within an IS project. This opens the door for an IS project to
change from complex to chaos within the blink of an eye. The
analysis of the top five features in every construct make one
realise that there is actually no complexity feature that is more
important than another or that one construct is more important
than another construct. The results do suggest that technical
and organisational complexity are the two main constructs that
contribute to the complexity of IS projects.
The modelling of complexity did not yield the desired
results and only a suggestion of a possible model is provided.
The modelling suggests that environmental complexity can be
divided into stakeholder complexity and strategic complexity.
Organisational complexity is intricate and should be dealt with
in its entirety. The remaining three complexity constructs can
be divided into five new constructs. This implies that the IS
complexity can be viewed as eight new constructs instead of the
original five constructs. Whether this makes IS complexity less
complex, remains to be seen.
The symbiotic relationship between IS project success and
IS project complexity cannot be negated. This study could not
provide a definite answer to the problem at hand. Figure 7.2
provides insight into this symbiotic relationship.
Complexity plays a significant role during the lower levels
of IS project success as all eight constructs have an impact on
process and project management success. When it comes to
the deliverable and strategic success, then only three constructs
play a role.
What should organisational leaders and specifically IS project
managers do in the face of complexity? The impression is created
139
Simple, complicated, complex and chaos
Organisational complexity + Stakeholder complexity + Strategic/Tactical complexity
Process success
Project
management
success
Deliverable
success
Strategic success
Technology experience complexity
Project goal complexity
Project scope complexity
Change management complexity
Uncertainty
FIGURE 7.2: Symbiotic IS project success and complexity model.
that when IS project managers can manage the complexity
surrounding IS projects, then there is a better chance that these
projects will be delivered successfully.
Snowden and Boone (2007:69) state that ‘wise executives
tailor their approach to fit the complexity of the circumstances
they face.’ This is also applicable to IS project managers that
need to understand what they should do. The first step is to
identify the level of complexity within the IS project. Four levels
of complexity exist, namely simple, complicated, complex and
chaotic. IS project managers should manage simple, complicated
and complex projects in such a way that they do not become
chaotic. The line between complex and chaotic is very thin.
In conclusion, IS project managers cannot rely on the normal
competencies as promoted by the various project management
competency frameworks. They need to have additional
competencies to deal with complexity as the IS domain will become
more and more complex in the near future. This new understanding
of complexity will allow IS project managers to address complexity
and understand the impact it has on the success of a project.
Knowledge and wisdom of IS project complexity will increase
the success of IS projects and ultimately the value that IT provides
to the organisation.
140
Appendix
1. Project success variables
Construct
Feature
Process success
Chosen
PS_01
Alignment
PS_02
Deliverable success
Business success
Strategic success
Variable Name
Integrated
PS_03
Implemented
PS_04
Specifications Met
DS_01
Requirements Met
DS_02
User Expectations
DS_03
User Acceptance
DS_04
Product Used
DS_05
User Satisfied
DS_06
Benefits Realised
DS_07
Goals
BS_01
Business Plan
BS_02
Governance
BS_03
Benefits Realisation
BS_04
Unintended Benefits
BS_05
Unintended Impacts
BS_06
Market Impact
SS_05
Industry Impact
SS_05
Competitive Impact
SS_05
Investor Impact
SS_05
Regulatory Impact
SS_05
141
Appendix
2. Project complexity variables
Construct
Element
Feature
Organisational
complexity
Vertical differentiation
Organisational structure
Horisontal differentiation Organisational units
Size
Resources
Project team
Trust
142
Variable
Name
OC_01
OC_02
Task structure
OC_03
Project duration
OC_04
Variety of methods and tools
OC_05
Capital expenditure
OC_06
Work hours
OC_07
Project team
OC_08
Site area
OC_09
Number of locations
OC_10
Project drive
OC_11
Resource and skills availability
OC_12
Experience with involved parties
OC_13
Health, safety, security and
environment (HSSE) awareness
OC_14
Interfaces between different
disciplines
OC_15
Number of financial resources
OC_16
Contract types
OC_17
Number of different nationalities
OC_18
Number of different languages
OC_19
Cooperation with joint-venture
partner
OC_20
Overlapping office hours
OC_21
Trust in project team
OC_22
Trust in contractor
OC_23
Risk
Organisational risks
OC_24
Interdependencies
Environmental dependencies
OC_25
Resource sharing
OC_26
Schedule dependencies
OC_27
Interconnectivity and feedback
loops in task and project networks
OC_28
Dependencies between actors
OC_29
Information systems dependencies
OC_30
Objective dependencies
OC_31
Process interdependencies
OC_32
Stakeholder interrelations
OC_33
Team cooperation and
communication
OC_34
Appendix
2. Project complexity variables
(continues...)
Construct
Element
Feature
Technical
complexity
Differentiation
Number and diversity of inputs
and/or outputs
Goals
Number of goals
TC_02
Goal alignment
TC_03
Clarity of goals
TC_04
Scope
Tasks
Experience
Environmental
complexity
Location
Market conditions
Uncertainty
Risk
Triple constraint
Activity
Goals
Technology
Stakeholders
Dynamics
Information
Change management
TC_01
Scale of scope
TC_05
Quality requirements
TC_06
Number of tasks
TC_07
Variety of tasks
TC_08
Conflicting norms and standards
TC_09
Newness of technology
TC_10
Experience with technology
Risk
Stakeholders
Variable
Name
Technical risks
Number of stakeholders
Variety of stakeholder perspectives
Political influence
Internal support
Required local content
Interference with existing site
Weather conditions
Remoteness of location
Experience in country
Internal strategic pressure
Stability of project environment
Level of competition
Environmental risks
Uncertainties in scope
Uncertainties in cost
Uncertainties in time
Uncertainty in methods
Task uncertainty
Uncertainty of goals and objectives
Technological maturity and novelty
Undisclosed participants
Competency
Incomplete information
Change process
Number of changes
Scope of changes
Frequency of changes
Impact of changes
Change over time
TC_11
TC_12
EC_01
EC_02
EC_03
EC_04
EC_05
EC_06
EC_07
EC_08
EC_09
EC_10
EC_11
EC_12
EC_13
U_01
U_02
U_03
U_04
U_05
U_06
U_07
U_08
U_09
U_10
D_01
D_02
D_03
D_04
D_05
D_06
143
References
Chapter 1
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences, Hawaii, 04–07 January.
Boehm, B., 2006, ‘A view of 20th and 21st century software engineering’, Paper
presented at the 28th International Conference on Software Engineering
Proceedings, New York, 20–28 May.
Cooke-Davies, T., 2016, The strategic impact of projects – Identify benefits to
drive business results, Newtown, PA, viewed 09 February 2017, from http://
www.pmi.org/learning/thought-leadership/pulse/identify-benefits-businessresults.
Curley, M., Kenneally, J. & Carcary, M., 2016, IT Capability Maturity Framework™
(IT-CMF™), 2nd edn., Van Haren Publishing, Zaltbommel.
Denscombe, M., 2010, The good research guide: For small-scale social research
Projects, McGraw-Hill Education, New York.
Dorfman, M. & Thayer, R.H., 2000, Software requirements engineering, 2nd edn.,
IEEE Computer Society Press, Los Alamitos, CA.
Harris, M.D.S., Herron, D. & Iwanicki, S., 2008, The business value of IT, Taylor &
Francis, Boca Raton, FL.
IT Governance Institute, 2012, CobiT 5, ITGI, Rolling Meadows, IL.
Labuschagne, L. & Marnewick, C., 2009, The prosperus report 2008: IT Project
Management Maturity versus Project Success in South Africa, Project
Management South Africa, Johannesburg.
Leffingwell, D., 2011, Agile software requirements lean requirements practices for
teams, programs, and the enterprise, Addison-Wesley, Boston, MA.
Lovelock, J.-D., Hale, K., Hahn, W.L., Atwal, R., Graham, C. & Gupta, N., 2017,
Forecast alert: IT spending, worldwide, 4Q16 update, Stamford, CT, viewed
11 April 2017, from https://www.gartner.com/doc/3567217/forecast-alert-itspending-worldwide.
Marnewick, C. (ed.), 2013, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C. & Labuschagne, L., 2010, ‘Linking project benefits to strategic
objectives: An exploratory investigation’, Paper presented at the 6th
Biennial National Conference and Exhibition, Birchwood Conference Centre,
Johannesburg, 06–08 September.
144
References
Marnewick, C. & Labuschagne, L., 2011, ‘An investigation into the governance of
information technology projects in South Africa’, International Journal of Project
Management 29(6), 661–670. https://doi.org/10.1016/j.ijproman.2010.07.004
Martinsuo, M., Gemünden, H.G. & Huemann, M., 2012, ‘Toward strategic value from
projects’, International Journal of Project Management 30(6), 637–638. https://
doi.org/10.1016/j.ijproman.2012.03.006
Royce, W.W., 1970, ‘Managing the development of large software systems:
Concepts and techniques’, Paper presented at the 1970 WESCON Technical
Papers volume 14, Western Electronic Show and Convention, Los Angeles, CA,
25–28 August.
Sekaran, U., 2003, Research methods for business: A skill building approach, John
Wiley & Sons, Hoboken, NJ.
Sommerville, I., 2001, Software engineering, 6th edn., Addison-Wesley, Harlow.
Sonnekus, R. & Labuschagne, L., 2003, The prosperus report 2003, RAU Standard
Bank Academy for Information Technology, Johannesburg.
The Standish Group, 2014, Chaos Manifesto 2014, The Standish Group International,
Boston, MA.
Thomas, R.M., 2003, Blending qualitative and quantitative research methods in
theses and dissertations, Sage, Thousand Oaks, CA.
Chapter 2
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences,Hawaii, 04–07th January.
Barclay, C., 2015, ‘A Dialogue on the Diversity in the Constituents of Project
Success’, in Strategic project management: Contemporary issues and strategies
for developing economies, pp. 13–30, CRC Press, Barclay.
Bourne, L., 2011, Project failure: Cobb’s paradox, viewed 12 October 2016, from
https://pmhut.com/project-failure-cobbs-paradox.
Budzier, A. & Flyvbjerg, B., 2015, Why do projects fail?, Social Sciences Research
Network, New York.
Cooke-Davies, T., 2002, ‘The “real” success factors on projects’, International
Journal of Project Management 20(3), 185–190. https://doi.org/10.1016/S02637863(01)00067-9
Coombs, C.R., 2015, ‘When planned IS/IT project benefits are not realized: A study of
inhibitors and facilitators to benefits realization’, International Journal of Project
Management 33(2), 363–379. https://doi.org/10.1016/j.ijproman.2014.06.012
Davis, K., 2014, ‘Different stakeholder groups and their perceptions of project
success’, International Journal of Project Management 32(2), 189–201. https://
doi.org/10.1016/j.ijproman.2013.02.006
145
References
Erasmus, L.J., Marnewick, C. & Joseph, N., 2014, ‘The idle state of ICT projects in
South Africa’, Journal of African Business Management 15(3), 184–196.
Gerow, J.E., Thatcher, J.B. & Grover, V., 2015, ‘Six types of IT-business strategic
alignment: An investigation of the constructs and their measurement’,
European Journal of Information Systems 24(5), 465–491.
Jenner, S., 2016, Transforming government and public services: Realising benefits
through project portfolio management, CRC Press, Boca Raton, FL.
Johnson, J., 2014, The CHAOS Manifesto, The Standish Group, Boston, MA.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Kaiser, M.G., El Arbi, F. & Ahlemann, F., 2015, ‘Successful project portfolio
management beyond project selection techniques: Understanding the role
of structural alignment’, International Journal of Project Management 33(1),
126–139. https://doi.org/10.1016/j.ijproman.2014.03.002
Lovelock, J.-D., Hale, K., Hahn, W.L., Atwal, R., Graham, C. & Gupta, N., 2017,
Forecast alert: IT spending, worldwide, 4Q16 update, Stamford, CT, viewed,
11 April 2017, from https://www.gartner.com/doc/3567217/forecast-alert-itspending-worldwide.
Marnewick, C. (ed.), 2013a, Propsperus report, The African edition: Project
management maturity vs. project outcomes in Africa, Project Management
South Africa, Johannesburg.
Marnewick, C. (ed.), 2013b, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C., 2016, ‘Benefits of information system projects: The tale of two
countries’, International Journal of Project Management 34(4), 748–760.
https://doi.org/10.1016/j.ijproman.2015.03.016
Marnewick, C. & Erasmus, W., 2014, ‘Improving the competence of project managers:
Taking an Information Technology project audit’, Paper presented at the PMI
Research and Education Conference 2014, Portland, OR, 27–29 July.
Marnewick, C., Erasmus, W. & Joseph, N., 2016a, Information technology
Project managers’ compentencies: An analysis of performance and personal
competencies, viewed 09 March 2017, from http://www.books.aosis.co.za/
index.php/ob/catalog/book/30
Marnewick, C., Erasmus, W. & Joseph, N., 2016b, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Mir, F.A. & Pinnington, A.H., 2014, ‘Exploring the value of project management:
Linking project management performance and project success’, International
Journal of Project Management 32(2), 202–217. https://doi.org/10.1016/j.
ijproman.2013.05.012
Monteiro de Carvalho, M., 2013, ‘An investigation of the role of communication
in IT projects’, International Journal of Operations & Production Management
34(1), 36–64. https://doi.org/10.1108/IJOPM-11-2011-0439
146
References
Ngoma, M. & Erasmus, W., 2016, ‘Maturity of IT governance in the South African
public sector’, Paper presented at the International Association for the
Management of Information Technology 2017, Orlando, FL, May.
Project Management Institute, 2013, A guide to the project management body of
knowledge (PMBOK Guide), 5th edn., Project Management Institute, Newtown
Square, PA.
Rosemann, M. & Vom Brocke, J., 2015, ‘The six core elements of business process
management’, in J. vom Brocke & M. Rosemann (eds.) Handbook of business
process management, 1, pp. 105–122, Springer, Heidelberg.
Schwalbe, K., 2016, Information technology project management, 8th edn.,
Cengage Learning, Boston, MA.
Serra, C.E.M. & Kunc, M., 2015, ‘Benefits realisation management and its influence
on project success and on the execution of business strategies’, International
Journal of Project Management 33(1), 53–66. https://doi.org/10.1016/j.
ijproman.2014.03.011
Turk, D., France, R. & Rumpe, B., 2014, ‘Limitations of agile software processes’,
arXiv preprint arXiv:1409.6600.
Whyte, J., Lindkvist, C. & Jaradat, S., 2016, ‘Passing the baton? Handing over
digital data from the project to operations’, Engineering Project Organization
Journal 6(1), 2–14. https://doi.org/10.1080/21573727.2015.1115396
Chapter 3
Ahern, T., Leavy, B. & Byrne, P.J., 2014, ‘Complex project management as complex
problem solving: A distributed knowledge management perspective’,
International Journal of Project Management 32(8), 1371–1381. https://doi.
org/10.1016/j.ijproman.2013.06.007
Ahmed, A., 2012, Software project management: A process-driven approach,
Taylor & Francis, London, England.
Asher, H., 2013, Theory-building and data analysis in the social sciences, University
of Tennessee Press, Knoxville, TN.
Baccarini, D., 1996, ‘The concept of project complexity – A review’, International
Journal of Project Management 14(4), 201–204. https://doi.org/10.1016/02637863(95)00093-3
Badampudi, D., Wohlin, C. & Petersen, K., 2015, ‘Experiences from using snowballing
and database searches in systematic literature studies’, Paper presented
at the Proceedings of the 19th International Conference on Evaluation and
Assessment in Software Engineering, Nanjing, China, 27–29 April.
Bakhshi, J., Ireland, V. & Gorod, A., 2016, ‘Clarifying the project complexity construct:
Past, present and future’, International Journal of Project Management 34(7),
1199–1213. https://doi.org/10.1016/j.ijproman.2016.06.002
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. https://doi.org/10.1016/0263-7863(95)00064-X
147
References
Bosch-Rekveldt, M., Jongkind, Y., Mooi, H., Bakker, H. & Verbraeck, A., 2011,
‘Grasping project complexity in large engineering projects: The TOE (Technical,
Organizational and Environmental) framework’, International Journal of Project
Management 29(6), 728–739. https://doi.org/10.1016/j.ijproman.2010.07.008
Brown, C.J., 2008, ‘A comprehensive organisational model for the effective
management of project management’, South African Journal of Business
Management 39(3), 1–10.
Chan, F.K.Y. & Thong, J.Y.L., 2009, ‘Acceptance of agile methodologies: A critical
review and conceptual framework’, Decision Support Systems 46(4), 803–814.
https://doi.org/10.1016/j.dss.2008.11.009
Cooke-Davies, T., 2002, ‘The “real” success factors on projects’, International
Journal of Project Management 20(3), 185–190. https://doi.org/10.1016/S02637863(01)00067-9
Cooke-Davies, T., Cicmil, S., Crawford, L. & Richardson, K., 2007, ‘We’re not in Kansas
anymore, Toto: Mapping the strange landscape of complexity theory, and its
relationship to project mangement’, Project Management Journal 38(2), 50–61.
Derbyshire, J., 2016, ‘The implications, challenges and benefits of a complexityorientated futures studies’, Futures 77, 45–55. https://doi.org/10.1016/j.
futures.2016.02.001
Deutsch, M.S., 1991, ‘An exploratory analysis relating the software project
management process to project success’, IEEE Transactions on Engineering
Management 38(4), 365–375. https://doi.org/10.1109/17.97444
Dhingra, S. & Sampson, T., 2016, Life after BREXIT: What are the UK’s options
outside the European Union?, London School of Economics and Political
Science, London.
Dube, S. & Marnewick, C., 2016, ‘A conceptual model to improve performance in
virtual teams’, SA Journal of Information Management 18(1), 1–10.
Dunović, I.B., Radujković, M. & Škreb, K.A., 2014, ‘Towards a new model of
complexity – The case of large infrastructure projects’, Procedia – Social and
Behavioral Sciences 119, 730–738. https://doi.org/10.1016/j.sbspro.2014.03.082
Flick, U., 2014, An introduction to qualitative research, Sage, London.
Floricel, S., Michela, J.L. & Piperca, S., 2016, ‘Complexity, uncertainty-reduction
strategies, and project performance’, International Journal of Project
Management 34(7), 1360–1383. https://doi.org/10.1016/j.ijproman.2015.11.007
Frank, M., Sadeh, A. & Ashkenasi, S., 2011, ‘The relationship among systems engineers’
capacity for engineering systems thinking, project types, and project success’,
Project Management Journal 42(5), 31–41. https://doi.org/10.1002/pmj.20252
Gällstedt, M., 2003, ‘Working conditions in projects: Perceptions of stress and
motivation among project team members and project managers’, International
Journal of Project Management 21(6), 449–455. https://doi.org/10.1016/s02637863(02)00098-4
Geraldi, J., Maylor, H. & Williams, T., 2011, ‘Now, let’s make it really complex
(complicated): A systematic review of the complexities of projects’,
International Journal of Operations & Production Management 31(9), 966–990.
https://doi.org/10.1108/01443571111165848
148
References
Geraldi, J.G., 2008, ‘Patterns of complexity: The thermometer of complexity’,
Project Perspectives XXIX, 4–9.
Geraldi, J.G. & Adlbrecht, G., 2007, ‘On faith, fact, and interaction in projects’,
Project Management Journal 38(1), 32–43.
Green, G.C., 2004, ‘The impact of cognitive complexity on project leadership
performance’, Information and Software Technology 46(3), 165–172. https://
doi.org/10.1016/S0950-5849(03)00125-3
Hass, K.B., 2009, Managing complex projects: A new model, Management
Concepts, Vienna, VA.
Hastie, S. & Wojewoda, S., 2015, Standish Group 2015 Chaos Report – Q&A with
Jennifer Lynch, viewed 06 January 2016, from http://www.infoq.com/articles/
standish-chaos-2015.
Heaslip, R.J., 2015, Managing organizational complexity: How to optimize the
governance of programs and projects to improve decision making, Project
Management Institute, Newtown, PA.
Hobday, M., 2000, ‘The project-based organisation: An ideal form for managing
complex products and systems?’, Research Policy 29(7–8), 871–893. https://
doi.org/10.1016/S0048-7333(00)00110-4
Ika, L.A., 2009, ‘Project success as a topic in project management journals’,
Project Management Journal 40(4), 6–19, https://doi.org/10.1002/pmj.20137
Jalali, S. & Wohlin, C., 2012, ‘Systematic literature studies: Database searches
vs. backward snowballing’, Paper presented at the Proceedings of the
ACM-IEEE International Symposium on Empirical Software Engineering and
Measurement, Lund, Sweden, 19–20 September.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Joseph, N. & Marnewick, C., 2014, ‘Structured equation modeling for determining
ICT project success factors’, paper presented at the 2014 PMI Research and
Education Conference, Portland, OR, 27–29 July.
Killen, C.P. & Kjaer, C., 2012, ‘Understanding project interdependencies: The
role of visual representation, culture and process’, International Journal of
Project Management 30(5), 554–566. https://doi.org/10.1016/j.ijproman.2012.
01.018
Kim, J. & Wilemon, D., 2003, ‘Sources and assessment of complexity in NPD
projects’, R&D Management 33(1), 15–30. https://doi.org/10.1111/14679310.00278
Kim, J. & Wilemon, D., 2009, ‘An empirical investigation of complexity and its
management in new product development’, Technology Analysis & Strategic
Management 21(4), 547–564. https://doi.org/10.1080/09537320902819296
Lu, Y., Luo, L., Wang, H., Le, Y. & Shi, Q., 2015, ‘Measurement model of project
complexity for large-scale projects from task and organization perspective’,
International Journal of Project Management 33(3), 610–622. https://doi.
org/10.1016/j.ijproman.2014.12.005
149
References
Marnewick, A., 2013, ‘A socio-technical view of the requirements engineering
process’, DIng thesis, University of Johannesburg, Johannesburg.
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Martens, M.L. & Carvalho, M.M., 2017, ‘Key factors of sustainability in project
management context: A survey exploring the project managers’ perspective’,
International Journal of Project Management 35(6), 1084–1102. https://doi.
org/10.1016/j.ijproman.2016.04.004
Maylor, H., Vidgen, R. & Carver, S., 2008, ‘Managerial complexity in project-based
operations: A grounded model and its implications for practice’, Project
Management Journal 39(Suppl 1), S15–S26. https://doi.org/10.1002/pmj.20057
Milis, K. & Mercken, R., 2002, ‘Success factors regarding the implementation of
ICT investment projects’, International Journal of Production Economics 80(1),
105–117. https://doi.org/10.1016/S0925-5273(02)00246-3
Muller, R., Geraldi, J.G. & Turner, J.R., 2012, ‘Relationships between leadership
and success in different types of project complexities’, IEEE Transactions on
Engineering Management 59(1), 77–90.
Nguyen, A.T., Nguyen, L.D., Le-Hoai, L. & Dang, C.N., 2015, ‘Quantifying the
complexity of transportation projects using the fuzzy analytic hierarchy
process’, International Journal of Project Management 33(6), 1364–1376.
https://doi.org/10.1016/j.ijproman.2015.02.007
Padalkar, M. & Gopinath, S., 2016, ‘Are complexity and uncertainty distinct
concepts in project management? A taxonomical examination from literature’,
International Journal of Project Management 34(4), 688–700. https://doi.
org/10.1016/j.ijproman.2016.02.009
Pade, C., Mallinson, B. & Sewry, D., 2008, ‘An elaboration of critical success
factors for rural ICT project sustainability in developing countries: Exploring
the DWESA case’, Journal of Information Technology Case and Application
Research 10(4), 32–55. https://doi.org/10.1080/15228053.2008.10856146
Pinto, J.K. & Slevin, D.P., 1987, ‘Critical factors in successful project implementation’,
IEEE Transactions on Engineering Management EM-34(1), 22–27. https://doi.
org/10.1109/tem.1987.6498856
Project Management Institute, 2013, A guide to the project management body of
knowledge: PMBOK® Guide, 5th edn., Project Management Institute, Newtown
Square, PA.
Remington, K. & Pollack, J., 2007, Tools for complex projects, Gower, Farnham,
England.
Schön, E.-M., Thomaschewski, J. & Escalona, M.J., 2017, ‘Agile requirements
engineering: A systematic literature review’, Computer Standards & Interfaces
49, 79–91. https://doi.org/10.1016/j.csi.2016.08.011
Schwalbe, K., 2013, Information technology project management, Cengage
Learning, Stamford, CT.
Senescu, R.R., Aranda-Mena, G. & Haymaker, J.R., 2013, ‘Relationships between
project complexity and communication’, Journal of Management in Engineering
29(2), 183–197. https://doi.org/10.1061/(ASCE)ME.1943-5479.0000121
150
References
Shenhar, A.J., Holzmann, V., Melamed, B. & Zhao, Y., 2016, ‘The challenge of
innovation in highly complex projects: What can we learn from Boeing’s
dreamliner experience?’, Project Management Journal 47(2), 62–78. https://
doi.org/10.1002/pmj.21579
Shenhar, A.J., Levy, O. & Dvir, D., 1997, ‘Mapping the dimensions of project success’,
Project Management Journal 28(2), 5–13.
Sohi, A.J., Hertogh, M., Bosch-Rekveldt, M. & Blom, R., 2016, ‘Does Lean & Agile
project management help coping with project complexity?’, Procedia – Social and
Behavioral Sciences 226, 252–259. https://doi.org/10.1016/j.sbspro.2016.06.186
Tatikonda, M.V. & Rosenthal, S.R., 2000, Technology novelty, project complexity,
and product development project execution success: A deeper look at
task uncertainty in product innovation’, IEEE Transactions on Engineering
Management 47(1), 74–87. https://doi.org/10.1109/17.820727
Thamhain, H., 2013, ‘Managing risks in complex projects’, Project Management
Journal 44(2), 20–35. https://doi.org/10.1002/pmj.21325
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. https://doi.org/10.1016/j.
ijproman.2008.01.001
Thomé, A.M.T., Scavarda, L.F., Scavarda, A. & Thomé, F.E.S.S., 2016, ‘Similarities
and contrasts of complexity, uncertainty, risks, and resilience in supply chains
and temporary multi-organization projects’, International Journal of Project
Management 34(7), 1328–1346. https://doi.org/10.1016/j.ijproman.2015.10.012
Vidal, L.A., Marle, F. & Bocquet, J.C., 2007, ‘Modelling project complexity’, Paper
presented at the Proceedings of the International Conference on Engineering
Design, Paris, 28–31 August 2007.
Vidal, L.A. & Marle, F., 2008, ‘Understanding project complexity: Implications
on project management’, Kybernetes 37(8), 1094–1110. https://doi.
org/10.1108/03684920810884928
Vidal, L.A., Marle, F. & Bocquet, J.-C., 2011, ‘Using a Delphi process and the
Analytic Hierarchy Process (AHP) to evaluate the complexity of projects’,
Expert Systems with Applications 38(5), 5388–5405. https://doi.org/10.1016/j.
eswa.2010.10.016
Whitney, K.M. & Daniels, C.B., 2013, ‘The root cause of failure in complex IT
projects: complexity itself’, Procedia Computer Science 20, 325–330. https://
doi.org/10.1016/j.procs.2013.09.280
Whyte, J., Stasis, A. & Lindkvist, C., 2016, ‘Managing change in the delivery of
complex projects: Configuration management, asset information and “big
data”’, International Journal of Project Management 34(2), 339–351. https://
doi.org/10.1016/j.ijproman.2015.02.006
Williams, T.M., 1999, ‘The need for new paradigms for complex projects’,
International Journal of Project Management 17(5), 269–273. https://doi.
org/10.1016/S0263-7863(98)00047-7
Xia, W. & Lee, G., 2004, ‘Grasping the complexity of IS development projects’,
Communications of the ACM 47(5), 68–74. https://doi.org/10.1145/986213.986215
151
References
Chapter 4
Aguilera, I., 2016, Delivering value: Focus on benefits during project execution,
Newtown, PA, viewed 09 March 2017, fromhttp://www.pmi.org/-/media/pmi/
documents/public/pdf/learning/thought-leadership/pulse/benefits-focusduring-project-execution.pdf
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 04–07 January.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences, Hawaii, 04–07th January.
Bennington, P. & Baccarini, D., 2004, ‘Project benefits management in IT projects –
An Australian perspective’, Project Management Journal 35(2), 20–31.
Marnewick, C. (ed.), 2013, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C., 2016, ‘Benefits of information system projects: The tale of two
countries’, International Journal of Project Management 34(4), 748–760.
https://doi.org/10.1016/j.ijproman.2015.03.016
Marnewick, C. & Labuschagne, L., 2012, ‘Factors that influence the outcome of
ICT projects’, Paper presented at the PMSA Conference 2012, Johannesburg,
17–19 September.
Project Management Institute, 2013, A guide to the project management body of
knowledge (PMBOK Guide), 5th edn., Project Management Institute, Newtown
Square, PA.
Schiesser, R., 2010, IT systems management, 2nd edn., RR Donnelley, Crawfordsville,
IN.
Chapter 5
Beck, K., Beedle, M., Bennekum, A.V., Cockburn, A., Cunningham, W., Fowler, M. et
al., 2001, Manifesto for Agile software development, viewed 20 April 2017, from
http://www.agilemanifesto.org/.
Fernandez, D.M., Wagner, S., Kalinowski, M., Schekelmann, A., Tuzcu, A., Conte,
T. et al., 2015, ‘Naming the pain in requirements engineering: Comparing
practices in Brazil and Germany’, IEEE Software 32(5), 16–23. https://doi.
org/10.1109/MS.2015.122
Joseph, N., & Marnewick, C., 2014, ‘Structured equation modeling for determining
ICT project success factors’, Paper presented at the 2014 PMI Research and
Education Conference, Portland, OR, 27–29 July.
Joseph, N. & Marnewick, C., (2017), ‘Investing in project management certification:
Do organisations get their money’s worth?’, Information Technology and
Management 1–24. https://doi.org/10.1007/s10799-017-0275-y
152
References
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Tamai, T. & Kamata, M.I., 2009, ‘Impact of requirements quality on project success
or failure’, in K. Lyytinen, P. Loucopoulos, J. Mylopoulos & B. Robinson (eds.),
Design requirements engineering: A ten-year perspective, vol. 14, pp. 258–275,
Springer, Berlin.
Todorović, M.L., Petrović, D.Č., Mihić, M.M., Obradović, V.L. & Bushuyev, S.D., 2015,
‘Project success analysis framework: A knowledge-based approach in project
management’, International Journal of Project Management 33(4), 772–783.
https://doi.org/10.1016/j.ijproman.2014.10.009
Williams, T., 2016, ‘Identifying success factors in construction projects: A case
study’, Project Management Journal 47(1), 97–112. https://doi.org/10.1002/
pmj.21558
Chapter 6
Anglim, J., 2007, Structural equation modelling, vol. 2013, Cambridge Scholars
Publishing, Newcastle upon Tyne.
Badewi, A., 2016, ‘The impact of project management (PM) and benefits
management (BM) practices on project success: Towards developing a project
benefits governance framework’, International Journal of Project Management
34(4), 761–778. https://doi.org/10.1016/j.ijproman.2015.05.005
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
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. https://doi.
org/10.1016/j.jss.2007.08.020
Doloi, H., Iyer, K.C. & Sawhney, A., 2011, ‘Structural equation model for assessing
impacts of contractor’s performance on project success’, International
Journal of Project Management 29(6), 687–695. https://doi.org/10.1016/j.
ijproman.2010.05.007
Ferguson, E. & Cox, T., 1993, ‘Exploratory factor analysis: A users’ guide’,
International Journal of Selection and Assessment 1(2), 84–94. https://doi.
org/10.1111/j.1468-2389.1993.tb00092.x
Field, A., 2013, Discovering statistics using IBM SPSS statistics, 4th edn., Sage,
London.
Field, A.P., 2009, Discovering statistics using SPSS: (And sex and drugs and rock
‘n’ roll), Sage, London.
Gaskin, J., 2013, SEM Series Part 5a: Confirmatory Factor Analysis, vol. 2013,
viewed 5 August 2013, from http://www.youtube.com/watch?v=MCYmyzRZn
IY&list=PLnMJlbz3sefLdYnz7TysHKrMBby7igpV9&index=6
153
References
Gaskin, J., 2016, SEM Series (2016) 3. Exploratory Factor Analysis (EFA), vol.
2017, viewed 16 January 2017, from https://www.youtube.com/watch?v=
VBsuEBsO3U8
Hair, J.F., Black, W.C., Babin, B.J., Anderson, R.E. & Tatham, R.L., 2006, M
ultivariate
data analysis, 6th edn., Prentice-Hall International, Upper Saddle River, NJ.
Hoyle, R.H., 2011, Structural equation modeling for social and personality
psychology, Sage, Thousand Oaks, CA.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Kaiser, H., 1974, ‘An index of factorial simplicity’, Psychometrika 39(1), 31–36.
https://doi.org/10.1007/bf02291575
Kim, D.Y., Han, S.H., Kim, H. & Park, H., 2009, ‘Structuring the prediction model
of project performance for international construction projects: A comparative
analysis’, Expert Systems with Applications 36(2 pt 1), 1961–1971. https://doi.
org/10.1016/j.eswa.2007.12.048
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology project
m anagers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2016.itpmc07
Marsh, H.W. & Hocevar, D., 1985, ‘Application of confirmatory factor analysis to
the study of self-concept: First- and higher order factor models and their invariance across groups’, Psychological Bulletin 97(3), 562–582. https://doi.
org/10.1037/0033-2909.97.3.562
Marsh, H.W., Hau, K.-T. & Wen, Z., 2004, ‘In search of golden rules: Comment on
hypothesis-testing approaches to setting cutoff values for fit indexes and
dangers in overgeneralizing Hu and Bentler’s (1999) findings’, Structural
Equation Modeling: A Multidisciplinary Journal 11(3), 320–341. https://doi.
org/10.1207/s15328007sem1103_2
McKinney, V., Yoon, K. & Zahedi, F.M., 2002, ‘The measurement of web-customer
satisfaction: An expectation and disconfirmation approach’, Information
Systems Research 13(3), 296–315. https://doi.org/10.1287/isre.13.3.296.76
McQuitty, S. & Wolf, M., 2013, ‘Structural equation modeling: A practical introduction’,
Journal of African Business 14(1), 58–69. https://doi.org/10.1080/15228916.2013.
765325
Nunkoo, R. & Ramkissoon, H., 2012, ‘Structural equation modelling and regression
analysis in tourism research’, Current Issues in Tourism 15(8), 777–802. https://
doi.org/10.1080/13683500.2011.641947
Reio, T.G. & Shuck, B., 2015, ‘Exploratory factor analysis’, Advances in Developing
Human Resources 17(1), 12–25. https://doi.org/10.1177/1523422314559804
Reisinger, Y. & Mavondo, F., 2007, ‘Structural equation modeling’, Journal of Travel &
Tourism Marketing 21(4), 41–71. https://doi.org/10.1300/J073v21n04_05
Roh, T.H., Ahn, C.K. & Han, I., 2005, ‘The priority factor model for customer
relationship management system success’, Expert Systems with Applications
28(4), 641–654. https://doi.org/10.1016/j.eswa.2004.12.021
154
References
Stahl, D., 2008, Introduction to path analysis and structural equation modelling
with AMOS, Vol. 2013, viewed 13 August 2013, from http://www.kcl.ac.uk/iop/
depts/biostatistics/teaching/previouslecturenotes/amos/amosweek3.pdf
Tabachnick, B.G. & Fidell, L.S., 1996, Using multivariate statistics, HarperCollins
College Publishers, New York.
Ullman, J.B., 1996, ‘Structural equation modeling’, in B.G. Tabachnick & L.S. Fidell
(eds.), Using multivariate statistics, pp. 709–810, Harper Collins, New York.
Yatim, B., 2008, Statistical modelling (Special Topic: SEM), vol. 2013, viewed 28
August 2013, from http://staf.uum.edu.my/byatim/nota/Multivariate/Powerpoints/Statistical%20Modelling2
Chapter 7
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Snowden, D.J. & Boone, M.E., 2007, ‘A leader’s framework for decision making’,
Harvard Business Review 85(11), 68–76.
155
Index
A
ability 28, 104
accept 29–30, 72
acceptance 30, 54, 70, 73, 105, 122,
126, 141
access 46
accurate 28, 59, 72
achieve 20, 32, 36, 44, 52–54, 108, 116
achieved 15, 21–23, 29, 31–32, 73, 104,
107, 127
acquisition 132
action 21, 31, 123
administration 5
Africa 2–3, 6–7, 9, 144
African 2, 7–8, 18–19, 80, 97, 144
African Context 97
Agile 12–14, 16–17, 44, 62, 64–68,
70–80, 83–84, 86–87, 89–92,
94–95, 97–99, 104–105, 111,
114–119, 122–124, 126, 130–132,
134–136, 138, 144
agreement 47
analyse 16, 37, 41, 66, 84, 93,
97, 99
application 1, 5, 36, 44
approach 12–16, 20, 34–35, 37, 44,
80, 87, 104, 111, 115, 126, 132,
135–136, 140
attributes 45, 53, 102
auspices 31
authority 88
autonomy 14
average 6–7, 66, 68, 71–72,
75–77, 79, 119
awareness 47, 55, 97, 129, 142
B
barriers 48
baseline 27
behaviour 31, 116
156
benefits 3–4, 6, 23, 27, 29–31, 46–47,
53, 58, 73–75, 80, 104–105, 107,
129, 132, 138, 141, 144
benefits realisation 27, 29–31, 74,
105, 141
bias 15
bodies 20, 25, 47
boundaries 48
bracket 119
breakdown 45, 66
budget 25, 27, 57, 70, 95, 104
business 3–5, 16, 22–26, 29–30, 36,
38, 40–41, 45, 49, 51, 53, 56,
58–59, 71, 73–75, 77, 88–89,
101–102, 104–105, 107, 111, 132,
138, 141, 144
business case 23, 73
business plan 75, 105, 141
business success 24, 73–75, 77,
104–105, 107, 111, 141
C
calculated 71
capabilities 21
care 7
certification 28
certified 28
challenge 4, 33, 88
challenges 28, 34–36, 38, 88,
92, 98, 103
change 9, 11–13, 27, 29–31, 35, 38,
40–41, 44, 59–60, 78, 86,
90–93, 97–99, 103–104, 128–129,
131–134, 139–140, 143
change control 27
change management 29, 59–60, 90,
92, 103–104, 128–129, 131–134,
140, 143
change process 59–60, 91–93, 128,
134, 143
Index
channels 35, 51
characteristics 85, 90, 103
claim 136
clarity 53, 58, 111, 118, 128, 131–132,
134, 143
classified 18
Cobb’s paradox 19
cognisance 10, 41, 110
collaboration 36, 38, 40, 44–45,
49, 51, 58, 82
communication 2, 13, 28–29,
36, 38, 40, 44–45, 49–51,
58–59, 88, 142
comparative 110, 114, 118
competency 36, 59, 93–95, 128,
131–134, 140, 143
competition 23, 57, 89, 102,
120–121, 124, 143
complete 14, 53, 59, 87, 114, 135
complex 10–12, 16, 38–39, 42, 47,
52, 55, 58, 60, 83–85, 88–95,
97–99, 119, 137–140
complexities 34–36, 38, 41, 46, 53,
82, 87, 92, 96–97, 99, 102, 119,
126, 128, 132–134, 136
complexity 1, 5, 7, 14–18, 21, 33–62,
81–104, 106, 108, 110, 112, 114,
116, 118–128, 130–134, 136–137,
139–140, 142–143
complexity model 34, 37, 39, 41,
116, 140
compromise 51
computer science 5, 151
concept 9, 14, 21, 33–34, 41–42,
57, 79, 100–101, 104, 145
conceptual model 34, 148
concern 6, 10, 22–23, 28, 47, 58,
72–73, 103, 116
conflict 48, 53
constraints 22, 38, 68, 93–94, 103
construct 14, 16–17, 33, 60–61,
81–82, 84, 88, 90, 93–100,
103, 116, 118–119, 126, 136, 139,
141–143
construction 34, 47
Content 41–43, 56, 121–123, 143
content analysis 41–43
context 29, 34, 42, 57, 66, 70, 82, 97,
101, 126
contract 47, 142
contractor 40, 49, 142, 153
contracts 47
contractual 47
contrast 66, 78, 87, 151
contributes 1, 32, 38, 42, 56, 73, 86
control 2, 23, 27, 39
conversion 11
cooperation 48, 51, 59, 142
cost 4, 16, 22, 34, 39, 45, 53, 57–58,
68, 70, 77–78, 85, 91, 93–95,
103, 128–129, 131, 134, 143
course 28–29, 115
create 3, 6, 10, 26, 39, 46, 73, 101,
137–138
creating 49, 138
Creation 5, 31
creep 57
criteria 22, 33, 70–74, 104,
122, 124, 126
Cronbach alpha 107, 111, 115,
122, 124
cross 40, 47, 64, 100
cultural 36, 48
culture 28, 30, 48
customers 1, 20, 22, 29–30, 72
customisation 11–12, 64–65
cycle 13, 66, 136
D
daily 1, 51, 55
data 2, 6, 11, 35, 100–101, 104, 107,
110–111, 115, 135
dataset 118, 135
deal 19, 27, 39, 43, 56, 103, 140
death 21
decision 15, 17, 20, 35, 37, 41
deficiencies 30, 131–132
defined 13–14, 21, 32, 36, 60, 70, 85,
87, 98, 100
degrees 110, 114, 118
deliverable 1, 20, 22–25, 28–30, 32,
66, 70–73, 75, 77, 101–102,
104–105, 107–113, 115–117, 135,
138–141
157
Index
deliverable success 24, 72–73, 77,
101–102, 104–105, 107–108,
110–112, 115–116, 135, 140–141
deliverables 1, 16, 76, 83
delivery 10, 19–20, 23, 31, 53, 65, 70,
83, 94, 99, 114, 129, 131, 134
dependencies 38, 50–52, 82–84,
96–97, 142
derailing 134
design 6, 12–13, 30, 91, 94
developing 35
development 13–14, 34–35, 39, 41, 45,
64–65, 81, 83, 86–87, 94, 98,
104, 116, 128, 132, 136
DevOps 64–65
dialogue 145
differentiation 43–44, 52, 103, 142–143
dilemma 96
discipline 1, 5, 23, 47, 68, 79, 142
disconfirmation 154
diversity 52, 86, 103, 131, 143
division 3, 9
drive 46, 52, 83, 102, 142, 144
duration 11, 37, 44, 47, 82–83, 102, 142
dynamic 35, 40–41, 45, 52, 92
dynamics 16, 36, 42–43, 54, 59–60,
81, 90–92, 97–98, 101–103,
126–134, 143
E
Economic Growth 56
education 35–36, 144
effectively 29, 35, 37, 40, 44, 48, 52,
60, 90–92, 107, 120
element 39–40, 43–44, 46, 48–59,
101–102, 142–143
elements 16–17, 37–40, 42–44, 52,
57–58, 60, 100, 102–103
embrace 5, 64, 102, 131–132
emerge 14
employed 37, 81, 93, 95, 97, 110, 114,
118, 128
employees 36
enablers 19, 27, 30–32
enterprise 2, 6, 12, 40, 49
environment 38, 40–41, 47, 50, 52,
54, 56, 62, 76, 81, 83, 87–89, 94,
158
96–97, 99, 102, 121, 124–125, 136,
142–143
environmental 16, 35, 42–43, 50, 54,
56–57, 60, 81, 87–90, 96–98,
101–103, 119–126, 139, 142–143
environmental complexity 16,
35, 42–43, 54, 56–57, 60,
81, 87–90, 96–98, 101–102,
119–125, 139
envisaged 31
evidence 6, 70
exclusion 131
executives 88, 140
exhibit 15, 60
expenditure 45–47, 82, 102, 142
experience 46, 48–49, 54, 56, 82,
88, 93, 95–96, 102–103, 121–123,
125–129, 131–132, 134, 140,
142–143
exploit 56
exploration 101
exploratory factor analysis (EFA) 118
exploratory model 116, 118–121,
123–125, 128, 131, 134
F
factor 14, 56, 66, 83, 105–107, 111–112,
115–116, 118–135
factor loading 105–106, 115, 119–120,
122, 124, 126, 130, 132
factor plot 120–123, 125, 127
factors 14, 33, 35, 38–39, 105, 107–108,
111–112, 115–116, 120, 123, 126–127,
131–132, 135–136
failure 22, 25–26, 29, 31–32, 50, 53,
56, 58, 76, 104–105, 119
feature 16, 42–46, 48–53, 55–61, 70,
81–100, 102–103, 116, 118, 120,
122–123, 126, 128–129, 132–134,
139, 141–143
feedback 13, 28, 39, 50–51, 86, 91, 98,
142
first 5, 12, 15, 21, 40–43, 48, 52, 55–57,
59, 62, 65, 85–86, 90–91, 98,
126, 137, 140
flexible 86–87, 89, 94, 131
formation 101
Index
framework 4–5, 9, 14, 16, 20–21, 37,
137–138, 140, 144
Freedom 110, 114, 118
G
generation 36
global 19, 102
goal 31, 36, 40, 44, 46, 51–53,
55, 58, 74, 102–103, 111,
114, 120, 128–129, 131–132, 134,
140, 143
goals 20, 23, 37–39, 45–46, 51–53,
58–59, 75, 83, 90, 92, 96, 101,
103, 105, 111, 114–116, 127–129,
131–135, 141, 143
governance 3, 9–10, 26, 74–75, 111, 116,
135, 141, 144
government 2
grouping 27, 111, 120, 122, 124, 100
growth 2, 4, 35, 56
H
hard 49
hardware 1, 4, 10, 34
health 47, 96–97, 142
high 26, 37–38, 41, 60, 75, 91, 98
Holistic 94–95
hope 75
I
identification 42
impact 4–5, 16, 23, 27, 30–32, 37–38,
49, 54, 56, 60, 74–77, 80, 82,
88–89, 91–92, 98, 106–108,
111–112, 128–129, 133, 135, 139–141,
143–144
implementation 10–13, 21, 29, 35, 40,
45, 47, 60, 64–66, 68, 82, 98,
128–129
importance 35, 37, 45–46, 52–53,
82–84, 86–87, 89, 93–94, 98,
119, 125, 128
inclusion 40, 44, 98, 129, 134
incorrect 59
individual 21, 26, 29–30, 32, 39, 45,
59, 97, 99, 103, 124
influence 16, 32, 34, 37–38, 40–41,
44–45, 47, 51, 54–56, 58–60,
85, 88–90, 102, 104, 116, 120,
123–125, 133, 138, 143
information 1–3, 5–9, 11, 15, 17–19,
28, 30, 33–36, 38–40, 42, 44,
46, 48, 50–52, 54, 56, 58–60,
62, 64, 66, 68, 70, 72, 74, 76,
78–84, 86, 88, 90, 92–96, 98,
100–101, 103–104, 128, 131,
134–135, 137–138, 142–143
information technology 1–3, 5, 8–9,
30, 39, 78–79
infrastructure 5–6, 10–12, 41, 64–65
inhibitors 27–32
Innovation 36–37, 39
input 97, 103
inputs 25, 52–53, 86, 94, 131, 138, 143
intangible 4, 46, 129
integrate 13, 34, 54, 64
integrating 34
integration vii, 2, 5, 11–12, 23, 34–35,
38, 40, 46–47, 54, 64–66, 68
interaction 5, 28, 35, 47, 51, 88
interconnected 52–53
interdependencies 37, 45, 49–51,
53, 102, 142
interfaces 47, 142
interpretation 32
interrelationships 112, 135
interviews 70
intra-organisational complexity 36
investigation 15, 42, 81, 105, 136, 144
investment 1–5, 18, 20, 22, 75, 138
K
Kaiser-meyer-olkin (KMO) 119
knowledge 19, 27, 36, 40, 45, 49, 59,
94, 140
L
lack 18, 24, 39, 45, 50, 55, 90, 98
language 5, 41, 48, 96–98, 142
language 48, 97
languages 5, 41, 48, 96–98, 142
large 1, 10, 21, 38, 45, 52, 75–76,
88–89, 91
159
Index
latent constructs 118
leaders 2, 4, 6, 10, 16–18, 20, 25, 28,
73, 138–139
leadership 144
leads 52–53, 58, 131
lean 64–65, 144
legislation 11, 55
life 13, 66, 136–137
locations 45–46, 56, 142
lose 25
lot 2, 11
M
maintenance 2, 4, 9
management 1, 6, 14, 16, 18–21, 23–29,
31–39, 42, 44–46, 48–52, 54–55,
57, 59–60, 70, 79, 82, 85, 88–
90, 92–94, 96, 98–99, 101–104,
110, 120–121, 123–126, 128–129,
131–135, 138–140, 143–144
management processes 103
manifest 125
maturity 58, 94, 128, 131, 133, 143–144
media 152
medium 37, 107, 116, 135
meeting 70, 88
member 25, 27, 31, 40, 48, 52, 58,
97, 128
method 12–15, 37, 44–45, 58, 64–66,
68, 70, 73–76, 78–79, 81,
83–84, 86, 89, 91–92, 95–96, 98,
102–103, 106, 111–112, 114–115, 126,
128, 131–132, 134–135, 138, 142–143
methodologies 13–14, 18, 20, 31, 62,
64, 70, 72, 97, 104
methodology 13–15, 18, 20, 28, 31, 62,
64, 70, 72, 93, 95, 97, 104, 125,
128, 136
methodology 15, 28, 93, 95,
125, 128, 136
miscommunication 29
mission 37
mistakes 25
mode 114
model 12–13, 15–16, 34, 36–37, 39, 41,
66, 101, 104–107, 109–125, 128,
131, 134–136, 139–140
160
model fit measures 114
monetary 7
money 1–2, 8, 35, 45
N
nation 56
nationalities 48, 97–98, 142
need 3, 8, 11, 15, 20, 24–29, 32, 39, 46,
48, 102, 104, 108, 116, 139–140
needs 10–11, 26, 28–29, 35, 40, 54, 61,
75, 90, 104, 119, 137
negative 4, 57, 59, 88, 91
network 11
networks 50, 142
newness 34–36, 85–87, 96–99, 128,
131, 134, 143
novelty 36, 58, 128, 131, 133, 143
number 10–11, 38–39, 44–45, 51–53,
55, 60, 82, 85, 87–92, 97–98,
111, 119, 121, 124–125, 128–129,
131–132, 134, 136–137, 142–143
O
objectives 2, 21, 25–26, 58, 73, 105, 111,
114–116, 128, 133–135, 143–144
observed variable 100
office 4, 11, 24, 46, 48–49, 142
only 1, 10, 15, 19, 23, 26, 29–31, 36, 39,
42, 49, 64, 68, 71–72, 85–86,
90, 96, 111, 114, 116, 120, 130, 132,
134, 139
open 86, 139
operates 35, 50, 87
operational 5, 10, 24, 30, 44, 50, 55
operational level 24
operations 20, 29, 57, 82
opportunities 4
order 11, 19–20, 25–26, 28–30, 32, 86,
99, 111, 135
organisational benefit 22, 24, 27, 29,
47, 101–102
organisational complexity 16, 35–36,
39–40, 42–44, 46, 48–50,
52–53, 56, 60–61, 81–85, 96–99,
101–102, 118–119, 139–140
organisational culture 28, 30
organisational goals 90
Index
organisational leaders 2, 4, 6, 10,
16–18, 20, 25, 28, 73, 138–139
orientation 96, 101, 103
oriented 31
other 5, 11–12, 14, 35–37, 39–40,
43–47, 49–50, 52–54, 57–60,
64–65, 70, 78, 88, 96, 99,
105–106, 111, 119, 121, 132, 134
outcome 16, 19, 21, 23–27, 36, 60, 108,
112, 116, 135, 138
outcome influencers 27
overwhelming 85, 91, 132
ownership 137
P
pace 35–37
paid 44–45
paradigm 19, 49
paradox 19
parties 44, 46–50, 56, 58, 82, 102,
120, 129, 142
pattern 31, 40, 91, 106, 112, 115, 127,
130, 133
Pattern Matrix 106, 112, 115, 127,
130, 133
perspective 2–3, 7, 13, 21, 24–25, 29,
31–32, 40, 44, 55, 86–90, 94,
98, 101, 118–119, 121, 125, 143
phenomenon 41
philosophy 44, 131, 135
physical 45, 126
pivotal 83, 128
place 12, 21, 28, 31, 40, 44, 52, 58–59,
83, 99, 103, 126, 129, 134
policy iv, 35, 123, 129
political 37–38, 55–56, 88, 90, 120,
124–125, 143
political influence 55–56, 88, 90, 120,
124–125, 143
politics 55, 88, 90
poor 16, 30, 34, 57, 60, 83, 91, 94
population 15
portfolio management 21, 23–25, 31
position 23, 83, 89–90, 92, 94–95,
97–99
positive 55, 75, 78, 80, 91, 96, 129, 138
powerful 39
practice 12, 27–28, 90, 103–104, 116,
121, 126, 129, 131–132, 135, 144
prerequisites 128
pressure 28, 56–57, 88–90, 102,
120–121, 124, 143
prevent 19, 31
primary 15, 42, 56
proactive 129
probability 15, 31
problem 14–15, 54, 104, 139
process 4–6, 12–14, 16, 20, 22,
24–27, 29, 35, 37–38, 40–41,
51–52, 59–60, 65–68, 77–78, 89,
91–93, 101–104, 107–119, 126, 128,
131–132, 134–135, 138–143
process success 24–25, 66–67, 77–78,
104, 107–108, 110–112, 114–116,
135, 140–141
processes 4, 6, 13–14, 16, 20, 25–27,
35, 37–38, 40–41, 51–52, 60,
65–66, 68, 103–104, 107–108,
114, 135
produce 6, 22, 26, 37, 66, 94, 131
product success 22, 27–30, 32,
70, 72, 105, 135
professional 7, 18–19, 111
programme 3, 9, 21, 23–25, 29
programme management 23–24
progress 18, 83, 132
project 1, 3, 5–34, 36–60, 62, 64–66,
68, 70–118, 120–155
project complexity 1, 18, 33–34,
36–39, 41–47, 50–55, 57, 59–60,
62, 81–82, 84, 86–88, 90, 92–
101, 116, 118, 120, 126, 136–137,
139–140, 142–143
project duration 44, 47, 82–83,
102, 142
project management 1, 6, 16, 18–21,
23–29, 31–34, 36–37, 42, 44,
46, 51–52, 54, 57, 70, 89, 93,
96, 101–104, 110, 126, 134–135,
139–140, 144
project management success 16, 21,
24–25, 27, 32, 102–104, 110, 126,
135, 139
project method 44, 58
161
Index
project success 1, 6–8, 10, 14–28, 30,
32–33, 44, 62, 64–66, 68, 70,
72, 74–81, 90, 100–104, 106–118,
120, 122, 124, 126, 128, 130, 132,
134–141, 144
project success models 104, 116
project team 25, 28, 36–37, 39,
45–46, 48–49, 51, 54–55, 57–58,
72, 83, 96, 102, 128, 142
promax 106, 112, 115
promise 18
purpose v, 12, 14–15, 44, 107, 110–111
Q
questionnaire 15–16, 104, 116
quite 76
R
ranked 82–99, 123
ranking 82–99
rationale 1, 15, 72
reason 6, 15, 28, 31, 60, 76, 98, 128
relations 29, 48
relationship 15, 17, 35–36, 38, 51, 55,
107–108, 112, 116, 138–139
replacement 12
representation 44
requirements 12–14, 28–29, 35, 37–38,
49, 53, 57, 70–73, 85–88, 94,
105, 116, 128–129, 131, 141,
143–144
research 2, 6, 15, 19–20, 25, 27, 33–35,
41, 59, 68, 104–105, 119, 129, 144
residual 110, 114, 118
resource 12, 20, 26, 32, 35, 39, 46–47,
50–51, 56, 84, 96, 102, 132, 142
resources 20, 26, 32, 35, 39, 46–47,
50–51, 56, 84, 96, 102, 132, 142
respect 135
responsibilities 48
responsibility 5, 48, 50, 137–138
responsible 5, 19, 25, 31, 44
result 22–23, 29, 33, 38, 71, 105, 108,
111, 116, 119, 134, 138
results 4, 6–8, 10, 15–18, 30, 64, 66,
68, 71–76, 78, 80, 88, 105, 108,
110–111, 114–116, 118–119, 122,
162
124, 126–127, 129, 134, 136,
138–139, 144
reveal 119, 127
rigid 98, 111, 125
risk 27–28, 35, 37–38, 49, 54, 57,
85–87, 96–98, 102–103, 121,
124–126, 128–129, 131, 134,
142–143
risk management 27, 85
risks 28, 38, 54, 57, 85–87, 96–98,
102–103, 121, 124–126, 128–129,
131, 134, 142–143, 151
robust 46, 60, 103–104, 129
role 29, 31, 35, 38, 42, 48, 52–53,
55–56, 84, 102, 126, 128–129,
135, 139
root 110, 114, 118
S
safety 47, 96–97, 142
sample 15
scale 16, 21, 32, 37–38, 45, 52–53,
85–87, 96, 98, 105, 128–129, 131,
133–134, 143–144, 149
schedule 11, 27, 50, 57, 82–84, 96–97,
104, 142
science 5, 144
scope 22, 25, 27, 37, 53, 57, 60, 68,
70–71, 77–78, 85–88, 91–96,
98, 103–104, 126–129, 131–134,
140, 143
self 13–14
sending 11
senior 31, 39, 55, 88, 120
sense 3, 93, 111, 132
sequence 12, 15
service 28, 75, 79–80, 104
services 2–3, 18, 57
site 45, 56, 97, 102, 121–123, 125–126,
142–143
skills 14, 27, 35, 39, 46–47, 49, 51, 82,
84–86, 94, 96, 98, 102, 142
social 48–49, 102, 144
soft issues 19
sources 34, 42
South Africa 2–3, 6–7, 9, 144
space 4, 54, 121, 123, 125
Index
specifications 22, 28, 70–73, 85–87,
94, 105, 141
stability 53, 56–57, 88–89, 102, 121,
124–125, 143
staff 30, 39, 55
stage 12, 44
stages 59, 93
stakeholder perspective 87–90,
98, 143
stakeholders 8, 22, 24, 28, 37–38, 46,
48, 50–51, 53, 55, 58–59, 87–90,
96–97, 102–104, 121, 124–125,
129, 137–138, 143
standard 20, 46, 53–54, 59,
128–129, 131, 143
state 2, 140
statement 37
status 45, 50, 55, 102
stories 18
story 20
strategic alignment 9, 26,
31–32
strategic intent 21, 23, 31, 120
strategic level 24, 75, 138
strategic pressure 56–57, 88–90, 102,
120–121, 124, 143
strategic success 16, 22–27, 31–32, 73,
75–78, 101–102, 104, 106, 108,
110–111, 116, 135, 138–141
strategy 6, 9–10, 31–32, 36–39, 66
stress 37, 89, 148
structural equation modelling
(SEM) 107
structure 5, 11, 14, 24, 35, 37,
40–41, 43–45, 48, 58–59,
83–85, 102, 142
study 6, 14–15, 19, 68, 78, 105, 110,
118, 136, 139
subgroups 15
success 1, 5–8, 10, 13–33, 44, 62,
64–68, 70–81, 90, 93–94,
100–118, 120, 122, 124, 126,
128, 130, 132, 134–141, 144
success rates 5–8, 15, 17, 19, 68,
76, 78–80, 138
suffer 34, 54, 90
sustainable 47
symbiosis 1, 17–18, 33, 62, 81, 100–102,
104, 106, 108, 110, 112, 114, 116,
118, 120, 122, 124, 126, 128, 130,
132, 134, 136–137
system 1–2, 5–8, 11–12, 14, 18–19, 30–31,
33–34, 36, 38–40, 42, 44–46,
48, 50–52, 54, 56, 58, 60, 62,
64–66, 68, 70, 72, 74, 76, 78,
80–84, 86, 88, 90, 92, 94, 96,
98, 100–101, 104–105, 121, 128,
135–138, 142, 144
T
tactical level 24
tailor 140
tandem 51, 85
task 14, 20, 25, 34, 37, 40, 44–45,
47–50, 53–54, 58, 82–87, 96,
98–99, 103–104, 127–129, 131,
133–134, 142–143
team 14, 25, 27–28, 36–37, 39–40,
45–49, 51–52, 54–58, 72, 83,
95–97, 102, 128–129, 142, 144
technical complexity 16, 41–43, 52–54,
57–58, 60, 81, 84–87, 96–99,
101–103, 126–128, 130–134
technical processes 25–27, 65–66
techniques 20, 22, 36, 116
technological complexity 34, 52
technology 1–3, 5, 8–9, 14, 30, 34–37,
39–40, 52, 54, 58–59, 78–79,
85–87, 95–99, 103, 127–128,
131–132, 134, 140, 143
terms 14, 26, 41
time 1, 4–5, 11, 16, 19–20, 22–23, 25,
34–35, 37, 39–41, 44, 48–49,
52, 57–58, 60, 64, 66, 68, 70,
72, 77–78, 83–85, 87, 91–95,
99, 103, 128–129, 131, 134, 143
tool 21, 39, 44, 100, 103, 128
tools 20–22, 36–37, 41, 44, 142
total 2, 8–9, 22, 60–61, 81, 119,
122, 124, 126, 130, 132
track 32
traditionally 33, 39, 47, 55
trained 72
training 4, 21, 28, 30
163
Index
transfer 36
transform 26, 38
transformation 26, 30–31
translate 47, 49
translated 7
transparency 50
travel 46
trend 15
triple 20, 22, 27, 57, 68, 70, 80,
93–94, 103, 143
triple constraint 20, 22, 27, 57, 68,
70, 80, 93–94, 103, 143
trust 49, 59, 102, 142
truth 70
U
uncertainty 11–12, 16, 34, 37, 41–43,
57–60, 81, 93–95, 101, 103,
126–134, 140, 143
uncover 70
understanding 14, 34–35, 41, 45–50,
52, 54–55, 58, 62, 82, 84,
87–89, 94, 99, 118–119, 140
unintended benefits 74–75, 107, 141
unintended impacts 74–75, 111, 141
unknown 47, 107–109, 112–113, 117, 129
unpacks 16
unpredictable 35
upgrade 1–2, 4, 12, 64–65
V
valid 110–111, 115–116, 118
validate 119, 136
valuable 102, 116
164
value 2–8, 10, 20, 22, 28, 32, 89, 111,
116, 119, 127, 138, 140, 144
values 107, 119, 122, 124, 126
variable 100, 105–107, 111–112, 115–116,
120, 122, 124, 127, 130, 133,
141–143
variance 27, 119, 122, 124, 126,
130, 132
variations 12, 136
venture 38, 48, 142
view 15, 24, 27, 29, 41, 86, 89, 94–95,
97, 99, 101, 103, 111, 131–132,
139, 144
viewed 32, 55, 100, 135, 139, 144
views 41, 43, 55, 84, 86–87, 90, 92,
99, 101, 126
virtues 25
vision 53
visual 5
vital 44
vitally 135
W
Waterfall 12–14, 16–17, 62, 64–68,
70–79, 83–84, 86–87, 89–90,
92–93, 95, 98–99, 105, 111–116,
118–119, 124–126, 132–135, 138
weakness 35
win 25
wisdom 140
wise 140
working 11, 13–14, 48, 98
world 2–3, 100
written 18
information system
project complexity and
information system
project success
Head Office
AOSIS (Pty) Ltd
Postnet Suite #110
Private Bag X19
Durbanville 7551
South Africa
Tel: +27 21 975 2602
Fax: +27 21 975 4635
Email: info@aosis.co.za
Website: http://www.aosis.co.za
© Carl Marnewick, Wikus Erasmus & Nazeer Joseph 2017. Licensee: AOSIS (Pty) Ltd
The moral rights of the authors have been asserted.
First Edition published in 2017
Impression: 1
Listed in OAPEN (http://www.oapen.org), DOAB (http://www.doabooks.org/) and indexed
by Google Scholar.
Some rights reserved. This is an open access publication. Except where otherwise noted, this
work is distributed under the terms of a Creative Commons Attribution-NonCommercialShareAlike 4.0 International license (CC BY-NC-SA 4.0), a copy of which is available at https://
creativecommons.org/licenses/by-nc-sa/4.0/.
Enquiries outside the terms of the Creative Commons license should be sent to the Rights
Department, AOSIS, at the above address or to publishing@aosis.co.za
Published in South Africa by AOSIS (Pty) Ltd, 15 Oxford Street, Durbanville, Cape Town,
7550.
Book Title: The symbiosis between information system project complexity and information
system project success
ISBN: 978-1-928396-25-3 (pdf)
ISBN: 978-1-928396-26-0 (e-book)
DOI: https://doi.org/10.4102/aosis.2017.itpsc45
How to cite this work
Marnewick, C., Erasmus, W. & Joseph, N., 2017, The symbiosis between information system
project complexity and information system project success, AOSIS, Cape Town.
Printed and bound in South Africa
This cover photo was provided under the CC0 (https://creativecommons.org/choose/
zero), via Pixabay
The publisher accepts no responsibility for any statement made or opinion expressed in this
publication. Consequently, the publishers and copyright holder will not be liable for any loss or
damage sustained by any reader as a result of his or her action upon any statement or opinion in
this work. Links by third party websites are provided by AOSIS in good faith and for information
only. AOSIS disclaims any responsibility for the materials contained in any third party website
referenced in this work.
Every effort has been made to protect the interest of copyright holders. Should any
infringement have occurred inadvertently, the publisher apologises and undertakes to
amend the omission in the event of a reprint.
The symbiosis between
information system
project complexity and
information system
project success
Carl Marnewick
Wikus Erasmus
Nazeer Joseph
Social Sciences, Humanities, Education & Business
Management Domain Editorial Board at AOSIS
Chief Editor: Scholarly Books
Andries van Aarde, Post Retirement Professor in the Dean’s Office, Faculty of
Theology, University of Pretoria, South Africa
Board Members
Jan Botha, Professor in the Centre for Research on Evaluation, Science and
Technology (CREST), University of Stellenbosch, South Africa
Joan Hambidge, Deputy Dean at the Faculty of Humanities for the University of
Cape Town & Professor for the School of Languages and Literatures, South Africa
Sakari Häkkinen, Dean of the Diocese of Kuopio, Finland
Glenna Jackson, Associate Editor, Professor Chair, Department of Religion and
Philosophy, Otterbein University, Westerville, OH, United States
Gregory C. Jenkins, Dean-elect, St George’s College, Jerusalem, Israel
Reina-Marie Loader, Director and Filmmaker, CinémaHumain, Vienna, Austria
Babita Marthur-Helm, Senior Lecturer Organisational Transformation &
Development; Managing Diversity Gender Empowerment, University of
Stellenbosch Business School, Stellenbosch, South Africa
Christopher Mbazira, Professor of Law & Coordinator of the Public Interest Law
Clinic (PILAC), Makerere University, Kampala, Uganda
Piet Naudé, Professor Ethics related to politics, economics and business &
Director, University of Stellenbosch Business School, Stellenbosch, South Africa
Charles Neill, Professor Department of Business Administration, The British
University in Egypt, El Sherouk, Cairo Governorate, Egypt
Cornelia Pop, Full professor at the Department of Business, Faculty of Business,
Babes-Bolyai University, Cluj-Napoca, Romania
Michael Schratz, Professor, Institut für LehrerInnenbildung und Schulforschung,
Dekan der School of Education, Leopold-Franzens-Universität Innsbruck, Austria
Johann Tempelhoff, Professor, Research Niche for Cultural Dynamics of Water
(CuDyWat), School of Basic Sciences, Vaal Triangle Campus of North-West
University, Vanderbijlpark, South Africa
Anthony Turton, Professor Centre for Environmental Management & Director
TouchStone Resources, University of Free State, South Africa
Willie L. van der Merwe, Professor & Chair Philosophy of Religion, Apologetics
and Encyclopaedia of theology & Professor Extraordinary Stellenbosch University,
South Africa, Vrije Universiteit Amsterdam, Amsterdam, the Netherlands
Christi van der Westhuizen, Associate Professor, Department of Sociology,
Faculty of Humanities, University of Pretoria, South Africa
Joke van Saane, Professor, Amsterdam Center for the Study of Lived Religion,
Vrije Universiteit Amsterdam, the Netherlands
Paul van Tongeren, Professor Department Philosophy, Radboud University
Nijmegen, the Netherlands
Robert G. Varady, Deputy Director and Research Professor of Environmental Policy,
Udall Center for Studies in Public Policy, The University of Arizona, Tucson, AZ
Anné H. Verhoef, Associate Editor, Professor, Faculty of Arts: School of
Philosophy, North-West University, Potchefstroom, South Africa
Xiao Yun Zheng, Professor & Assistant President of Yunnan Academy of Social
Sciences (YASS) and Director International Center for Ecological Culture Studies
(ICECS-YASS), Yunnan Academy of Social Sciences, Kunming City, China
Peer Review Declaration
The Publisher (AOSIS) endorses the South African ‘National Scholarly Book Publishers
Forum (NSBPF) Best Practice for Peer Review of Scholarly Books’. The manuscript
was subjected to rigorous two-step peer review prior to publication, with the identities
of the reviewers not revealed to the author(s). The reviewers were independent of
the publisher and/or authors in question. The reviewers commented positively on
the scholarly merits of the manuscript, and recommended that the manuscript be
published. Where the reviewers recommended revision and/or improvements to the
manuscript, the authors responded adequately to such recommendations.
Research Justification
Project success is widely covered, and the discourse on project complexity
is proliferating. The purpose of this book is to merge and investigate the two
concepts within the context of information system (IS) projects and understand
the symbiosis between success and complexity in these projects. In this original
and innovative research, exploratory modelling is employed to identify the
aspects that constitute the success and complexity of projects based on the
perceptions of IS project participants. This scholarly book aims at deepening the
academic discourse on the relationship between the success and complexity of
projects and to guide IS project managers towards improved project performance
through the complexity lens.
The research methodology stems from the realisation that the complexity of
IS projects and their relationship to project success are under-documented. A
post-positivistic approach is applied in order to accommodate the subjective
interpretation of IS-project participants through a quantitative design. The
researchers developed an online survey strategy regarding literature concerning
the success and complexity of projects. The views of 617 participants are
documented. In the book, descriptive statistics and exploratory factor analysis
pave the way for identifying the key success and complexity constructs of IS
projects. These constructs are used in structural-equation modelling to build
various validated and predictive models.
Knowledge concerning the success and complexity of projects is mostly generic
with little exposure to the field of IS project management. The contribution to
current knowledge includes how the success of IS projects should be considered
as well as what the complexity constructs of IS projects are. The success of IS
projects encompasses strategic success, deliverable success, process success
and the ‘unknowns’ of project success. The complexity of IS projects embodies
organisational complexity, environmental complexity, technical complexity,
dynamics and uncertainty. These constructs of success and complexity are
mapped according to their underlying latent relationships to each other.
The intended audience of this book is fellow researchers and project and IS
specialists, including information technology managers, executives, project
managers, project team members, the project management office (PMO), general
managers and executives that initiate and conduct project-related work.
The work presented in this first edition of the book is original and has not been
plagiarised or presented before. It is not a revised version of a thesis or research
previously published. Comments resulting from the blind peer review process
were carefully considered and incorporated accordingly.
Prof. Carl Marnewick, Wikus Erasmus & Nazeer Joseph
Department of Applied Information Systems
University of Johannesburg
South Africa
Contents
Abbreviations appearing in the Text and Notes x
List of Tables
xi
List of Figures
xiii
Notes on Contributors
xv
Chapter 1
Introduction
1
Investment in information technology
1
Value of IT
3
IS project success rates
6
Strategic alignment of IT
9
Types of IS projects
10
Infrastructure 10
Customisation 11
Integration 11
System implementation (full)
11
System implementation (upgrade)
12
Method of implementation
12
Waterfall model
12
Agile approach
13
Research methodology
15
Book layout
16
Chapter 2
Demystifying project success
18
The evolution of success
20
Project outcomes
21
Success and failure
25
Outcome influencers
27
Project success
27
Product success
28
Organisational benefit
29
Conclusion 32
vii
Contents
Chapter 3
Complexity of information system projects 33
The concept of project complexity
34
Complexity model for new development products
34
Novelty, Technology, Complexity and Pace model
36
Project Complexity Model
37
Information systems development projects
complexity model
39
Constituents of project complexity
41
Organisational complexity
42
Technical complexity
52
Environmental complexity
54
Uncertainty 57
Dynamics 59
Conclusion 60
Chapter 4
I nsights into information system project
success
62
General information
63
Project success
66
Process success
66
Project success
68
Deliverable or product success
70
Business success
73
Strategic success
75
Overall IT project success
76
Conclusion 80
Chapter 5
I nsights into information system
project complexity
Information system project complexity features
Organisational complexity
Technical complexity
viii
81
82
82
85
Contents
Environmental complexity
87
Dynamics 90
Uncertainty 93
Overall complexity view
95
Conclusion 99
Chapter 6
ymbiosis between IS project
S
success and complexity
100
Conceptualising the symbiosis between information
system project success and complexity
100
Development and analysis of IS project
success models
104
Overall results
105
Results for Waterfall projects
111
Results for Agile projects
114
Development and analysis of IS project
complexity models
116
Organisational complexity and project success
118
Environmental complexity
119
Technical complexity, dynamics and uncertainty
126
Overall exploratory factor analysis modelling of
technical complexity, dynamics and uncertainty
126
Conclusion 135
Chapter 7
Simple, complicated, complex and chaos
137
Appendix 141
References 144
Index
156
ix
Abbreviations appearing
in the Text and Notes
EFA
Exploratory Factor Analysis
HSSE
Health, Safety, Security and Environment
ISDP
Information System Development Project
IS
Information System
IT
Information Technology
KMO Kaiser-Meyer-Olkin
NPD
New Product Development
NTCP
Novelty, Technology, Complexity and Pace
PCM
Project Complexity Model
®
PMBOK A Guide to the Project Management Body of
Knowledge
x
List of Tables
Table 1.1: Information technology spending world.
2
Table 1.2: Information technology waste – worldwide. 8
Table 1.3: Information technology waste –
South Africa.
9
Table 4.1: Cost and time comparison: Agile
versus Waterfall.
70
Table 4.2: Overall information technology
project success rates.
79
Table 5.1: Organisational complexity top five
complexity features (Overall).
82
Table 5.2: Organisational complexity top five
complexity features (Agile).
83
Table 5.3: Organisational complexity top five
complexity features (Waterfall).
84
Table 5.4: Technical complexity top five complexity
features (Overall).
85
Table 5.5: Technical complexity top five complexity
features (Agile).
86
Table 5.6: Technical complexity top five complexity
features (Waterfall).
87
Table 5.7: Environmental complexity top five
complexity features (Overall).
88
Table 5.8: Environmental complexity top five
complexity features (Agile).
89
Table 5.9: Environmental complexity top five
complexity features (Waterfall).
90
Table 5.10: Dynamics top six complexity features
(Overall). 91
Table 5.11: Dynamics top six complexity
features (Agile).
92
Table 5.12: Dynamics top six complexity
features (Waterfall).
92
Table 5.13: Uncertainty top five complexity
features (Overall).
93
Table 5.14: Uncertainty top five complexity
features (Agile).
94
xi
List of Tables
Table 5.15: Uncertainty top five complexity
features (Waterfall).
Table 5.16: Top five and bottom five complexity
features across all construct.
Table 5.17: Top five and bottom five complexity
features across all constructs (Agile).
Table 5.18: Top five and bottom five complexity features
across all constructs (Waterfall).
Table 6.1: Overall factor loadings with Pattern Matrix.
Table 6.2: Model fit data for Overall model for
project success.
Table 6.3: Factors for project success with a
Pattern Matrix (Waterfall).
Table 6.4: Model fit for Waterfall project
success mode.
Table 6.5: Factors for Agile project success.
Table 6.6: Agile model fit measurements.
Table 6.7: Environmental complexity exploratory
factor analysis Patten Matrix.
Table 6.8: Environmental complexity exploratory
factor analysis Patten Matrix (Agile).
Table 6.9: Environmental complexity exploratory
factor analysis Patten Matrix (Waterfall).
Table 6.10: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix.
Table 6.11: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix (Agile).
Table 6.12: Technical complexity, dynamics and
uncertainty exploratory factor analysis
Pattern Matrix (Waterfall).
xii
95
96
97
98
106
110
112
114
115
118
120
122
124
127
130
133
List of Figures
Figure 1.1: Information technology services
spending – South Africa.
Figure 1.2: Information technology value framework.
Figure 1.3: International information system
project success rates.
Figure 1.4: South African information system
project success rates.
Figure 1.5: Waterfall model.
Figure 2.1: South African and global information
system project success rates.
Figure 2.2: Five levels of project success.
Figure 2.3: Project outcome and portfolio,
programme and project management.
Figure 2.4: Information technology enabled
operational transformation.
Figure 3.1: Overview of the components of
project complexity (derived from
content analysis).
Figure 4.1: Job description.
Figure 4.2: Type of information system projects.
Figure 4.3: Development method.
Figure 4.4: Crosstab between type of project
and development method.
Figure 4.5: Process success.
Figure 4.6: Process success (Agile vs Waterfall).
Figure 4.7: Cost and time comparison.
Figure 4.8: Scope comparison (Agile vs Waterfall).
Figure 4.9: Deliverable success.
Figure 4.10: Deliverable success (Agile vs Waterfall).
Figure 4.11: Business success.
Figure 4.12: Business success (Agile vs Waterfall).
Figure 4.13: Strategic success.
Figure 4.14: Strategic success (Agile vs Waterfall).
Figure 4.15: Overall success.
Figure 4.16: Longitudinal analysis of information
technology project s uccess rate.
3
5
7
8
13
19
22
24
30
43
63
64
65
65
67
67
69
71
72
73
74
75
76
77
77
78
xiii
List of Figures
Figure 4.17: Overall information technology
project success.
79
Figure 6.1: Symbiosis of information system
project success and information
system project complexity.
101
Figure 6.2: Project success level factors.
108
Figure 6.3: Unconfirmed model for project
success levels.
109
Figure 6.4: Unconfirmed model for Waterfall
project success levels.
113
Figure 6.5: Unconfirmed model for Agile project
success levels.
117
Figure 6.6: Environmental complexity factor
plot diagram.
121
Figure 6.7: Exploratory model for environmental
complexity of information system project. 121
Figure 6.8: Environmental complexity factor plot
diagram when using Agile.
123
Figure 6.9: Exploratory model for environmental
complexity (Agile).
124
Figure 6.10: Environmental complexity factor plot
diagram (Waterfall).
125
Figure 6.11: Exploratory model for environmental
complexity (Waterfall).
125
Figure 6.12: Exploratory model for technical
complexity, dynamics and uncertainty
of information system projects.
128
Figure 6.13: Exploratory model for technical
complexity, dynamics and
uncertainty (Agile).
131
Figure 6.14: Exploratory model for technical
complexity, dynamics and uncertainty
(Waterfall). 134
Figure 7.1: Information system project success levels. 138
Figure 7.2: Symbiotic IS project success and
complexity model.
140
xiv
Notes on Contributors
Carl Marnewick
Prof. Carl Marnewick’s academic career started in 2007 when he
joined the University of Johannesburg. He traded his professional
career as a senior information technology (IT) project manager
for that of an academic career. The career change provided him
with the opportunity to emerge himself in the question why IT
and/or Information System (IS)-related projects are not always
successful and do not provide the intended benefits that were
originally anticipated. This is currently a problem internationally as
valuable resources are wasted on projects and programmes that
do not add value to the strategic objectives of the organisation. It
is an international problem where there is a gap between theory
and practice and he is in the ideal position to address this problem.
The focus of his research is the overarching topic, and his
particular interest is the strategic alignment of projects to the
vision of the organisations. This alignment is from the initiation of
a project to the realisation of benefits. He developed a framework
(Vision-to-Project i.e. V2P) that ensures that projects within an
organisation are linked to the vision. Within this framework, a
natural outflow of research is the realisation of benefits to the
organisation through the implementation of IT and/or IS systems.
Benefits realisation is part of a complex system and his research
to date has identified the following impediments in the realisation
of benefits, (1) IT project success rates as well as IT project
management maturity levels did not improve over the last decade
and these results are in line with similar international research, (2)
IT project managers are not necessarily following best practices
and industry standards, (3) governance and auditing structures
are not in place and (4) IT project managers’ training and required
skills are not aligned. If these four aspects are addressed through
research and practice, then benefits realisation can occur.
His research has given him national and international presence.
He is currently a regular reviewer for national and international
journals. He was actively involved in the development of new
international project management standards ISO21500 and
ISO21503 (portfolio management). Project Management SA
xv
Notes on Contributors
awarded him the Excellence in Research Award as recognition
for his active contribution to the local and global body of
knowledge by conducting and publishing scientific research in
portfolio, programme and project management.
He is currently heading the Information Technology Project
Management Knowledge and Wisdom Research Cluster. This
research cluster focuses on research in IT project management
and includes, amongst others, governance, auditing and
assurance, complexity, IT project success, benefits management
and sustainability. Email: cmarnewick@uj.ac.za
Wikus Erasmus
Wikus Erasmus has been researching and lecturing at the
University of Johannesburg since 2010 in the Department of
Applied Information Systems. He has attained a master’s degree
in Business Management with his undergraduate studies in
Informatics. He is registered as a PhD candidate.
He did a tour of duty as a project manager in the construction
and information technology industry where he primarily focused
on IT infrastructure implementations. These were for major
South African corporate clients, including financial institutions
and retail holding groups.
His experience as a project manager in the IT industry has guided
him to focus on various issues of importance to project management.
These include the governance of projects, programmes and
portfolios, the strategic alignment of projects and the success of
IT projects. He has published various papers that addressed poor
communication and poor risk management practices in IT projects.
He also experienced the importance of stakeholder relations, even
when challenged, in the successful completion of a project.
He is of the opinion that proper governance frameworks
should be implemented if greater project success rates are to
be observed as these would improve the strategic alignment
of projects. This improved strategic alignment would ensure
that projects that contribute to organisational goals will be
attempted. The process needs to be overseen with concurrent
project auditing and a final project audit to impart organisation to
the organisation. These verification methods are yet other areas
that he has found lacking in the practice of project management.
Email: werasmus@uj.ac.za
xvi
Notes on Contributors
Nazeer Joseph
Nazeer Joseph (BCom, BCom Hons, MCom) is a native of
Johannesburg who, while working on his master’s degree, joined
the University of Johannesburg (UJ) as a part-time lecturer for
the Department of Applied Information Systems. The output of
his master’s degree was a predictive model for determining IT
project success. His master’s degree, which he achieved cum
laude, signifies his contribution to the IT project management
body of knowledge. On completion of his MCom, he joined UJ
on a full-time basis. He chose to pursue an academic career once
he completed his MCom and realised that the field of IT project
management requires extensive attention in order to improve IT
project success. The poor performance of IT projects is a global
phenomenon and must be addressed to ensure these projects
deliver the expected benefits to realise organisational goals and
objectives.
His research touches on a number of areas in the IT project
management domain, (1) IT project management processes,
(2) Agile IT project management, (3) IT project performance,
(4) IT project management competencies and (5) IT project
management sustainability. He is currently working on his PhD in
IT management with the primary focus on IT project management
processes. A key aspect why IT projects fail is that current
project management processes are inadequate for IT projects.
The aim of his PhD is to investigate why current processes are
inadequate and what can be done to improve these processes
and subsequently IT project performance.
As a junior lecturer and researcher at UJ, he has established
himself as performer and contributor to the IT project
management body of knowledge. He publishes in international
journals, participates in conferences and strives to continuously
contribute as a journal reviewer. His master’s research was the
only master’s degree presented at the 2014 PMI Research and
Education Conference.
In an effort to improve the state of IT project performance, he
works within a research cluster which has established close ties
with South African organisations to assist them with addressing
this problematic phenomenon. Email: njoseph@uj.ac.za
xvii
Chapter 1
Chapter 1
Introduction
Project success is one of the enigmas within the project
management discipline. No one is sure how to define project
success, what contributes to projects succeeding or failing or
how to measure the success of projects. This is even worse when
it comes to Information System (IS) projects. The deliverables
of IS projects are seldom seen apart from some application that
users and customers use as part of their daily routine. The only
time that the deliverable of an IS project is visible and tangible
is when the focus of the IS project is to replace or upgrade
hardware.
I nvestment in information
technology
Vast amounts of money are spent annually on Information
Technology (IT). The rationale is that organisations cannot
function without IT and therefore it warrants the large amounts
of money that are invested in IT. A report by Lovelock et al.
(2017) indicated that IT spending is rising on an annual basis and
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Introduction’, in The symbiosis
between information system project complexity and information system project success,
pp. 1–17, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2017.itpsc45.01
1
Introduction
TABLE 1.1: Information technology spending world.
Years
Spending (Billions of
dollars)
2014
2015
2016
2017
2018
2019
Data centre systems
166
171
170
175
176
178
181
Enterprise software
310
314
333
355
380
407
436
Devices
649
646
588
589
589
593
593
IT services
897
866
900
938
981
1029
1081
Communications services
Total
2020
1541
1399
1384
1408
1426
1441
1462
3564
3395
3375
3464
3553
3648
3752
Source: Lovelock et al. 2017.
will continue to rise for the foreseeable future. Annual growth
is predicted to be around 2.7%. The prediction is illustrated in
Table 1.1.
It is evident from the amounts in Table 1.1 that companies as
well as governments spend a lot of money on IT-related services.
The annual increase of 2.7% also indicates that IT is a continuous
investment. This continuous investment in IT is also evident
from a South African perspective where it is expected that
South Africa will spend $10.5 billion in 2017. This is 0.3% of the
worldwide spend on IT. Research indicated that South African
companies spend billions of rands on IT services as illustrated in
Figure 1.1.
The South African spend on IT services is 0.5% of the
worldwide spend on IT services. That is an amount of $5bn. IT
services normally include, (1) IS consulting, (2) system integration,
(3) maintenance, support and upgrades, (4) full outsourcing
and (5) hosting. The remainder is spent on devices, enterprise
software and communication services. Given this amount of
money that is spent on IT, the question is raised whether this
adds any value to organisations, irrespective of whether they are
public or government entities. The amount that is annually spent
on IT is a mere 0.7% of South Africa’s gross domestic product.
One of the control objectives within COBIT 5 (EDM02) states
that organisational leaders should receive the optimal value from
2
Chapter 1
IT Spend (Billions rands)
90
87.3
85
80
75
75
70
70
65
63
60
55
65
56.9
50
2015
2016
2017
2018
2019
2020
Source: Lovelock et al. 2017.
FIGURE 1.1: Information technology services spending – South Africa.
their investments in IT services and IT assets (IT Governance
Institute 2012). Even from a governance perspective, IT
investment should make logical sense and contribute to the
overall benefit of the organisation. IT investments are generally
implemented through programmes or projects that create
benefits and ultimately business value (Curley, Kenneally &
Carcary 2016).
Value of IT
IT provides value to entire organisations because they reach
out to the world through IT. IT is not perceived as a stand-alone
entity or division because it is integrated within the organisation,
and organisations cannot perform without IT. When IT does not
deliver value, then the chances are that the organisation will also
not reach its optimum performance.
The questions that organisations need to answer are: Firstly,
What value is IT to the organisation? and secondly, How can this
3
Introduction
value be measured? The value of IT can be determined through
the following equation:
Value of IT = Benefits – Costs
Given this equation, organisations should determine the
benefits that they receive from IT and also how much it costs to
implement, maintain and upgrade IT.
Determining the costs of IT is relatively easy, but organisational
leaders should not just take the direct costs into account but
also the hidden or overlooked costs. Hidden costs include, but
are not limited to, recruiting, training, office space, software
enhancements (upgrades), software maintenance (bug fixes),
hardware upgrades, hardware maintenance and scheduled
outages. Ascertaining the benefits of IT is not easy. The easiest
way might be to shut down the entire IT department for a day or
two and determine the impact on the organisation based on lost
sales and opportunities or the negative impact on the brand of
the organisation.
Irrespective of what metrics are used to determine the
benefits of IT, a general way to determine the benefits is to use
financial calculations such as Return on Investment, Payback
Period or Net Present Value. The results from these financial
calculations normally indicate whether an investment in IT is
a safe and profitable investment. The benefits of IT are also
intangible and these are the challenge that organisational
leaders face. How do organisations quantify the intangible
benefits of IT?
Harris, Herron and Iwanicki (2008) provided a framework
that can be used to determine the value of IT. The value of IT is
determined over a period of time and is based on the investment
in IT and also the benefits of IT to business. A simplified version
of the framework is illustrated in Figure 1.2.
The value of IT to business is determined by the degree
whereby processes are influenced and changed, how sales have
improved and whether there is a growth in revenue at the end
4
Chapter 1
Business operational value
Business process value
IT Application business value
IT investments
IT Infrastructure business value
IT
Managment
responsibility
Business investments
Business
Managment
responsibility
Business financial value
Time for business impact
FIGURE 1.2: Information technology value framework.
of the day. Figure 1.2 actually highlights that everyone in the
organisations are responsible for determining the value of IT.
The IT department provides IT as an enabler for business and
it is up to business to determine to what extent they want to
embrace IT.
IT investments are normally realised through projects and the
more successful the projects, the more value is created from the
IT investments. The following sections briefly discuss the success
rates of IS projects and highlight that organisations do not obtain
value from IT projects and therefore also not from IS.
Information technology is the cumulative word that is used
to describe everything and anything that has vaguely to do with
computers. IT consists of three components, of which the first
is computer science. This discipline focuses on topics such as
discrete structures, human-computer interaction, programming
fundamentals, graphics and visual computing, algorithms and
complexity and programming languages amongst others.
The second layer or component is information technology.
This discipline focuses on the selection, creation, application,
integration and administration of computing technologies.
Computing technologies include networking, databases, web
systems and information security. Information systems is
5
Introduction
the third layer and focuses in general on the improvement of
organisational processes and the design and management
of enterprise architecture. Topics within the IS field focus on
data and information management, enterprise architecture, IT
infrastructure, IS project management, systems analysis and
design as well as IS strategy.
This study focuses specifically on the third layer, that is, the IS
layer and more specifically on IS project management.
IS project success rates
IS projects are the vehicles that organisational leaders use to
implement the IT strategy. The logical conclusion is that when IS
projects fail or are perceived as not delivering on all the benefits,
then the IT strategy is not fully implemented. This then creates
an imbalance where the IT strategy does not fully contribute to
the organisational strategies.
Information system project success has been studied over
the last couple of decades by academics and practitioners
alike. The reason for this almost frenetic research is that there is
enough evidence to indicate that IS projects are still failing at an
alarming rate. This was the case two decades ago, and it is still
the case in the late 2010s. Research is performed internationally
by the Standish group which produces the Chaos Chronicles,
and in South Africa the research on IS project success rates is
called the Prosperus reports (Labuschagne & Marnewick 2009;
Marnewick 2013; Sonnekus & Labuschagne 2003). Results from
the international research are shown in Figure 1.3.
The results indicate clearly that something drastically is wrong
as the rate to successfully implement an IS project is on average
28%. This implies that 70% of IS projects either do not add value
or add limited value to organisations. Of even greater concern is
the fact that the success rates have stagnated at around 30% for
the last decade, implying three things:
6
Chapter 1
40
35
35
32
Percentage
30
27
25
26
28
29
31
29
29
28
27
20
15
16
10
5
0
1994
1996
1998 2000 2004 2006 2009 2011
2012
2013
2014
2015
Year
Source: Labuschagne and Marnewick (2009); Marnewick (2013); Sonnekus and Labuschagne (2003).
FIGURE 1.3: International information system project success rates.
1. IT departments and professionals actually do not care about
these results.
2. We do not understand the complexity of IS projects.
3. We are measuring the success of IT projects incorrectly.
IS projects success rates within South Africa do not look much
better as indicated in Figure 1.4.
Although the South African success rates look better than the
international success rates, South African companies are in the
same boat as international companies where a mere third of IS
projects are perceived as successful.
When these results are translated into monetary value, a
gloomy picture is created as indicated in Table 1.2. The results
indicate that $17 820bn are wasted on IS projects that either do
not deliver or deliver little value to a company.
The South African perspective is just as bleak as indicated in
Table 1.3. On average, 57 cents are wasted for every one rand
spent on IT.
7
Introduction
70
60
59
Percentage
50
40
43
37
34
30
20
10
0
2008
2003
2011
2013
Year
Source: Labuschagne and Marnewick (2009); Marnewick (2013); Sonnekus and Labuschagne (2003).
FIGURE 1.4: South African information system project success rates.
TABLE 1.2: Information technology waste – worldwide.
Year
Billions of dollars
Spending
Waste
2014
3564
2566
2015
3395
2444
2016
3375
2430
2017
3464
2494
2018
3553
2558
2019
3648
2627
2020
3752
2701
Total
24 751
17 820
The results depicted in this section clearly indicate that
companies need to address the success rates of IS projects as
a matter of urgency. Information technology cannot continue
to be seen as a black hole into which money disappears and
little or no value is created for the company and all the relevant
stakeholders.
8
Chapter 1
TABLE 1.3: Information technology waste – South Africa.
Year
Billions of rands
Spending
Waste
2015
56.9
32.4
2016
63
35.9
2017
65
37.1
2018
70
39.9
2019
75
42.8
2020
87.3
49.8
Total
417.2
237.8
Strategic alignment of IT
Projects are generally perceived as the vehicles to implement
strategies (Cooke-Davies 2016; Martinsuo, Gemünden & Huemann
2012; Marnewick & Labuschagne 2010). These strategies can
be organisational strategies or they can be strategies specific
to a division within the organisation. IT strategies are also
implemented through projects.
IT strategies are derived from the organisational strategies
and are therefore aligned with the organisational strategies
(Marnewick & Labuschagne 2011). This implies that when the
organisational strategies change, the IT strategies should also
change and be realigned with the organisational strategies.
Within the COBIT governance framework, EDM01 (Ensure
Governance Framework Setting and Maintenance) focuses on
the alignment of the IT strategy with the organisational strategy
(IT Governance Institute 2012). EDM01 measures three specific
concepts related to the IT strategic alignment:
•• The percentage of organisational strategies supported by IT
strategies.
• The level of stakeholder satisfaction with the intended IT
portfolio. The IT portfolio consists of various programmes and
projects that will implement the IT strategy and ultimately the
organisational strategy.
9
Introduction
• The percentage of IT-value drivers that are mapped to the
organisational value drivers.
Given the notion that projects are the vehicles to implement
the IT strategies, organisational leaders should then be seriously
concerned. The IS project success results clearly highlight the
notion that IT strategies cannot be fully implemented because
of the large number of IS projects that are failing. It is evident
that only a small percentage of the IT strategy is implemented
which in turn implies that IT strategies are not necessarily
supporting the organisational strategies. This raises the
question whether IT adds value to the organisation at large as
suggested by EDM02.
This non-delivery of IT strategies creates a governance
concern. The question that needs to be answered is what the
real value is that IT brings to the organisation at large. There
is no doubt that organisations cannot function without IT, but
the question is whether IT is of strategic value or operational
value. The results suggest that IT is more of operational value
than strategic value.
Types of IS projects
There is no one-size-fits-all solution when it comes to the
implementation of IS projects. IS projects come in different
flavours and IS project managers should take cognisance of
these different types of projects.
Infrastructure
The implementation of IT infrastructure is one of the least
complex projects to realise. These types of projects focus on
the implementation of hardware such as networking equipment
or the installation of desktops and printers. What makes these
types of projects less complex is the simplicity and predictability
to implement. For example, when an organisation needs to
10
Chapter 1
relocate offices, new network points need to be installed. The
project schedule is easily created, as the project manager will
know more or less how long it takes to install a network point
and that the time needed is merely multiplied by the number of
network points. The same logic applies when printers or desktop
workstations need to be installed.
Customisation
Customisation of software is a little bit more complex than
the implementation of infrastructure. Software products
do not necessarily suit the needs of an organisation as is.
To cater for the specific needs of an organisation, software
needs to be customised or changed. This change is more a
cosmetic change to the existing software product than a major
change to the internal workings of the software package.
Customisations might include the change of financial reports
to suit legislation or a change in the look and feel of an order
capture screen.
Integration
Integration on the other hand is more complex than
customisation. Integration focuses on sending data (information)
between two software products. This implies that the
software developer needs to understand the data structure of
both products and the way that data is stored. Integration focuses
on the conversion of data from the one product to the
other product and vice versa. Planning for integration is also
tricky as it is not always that easy to estimate the duration of any
integration.
System implementation (full)
A full system implementation is extremely complex and
contains a lot of uncertainties. A full system implementation
11
Introduction
is typically when organisations decide to replace one system
with another system. This might be the case when an Enterprise
Resource Planning (ERP) system replaces a legacy system.
This type of implementation requires all hands on deck and
normally includes infrastructure replacements, customisations
and integrations with other systems.
System implementation (upgrade)
An upgrade is also complex and consists of a level of uncertainty
but not to the extent of a full system implementation. The
difference between an upgrade and a full implementation is
that the basic building blocks are in place. The upgrade focuses
on staying current with the latest version of the software.
The upgrade might include the upgrade of infrastructure but
definitely some customisations and integrations. Customisations
and integrations can follow different methods of implementation,
that is the traditional Waterfall method or an Agile approach.
Method of implementation
Various methods exist to implement IS projects, but it is not the
purpose of this book to discuss all the different methods. The
two most important methods are the Waterfall model and Agile
and its various variations.
Waterfall model
One of the first structured approaches developed was the
Waterfall process. In this model as illustrated in Figure 1.5, the
process is executed in an orderly sequence (Leffingwell 2011).
Each stage is completed before the next stage starts (Leffingwell
2011). Requirements are agreed, a design is created after which
the coding follows and testing is performed. The final step is
integration. In practice when implementing complex systems, it
is almost impossible to have requirements that do not change
12
Chapter 1
Requirements
Design
Code
Test
Integrate
Source: Dorfman and Thayer (2000).
FIGURE 1.5: Waterfall model.
during the implementation life cycle (Dorfman & Thayer 2000).
The advantage of the model is that it is a simple process to
manage (Sommerville 2001).
An iterative approach is used in the Waterfall model where
each successive step provides feedback to a previous step (Royce
1970). However, the Waterfall model is mostly interpreted as a
sequential linear process (Boehm 2006).
Agile approach
Agile methodologies were initially authored to manage the
development of software development projects, but have been
extended because of their popularity and success with handling
most types of IS projects. Agile software development is a method
of software development that is characterised by an emphasis
on, (1) people, (2) communication, (3) working software and (4)
responding to change.
The working definition of Agile methodologies can be
summarised as a group of software development processes that are
iterative, incremental, self-organising and emergent. Hence from a
theoretical perspective Agile methodologies can be defined as:
13
Introduction
•• Iterative: The word iterative is derived from iteration which
carries with it connotations of repetition. In the case of Agile
methodologies it is not just repetition but an attempt to solve
a software problem by finding successive approximations to
the solution starting from an initial minimal set of requirements.
• Incremental: Each subsystem is developed in such a way that
it allows more requirements to be gathered and used to
develop other subsystems based on previous ones. The
approach is to partition the specified system into small
subsystems by functionality and add a new functionality with
each new release.
• Self-organising: This term introduces a relatively foreign
notion to the management of scientific processes. The usual
approach is to organise teams according to skills and
corresponding tasks and let them report to management in a
hierarchical structure. In the Agile development setup the
‘self-organising’ concept gives the team autonomy to organise
it to best complete the work items.
• Emergent: The word implies three things. Firstly, based on the
incremental nature of the development approach the system
is allowed to emerge from a series of increments. Secondly,
based on the self-organising nature a method of working
emerges as the team works. Thirdly, as the system emerges
and the method of working emerges a framework of
development technologies will also emerge.
It must be noted that for the purpose of this book and study,
reference is made to Waterfall projects and Agile projects. Waterfall
projects are IS projects that make use of the Waterfall method to
deliver the software that forms part of the larger project. Similarly,
Agile projects are projects that make use of Agile methods to
develop software. These terms are strictly not the correct terms
but are used for ease of reading and understanding.
Previous studies uncovered various factors that contribute to
IS project success (Marnewick 2013; The Standish Group 2014).
Although complexity was defined as a factor, complexity as a
construct was never investigated as a factor itself. The purpose
of this study is to understand complexity within the IS domain
14
Chapter 1
and to determine the relationship between IS project success and
complexity. This was achieved through a quantitative approach.
Research methodology
A quantitative approach was used for this study as the primary aim
was to determine current IS project success rates as well as the
relationship with complexity (Denscombe 2010; Thomas 2003).
The rationale for this decision was two-fold. This study builds on
previous studies (Labuschagne & Marnewick 2009; Marnewick
2013; Sonnekus & Labuschagne 2003), and IS success rate
trends need to be established. This can only be done through a
longitudinal study that is embodied within a quantitative approach.
The second reason was that it ensured that each respondent was
presented with the exact same questions in the same sequence.
Moreover, this allowed the researchers to reliably aggregate and
compare the responses between different sample subgroups.
Probability sampling was used as this research focused on
providing a representative view of the unit of analysis for the
purpose of generalisability (Sekaran 2003). Simple random
sampling was selected because it not only provides results which
are highly generalisable, but also adequately represents the
target population. Furthermore, as this form of sampling exhibits
low bias, the results obtained would provide an objective view of
the research problem.
The instrument used for this study was a questionnaire. The
questionnaire was divided into four sections. The first section
focused on the biographical information of the respondent.
The second part focused on the type of IS project that is under
investigation. Two important aspects that form part of an IS
project had to be answered. The first aspect speaks to the type
of IS project and the second aspect speaks to the type of method
that was used to implement the IS project.
The third section of the questionnaire dealt with the notion of
IS project success. This section was designed around the model
of Bannerman and Thorogood (2012). Each component within a
15
Introduction
success level was measured based on a Likert scale. Respondents
could choose between poor, fair, good, very good and excellent.
This was applicable to processes, deliverables, business and
strategic success. Actual figures were provided for cost and time
that form part of project management success.
The fourth section of the questionnaire focused on the
complexity of the project. Five types of complexity had to be
assessed based on a Likert scale. Respondents could choose
between simple, relatively simple, fairly complex, complex
and very complex. Organisational complexity consisted of 34
types of complexity, technical complexity consisted of 12 types,
environmental complexity consisted of 13 types, dynamics
consisted of 6 types and uncertainty consisted of 10 types. The
types of complexity are discussed in detail in Chapter 3.
Book layout
The book is divided into the following chapters for ease of
reading and referencing. Chapter 2 focuses on IS project
success and what constitutes IS project success. The framework
of Bannerman (2008) is used to describe IS project success.
Success is not just a yes or no answer but can be measured at
various levels that might have an impact on one another. This
model or approach provides organisational leaders with a better
way to measure and determine IS project success.
The third chapter unpacks the notion of complexity. This is
done through the lenses of IS projects. The outcome is that IS
projects are complex and that five types of complexity influence
IS projects. Each of these five complexity constructs consists
of elements that in turn consist of features. This makes the
management of IS projects extremely complex.
Chapter 4 analyses the success of IS projects. Each level of
the framework is used to determine project success. For each
level, the overall success is determined as well as the success for
the Waterfall and Agile projects. The results highlight that there
16
Chapter 1
is an improvement in overall IS project success and that Agile
projects might be more successful than Waterfall projects.
Chapter 5 investigates the results of IS complexity. To simplify
the matter, the top five and bottom five elements are provided
for each complexity construct. This is also done for all IS projects
and specifically for the Agile and Waterfall projects.
Chapter 6 focuses on the relationship or symbiosis between
IS project success and complexity. The results indicate that a
symbiotic relationship exists between IS project success and
complexity. The various complexity constructs are mapped to
the levels of IS project success.
Chapter 7 concludes the book. A synopsis is provided to
enable organisational leaders and IS project managers to utilise
the information and make better decisions, increase IS project
success rates and address complexity within IS projects.
17
Chapter 2
Demystifying project
success
Most IS projects fail (Johnson 2014; Marnewick 2013a, 2013b).
In fact, almost two thirds of IS projects evaluated since 2003
could not be classified as success stories. Figure 2.1 indicates the
lack in progress made by project management professionals in
increasing the rate of delivering success.
The South African results approximate the international results,
indicating that there are not simply local conditions at play. There
must be something at the heart of IS project management that is
actively driving these results.
Billions of rands are spent each year on IT services, and
investment is set to grow in this area (Lovelock et al. 2017). No
wonder organisational leaders are losing confidence in project
management methodologies when almost two-thirds of IS
projects fail and investment is lost, or the project does not deliver
on its promise.
Much has been written on why projects fail (Budzier &
Flyvbjerg 2015; Erasmus, Marnewick & Joseph 2014; Joseph
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Demystifing project success’,
in The symbiosis between information system project complexity and information system
project success, pp. 18–32, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2017.itpsc45.02
18
Chapter 2
70
59%
60
Percentage
50
CHAOS Chronicles
Prosperus Reports
43%
40
37%
30
35%
34%
31%
29%
29%
20
10
0
2002
2004
2006
2008
Year
2010
2012
2014
Source: Joseph, Erasmus and Marnewick (2014).
FIGURE 2.1: South African and global information system project s uccess rates.
et al. 2014; Marnewick, Erasmus & Joseph 2016a, 2016b; Ngoma
& Erasmus 2016). This knowledge has been with project
professionals for a very long time. It is known why projects fail.
It is known what should be done to ensure projects are delivered
successfully (Cooke-Davies 2002). Yet, project managers cannot
seem to increase their project delivery success rates. This is the
annunciation of Cobb’s paradox: If we know why projects fail and
how to prevent it, why do we still fail at projects? (Bourne 2011).
The answer could lie in the fact that much research has been
done in the technical aspects of project management, while
limited studies are done in the so-called ‘soft issues’ around project
management. It may very well be that the identified inhibiters
and enablers of project success are only partially responsible for
project outcomes and more remain to be uncovered. What may
complicate matters even more is the possibility that IS projects
do not fit the traditional paradigm of project management as we
know it today. Perhaps IS projects are so different that project
management should be rethought in its entirety in order to deal
with the idiosyncrasies of IS project management.
19
Demystifying project success
What is abundantly clear is that should IS project delivery
continue on the current trajectory, we may very well not
encounter the term ‘IS Project Management’ in future. Investment
decision-makers will look elsewhere to achieve the goals that
formal project management methodologies promised.
The evolution of success
One of the formal definitions of a project is that it is a set of
predetermined activities that need to be completed incrementally
in order to achieve a unique, predefined objective through the
use of resources in a specified time frame (Project Management
Institute 2013; Schwalbe 2016). At face value, it is a relatively
simple task to provide a deliverable in the manner a customer
requests.
Tools, techniques and processes that were already available
to operations were adapted to compensate for the closed-off
time frame in completing these activities. These were harnessed
into formal project management methodologies. This was the
approach of the 1970s, although projects have been attempted
and completed for centuries and millennia before then.
Much of past research was focused on the mechanisms, tools
and techniques for managing a project properly. Bodies such as
the Project Management Institute and Association for Project
Management have developed innumerable toolkits, standards,
methodologies and frameworks to assist project practitioners in
this endeavour.
But that was not the end of the story. Organisational leaders
discovered that even though they had to manage project
managers through strict quantifiable metrics, such as the
triple constraint, customers were often satisfied with the end
product, although they might not have been satisfied in the
manner of its delivery. The product became then the priority
at the end of the day. The end seemed to justify the means
(Davis 2014).
20
Chapter 2
Success varied by industry, yet large amounts were and
are invested in project management training and capabilities.
As organisations continued to grow, so did the scale and
complexity of projects. So much so that megaprojects could
not be managed by a single individual but through committees.
Megaprojects had strategic significance and as such they were
broken down into smaller projects. Programmes emerged.
Some oddball projects were encountered that did not seem
to fit in with the strategic intent of the organisation. Portfolio
management was then required to select and reject projects that
would have the greatest benefit in supporting the organisations’
strategic objectives. However, complexity grew even more as
organisations sought to gain competitive advantage through
projects. Market forces dictated that organisations needed to take
decisive action in attempting to gain and maintain market share.
Project management has now become an important strategyachieving tool through portfolio management. Any selected
project has to contribute to achieving the greater organisational
strategic intent.
Ultimate project success is now characterised by strategically
effective organisations. But what does that mean to the project
manager that is currently experiencing his or her first project
that simply cannot be steered to success, regardless of what
interventions are put in place? The so-called ‘project of death’.
Project outcomes
No discussion on project management success can be held
without referring to the seminal work performed by Paul
Bannerman. He rightly deduced that project success is achieved
on multiple levels and developed a framework to illustrate this
concept (Bannerman 2008; Bannerman & Thorogood 2012).
Figure 2.2 lays out the case that project success is defined
from various perspectives. In Level 1, project success is defined
by the successful implementation of project management tools
21
Demystifying project success
Return on investment
Tactical
(Derived value)
Strategic
Stakeholders
Technical
Project
Client/User
Level 1
Level 2
Level 3
Project
Process
success
PM
success
Product
Deliverable
success
Business: Internal
Level 4
External
Level 5
Organisational benefit
Business
success
Strategic
success
Source: Adapted from Bannerman (2008).
FIGURE 2.2: Five levels of project success.
and techniques. Success at this level is determined through the
selection of appropriate tools and how effective they were used.
In Level 2, success is measured according to whether the
project has met the triple constraint of time, cost and scope.
A failure to meet any of these technical constraints would result
in total project failure at Level 1 and Level 2.
Customers, clients or users are usually less concerned
about whether the projects have used the appropriate technical
tools. They may be somewhat concerned how well the project
fared with regard to the triple constraint. However, users and
customers are mostly concerned about the deliverable the
project produces at the end of the day. Consideration such as
‘fit for use’ or usability are of greater concern at Level 3. Various
examples exist where the product produced by a project can
successfully be used by the project’s customers and has yet
failed on Level 1 and Level 2 criteria (Marnewick 2016; Serra &
Kunc 2015). If a project meets the customer’s specifications, the
project can be termed a success on Level 3. Product success
would then be achieved.
22
Chapter 2
Project success on Level 4 is determined by realised benefits
provided subsequent to project completion. Should the benefits
promised in the initial business case actually accrue or realise as
a direct result of a completed project, then the project would
be a success. Unfortunately, these benefits do not immediately
become apparent as soon as the project is completed (Marnewick
2013b). These benefits would only start to become a reality when
the product delivered by the project has been fully operationalised
and integrated in the organisation. Only after an indeterminate
period of time, and after careful observation and measurement,
would the direct impact of the deliverable become known.
Ultimately, Level 4 project success is determined by whether
or not business goals have been achieved or not through
the successful completion of a project. What one has to bear
in mind is the fact that certain unintended consequences or
benefits may result after the integration of a project product in
the organisation. Where it may be difficult to point to a specific
project to indicate what impact it had on achieving business goals,
it may be simpler to determine where a group of strategically
similar projects have had such an impact. This may be done in
the form of prudent programme management where control and
coordination could be achieved between projects that are aimed
at achieving a particular business objective. In organisations
where no programme management discipline exists, it will have
to make do with strong project management reporting.
Level 5 project success is externally focused in that strategic
success is to result because of successful project delivery. These
concerns are focused on whether the organisation’s position shows
improvement with regard to investors, the competition and the
market in general. This level of success may be extraordinarily
difficult to attribute to any single project. Therefore, portfolio
management may be better suited as this is an attempt to aggregate
all project outcomes throughout the organisation to determine the
strategic success of the project discipline in the organisation. This
will obviously only be of any meaning if an effort was made to align
all projects to the organisation’s strategic intent.
23
Tactical level: Programme management
Level 4: Business success for internal business stakeholders
Level 3: Deliverable success for user/clients
Operational level: Project management
Level 3: Deliverable success for user/clients
Level 2: Project management success for stakeholders
Level 1: Process success for technical stakeholders
Product &
project success
Strategic level: Portfolio management
Level 5: Strategic success for external stakeholders
Level 4: Business success for internal business stakeholders
Organisational benefit
Demystifying project success
FIGURE 2.3: Project outcome and portfolio, programme and project management.
Mapping these perspectives to the traditional three
organisational levels as well as project, programme and portfolio
management provides the following view in Figure 2.3.
Some overlap may exist on Level 3 and Level 4. Deliverable
success may form part of project or programme management,
depending on the structure of the organisation. Level 4 is
most often found under portfolio management (Jenner 2016)
of the organisation but may also be found under programme
management (Serra & Kunc 2015). These adaptations will have
to be considered in organisations that do not have a programme
management office for lack of need.
24
Chapter 2
Success and failure
When one is set to lose a contest one was almost certain to
win through bad judgment and mistakes, one is said to have
snatched defeat from the jaws of victory. In project management,
there seem to be many avenues to attain success, given the five
different available perspectives. Additionally, we know what
causes projects to fail and to succeed, yet we continue to reach
out feverishly towards defeat.
Bannerman (2008) takes great pains to clarify that the
five levels of project success are not related in an aggregated
manner. He indicated that process success does not imply
project management success. A project that was successfully
completed in scope, time and budget does not guarantee that
the deliverable will be accepted or useful to the customer.
A product regarded as useful by the customer does not imply
that business objectives will be met. Achieving business
objectives does not imply that the organisation will be
strategically successful. Clearly success is dependent on a
specific stakeholder’s perception.
Does one need to be successful on all five levels before a
project can be deemed successful? Luckily this seems not to be
the case as it would be a Herculean task. The technical project
team member responsible for a specific process on Level 1 can
in no way be held responsible for the outcome on strategic
success in Level 5. However, is the executive board dependent
on these technical processes being completed successfully in
order to attain strategic success in the long term? The research
determines it need not necessarily be so.
We are left with a conundrum. Vast bodies of literature
extoll the virtues of proper project, programme and
portfolio management. Each academic work enumerates the
seemingly countless processes, procedures, inputs and outputs
for each activity. Is it all for nought when the organisational
leaders above the project manager’s pay grade are unaffected
25
Demystifying project success
by their successes and failures? Why is there such an emphasis
on completing projects successfully when there is little ultimate
significance in the high levels of the strategic hierarchy?
It seems that project management shares certain principles
with alchemy. The alchemists of yore attempted to transform
lead into gold. They never attempted to create gold from
nothing. The same may be true in project management. The
technical processes on Level 1 needed to produce a ‘substance’
that project managers could use to transform into another
‘substance’ in Level 2. This new substance takes on the form
of a project outcome: success or failure. The individuals in
Level 3 need to create this ‘project management substance’
and create a product that could be either a success or a
failure. The Level 4 alchemist needs to transform this ‘product
substance’ into some sort of business benefit and that must be
transformed again into strategic success in Level 5.
Therefore, two items are required in order to perform ‘project
management alchemy’: substance and alignment, success is
not necessarily required. The substance is the output from each
level of project success. In order to guide the transformation
process to ultimately deliver project management ‘gold’ in the
form of strategic success, some sort of strategic alignment is
required.
Without some sort of outcome from the previous levels,
it would not be possible to create an outcome that could be
ultimately usable in Level 5. And even if a high-quality outcome
is delivered at lower levels, if it cannot be taken to ultimately
further strategic objectives, the effort is futile.
Evidently, the terms ‘success and failure’ only have meaning
on Level 5 as they relate to ultimate project outcomes. On
Level 1 to Level 4, ‘success and failure’ only serve as a basis for
organisational governance to ensure that resources are used
appropriately in order to deliver a ‘substance’ of higher quality
that could more easily be transformed in the next level.
26
Chapter 2
Outcome influencers
What would enablers and inhibitors of success be at each level in
this ‘process’ view? The discussion focuses on the three grouping
of success as identified by Bannerman (2008):
1. Project success including technical process and project
management success.
2. Product success.
3. Organisational benefit including benefits realisation and
strategic success.
Project success
The vast body of research focuses its attention on the mechanism
and processes of project management and what these contribute
to delivering successful projects. The main enablers of success
in this section primarily deal with the skills and knowledge of
project managers.
Regarding specific technical processes, the main aspects
that project managers and their team members need to focus
on is in risk management and change control (Marnewick
& Erasmus 2014). Of these two, risk management is the
knowledge area in the PMBOK® Guide that is the least matured
in practice:
•• Proper risk management practices increase the quality of
project management in that eventualities are planned for in
budget, schedule and scope. This would decrease variances in
the triple constraint, resulting in a greater chance of project
management success.
• When certain parameters of the project are changed,
depending on whether specific technical processes are
completed correctly, the knock-on effect impacts the triple
baseline constraint. Change control must be present as change
is a given in the vast majority of projects. The impact of
uncontrolled changes is impossible to fully quantify. The effect
on the project, however, is devastating.
27
Demystifying project success
The skill that most project managers agree is the greatest
contributor to success is communication with the project team
(Marnewick et al. 2016a, 2016b; Monteiro de Carvalho 2013). This
stands to reason as all interaction in a project concerns the flow
of accurate information.
Inhibitors to success would include the antecedents of the
contributors to project success as discussed. However, when
organisational leaders recognise the need for additional training
something very counterintuitive happens. Project managers who
are sent for certification courses seem to develop a reduced
ability to deliver projects successfully once they are certified in
a formal project methodology (Joseph et al. 2014). The reasons
behind this are unclear, but as it stands, formal certification
seems to be an inhibitor of project success.
Another great inhibitor to project success is an organisational
culture that does not allow for or value prudent project
management practices (Mir & Pinnington 2014; Rosemann
& Vom Brocke 2015). This would include undue pressure on
project managers to shorten the planning phase of their project
in order to get to execution more rapidly. This rush may leave
many risks and challenges unidentified, resulting in chaos during
execution.
Product success
Product success implies the user and/or customer have their
needs met through the project deliverable, regardless of how it
came into their hands (Bannerman 2008). The greatest success
enabler here is effective communication with stakeholders, more
specifically between the project team and the user or customer
(Barclay 2015; Davis 2014). This is to ensure that correct client
specifications are used in designing the product or service to
be delivered. This entails that proper requirements management
takes place. Regular customer feedback is required to ensure
that all stated needs are met in the deliverable.
28
Chapter 2
Another enabler of product success is the active involvement
of an individual that could fulfil a customer relations role that
further facilitates communication. This is especially important
when project management failure is looming.
An inhibitor to product success is, of course, miscommunication
and changing requirements. It will obviously be much more
difficult to meet customer requirements should these be in
flux. Unreasonable customers may also decide not to accept
the product even if all signed-off requirements are met, but the
actual product is not what was expected by the customer (Turk,
France & Rumpe 2014).
Organisational benefit
The organisational benefits are achieved as a result of successfully
completed projects or programmes in the organisation that
impart a strategic advantage.
Benefits realisation is a perspective internal to the organisation
that could overlap the strategic and tactical organisational levels.
This perspective takes a longer view of the effect of projects in the
organisation in that benefits can only accrue after a project has
been completed. These benefits are not immediately apparent. In
order to internalise these benefits, the project deliverable needs
to be integrated into the organisation. This would imply that some
level of organisational change management must be initiated. This
process could be illustrated as in Figure 2.4 (Coombs 2015).
For the implementation of an IS deliverable, operations need to
be adapted to accept and effectively utilise the new deliverable.
The premise is that business benefits will only accrue once business
change has occurred through the use of IT. This seems eminently
reasonable in an IS context (Whyte, Lindkvist & Jaradat 2016).
For the implementation of an IS-type deliverable, the following
main inhibitors to benefits realisation are identified (Coombs
2015):
29
Demystifying project success
Enablers
IT enabled operational transformation
IT
Business
change
Business
benefits
Inhibitors
FIGURE 2.4: Information technology enabled operational t ransformation.
•• Staff not engaging with new ways of thinking: This speaks
directly to the difficulty in changing organisational culture
and the individual’s resistance to change.
• Poor design of the new system: Clearly this links to product
success. A poorly designed product or deliverable will not be
readily accepted by its intended users. Expected benefits will
only accrue once these deficiencies are corrected after the
closure of the project.
• Poor performance of the system: This is another productrelated metric that would inhibit the use of the system and its
subsequent realised benefits.
Here we see a much stronger link between levels of
project success in Level 3 and Level 4, benefits realisation. The
results imply that a poor product deliverable could negatively
impact benefits realisation. A poor quality deliverable in
Level 3 implies an inhibitor to benefits realisation in Level 4.
Enablers of benefits realisation include the following:
• Training in the use of the deliverable. Users cannot immediately
accept the new deliverable. Initial acceptance would be
dependent on training and ensuring users and customers are
used to the new systems. However, this would only account
for product success on Level 3. Enhancing the chances of
success at Level 4 requires ongoing training for users to
use the new system to its fullest potential. A change in
organisational culture is required in order to sustain the
30
Chapter 2
transformation effort and to prevent users from falling back
into old patterns of behaviour that may have necessitated the
creation of a new system.
It seems in benefits realisation that inhibitors are more technically
oriented, while enablers are more organisationally oriented. It
would, therefore, be appropriate that transformation activities
take place under the auspices of an organisational entity that
is responsible for mapping and tracking benefits. Strategic
success on Level 5 has an external perspective where all project
activities, from Level 1 to Level 4, culminate in some impact on
the market. This is only possible where strategic alignment has
taken place where all projects are part of a concerted effort to
support strategy (Gerow, Thatcher & Grover 2015).
With this lofty goal in mind, it may stand to reason that project
practitioners have very little to do with strategic impact external
to the organisation. Instead, very senior members of the board
tasked with portfolio management are the key role players that
have to ensure that the organisation’s strategic intent is achieved
through the support of the entire organisation. The delivery of
a product through project management methodologies, while
essential, is only one small part of the entire exercise (Kaiser, El
Arbi & Ahlemann 2015).
An enabler of strategic success from a projects perspective
is a concerted strategic alignment initiative that ensures that all
projects are selected on their probability of success and envisaged
contribution to the organisation. Without such an alignment
effort an impact on the market can still be made, however, the
degree of impact would be very uncertain. Unexpected benefits
or issues may arise more frequently in such a case.
Inhibitors to strategic success may include actions to avoid
such as failure to establish a clear strategy and frequently
changing strategy. Both these situations require the entire ship
that is the organisation to change tack, while all its efforts are
focused on achieving and supporting a different strategy.
31
Demystifying project success
External market condition will also influence the degree to
which the current strategy is effective, if the organisation’s chosen
strategy has not been developed with this in mind. Inhibitors and
enablers for the success of Level 5 are much more dependent on
strategic management thinking than purely project management
considerations.
Conclusion
How project success and failure is defined depends greatly
on individual interpretation. When taking the organisational
perspective, perhaps project management success should be
viewed on a continuum and not on a binary scale of ‘success’ and
‘failure’. When drilling down into the details of what technical
and product success actually imply, lower orders of management
need to be aware of what metrics are being used to determine
and track how their scarce resources are being utilised.
Ultimately, the organisation exists to provide value to its
shareholders. This is most significantly achieved through
strategic impacts. However, there is something to be said for
laying the foundation for such success. Success on lower levels
of project management in no way guarantees success on higher
levels. Likewise, failure on lower levels does not guarantee failure
on higher levels. There is, however, an implication that success
on lower levels contributes in some way to success on higher
levels. Failure on lower levels may make success on higher levels
more difficult, yet not impossible.
What is important is that an actual deliverable is created that
can be used to eventually attempt to achieve strategic success
through strategic alignment. In such a way, the organisation can
attempt to snatch victory from the jaws of defeat, and not vice
versa.
32
Chapter 3
Chapter 3
Complexity of
information system
projects
Complexity is a concept which is now more prevalent than
ever (Derbyshire 2016; Vidal & Marle 2008). Geraldi (2008:4)
proclaims that ‘mastering complexity is not a new challenge
but an old challenge that is being increasingly recognized
and accepted.’ Project management literature traditionally
emphasise the success criteria and success factors that are
necessary to understand project performance (Belassi & Tukel
1996; Cooke-Davies 2002; Ika 2009; Pinto & Slevin 1987). Project
management research has evolved over the years to include
the concept of project complexity (Ahern, Leavy & Byrne 2014;
Baccarini 1996; Cooke-Davies et al. 2007). The increased focus
on project complexity is the result of attempts to address
the fluctuating performance of various projects regardless
of industry and type. This chapter aims to elaborate on the
concept of project complexity and constructs which constitute
project complexity.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Complexity of information
systems projects’, in The symbiosis between information system project complexity and
information system project success, pp. 33–61, AOSIS, Cape Town. https://doi.org/10.4102/
aosis.2017.itpsc45.03
33
Complexity of information system projects
The concept of project complexity
Project complexity involves identifying and understanding the
various intricacies embedded in a project. Baccarini (1996:201)
introduced project complexity within the context of construction
projects and argued that project management is ‘associated with
management of complexity.’ The research of Baccarini (1996)
subsequently resulted in the development of a conceptual model
of project complexity. Similarly, Xia and Lee (2004) applied the
concept of project complexity to IS projects and produced a
conceptual model for IS project complexity. Similar literature
works have developed models for project complexity to enlighten
how projects are understood and perceived. Four key models
are identified and discussed in the sections that follow.
omplexity model for new development
C
products
New product development (NPD) projects are commonplace in
many industries but suffer poor performance with regard to time
and cost (Kim & Wilemon 2003, 2009). Kim and Wilemon (2003)
investigated these projects and developed a complexity model
for NDP projects. They argue that NDP projects consist of several
functions and technologies which add to the level of complexity.
Furthermore, the level of complexity faced by functional groups
varies during projects which influences the ‘complexity curve’ of
a project (Kim & Wilemon 2003:18). Kim and Wilemon (2003)
discovered the following sources of complexity:
•• Technological complexities: This source focuses on challenges
with tasks and uncertainties around technology or a
technological approach. Component integration and
technological newness underpin the challenges and
uncertainties. Component integration addresses the complexity
of integrating the various technological parts, systems and
subsystems at the software and hardware level. The aim is to
integrate all components correctly and ensure the system
34
Chapter 3
•
•
•
•
operates effectively. Alternatively, technological newness
looks at how new technology can be used to solve technological
issues. If new technology is not understood, the implementation
of such technology could be detrimental. This applies to the
novel use of existing technology and the introduction of
cutting edge technology. Introducing new technology also
introduces other complexities such as the requirement of new
skills and resources for effective exploitation.
Environmental complexities: The markets in which
organisations and product developers operate are dynamic as
they follow a rapid pace and are unpredictable at the best of
times. These external complexities require organisations to
process data and information more efficiently to remain
competitive and relevant in their industries. It is therefore of
paramount importance to understand market size and growth,
market variability (e.g. regulatory changes), challenges in
predicting competitors and weakness in adapting to market
change.
Development complexities: Complications and complexity
around the research and development processes are the core
of development complexities. Factors underlying research
and development process complexities include, integration of
multiple research decisions, predicting effort, money and time
required for new product development, component
integration, evaluating process requirements for development,
identifying and obtaining quality suppliers and management
of supply chain relationships.
Marketing complexities: Introducing products into new,
untapped markets requires organisations to apply new and
novel marketing skills to penetrate the market. This often
involves conducting intense market and consumer tests. Risk
appetite is an indicator of how organisations will approach
entering a new market. Multiple considerations must be taken
into account such as customer education regarding the
product, introducing new distribution channels, understanding
and managing the needs of a new market, establishing pricing
policies, developing advertising campaigns, user adaptation
and capability level as well as incompatible technologies.
Organisational complexities: The organisational structure
plays a defining role in rolling out NPDs. NPDs require interaction
35
Complexity of information system projects
between multiple business units, departments and employees
which increases the level of complexity. Education and
communication strategies must be thought out as these will
ease the management of organisational complexity.
Furthermore, effective knowledge management and transfer
must exist within the organisation as this enables the application
of new tools, techniques and technologies. Another important
aspect to organisational complexity is that of forming and
managing project teams which include multiple specialists.
Team dynamics such as cultural differences, geographical
location and competency must also be taken into account.
• Intra-organisational complexities: These complexities arise
when organisations partner to achieve a common goal and
pursue NPD projects. The original notion is that collaboration
will not only mitigate other complexity areas but, in turn,
generate other new complexities. Similar to organisational
complexities, intra-organisational complexities consider
aspects such as degree of formality and/or informality,
dependency issues, communication and relationship
management challenges, measuring a collaborator’s
contribution and distributing outcomes equitably.
ovelty, Technology, Complexity and
N
Pace model
Shenhar et al. (2016:68) developed the ‘Diamond of Innovation’
model as a means to tackle project complexity. The model is
also referred to as the Novelty, Technology, Complexity and
Pace (NTCP) model (Frank, Sadeh & Ashkenasi 2011). The model
focuses on project management style selection by assessing the
four dimensions of NTCP. The four dimensions are defined as
follows (Frank et al. 2011):
•• Novelty: The newness of the product is the focus of this
dimension. Three subdomains underpin the novelty dimension,
(1) derivative, (2) platform and (3) breakthrough. Derivative
projects have minor improvements over other products, while a
new generation of products is developed through platform
36
Chapter 3
projects. Innovation projects produce unique and niche products
which are significantly differentiated in the marketplace.
• Technology: Technology and uncertainty are inseparably
linked in this dimension as the use of technology introduces
varying levels of uncertainty. The aim is to reduce the level of
uncertainty by effectively managing the technology employed
in a project. Four types of technological projects exist, (1) low
tech, (2) medium tech, (3) high tech and (4) super high tech.
The more sophisticated the project, the higher the level of
uncertainty and complexity. Alternatively, uncertainty also
determines, amongst other things, duration and scheduling of
tasks and activities, articulating and defining product
requirements, planning precision and risk mitigation strategies.
• Complexity: This dimension specifically looks at product
scope and the interdependencies between various project
components. Complexity directly influences the level of
formality by which the project will be managed as well as the
processes employed.
• Pace: Pace stresses the importance of time goals during a
project as this will influence the project structure and the level
of management attention. There are four apparent levels of
timed goals, (1) regular, (2) fast, (3) time-critical and (4) blitz.
They follow a progressive scale on haste and importance.
Project Complexity Model
The Project Complexity Model (PCM) was developed to
capture the various dimensions of project complexity (Hass
2009). The aim of the PCM is to provide a framework to identify
and analyse complexity elements of a project and facilitate
decision making amongst the project team. Hass (2009) argues
that specific project management tools, methods and approaches
will be determined by which dimensions apply to the project.
The complexity dimensions within PCM are as follows:
•• Strategic importance, political implications and multiple
stakeholders: It is clear there are three subdomains within this
dimension. Strategic importance is associated with the level of
executive support and impact on the mission statement set out
37
Complexity of information system projects
within the organisation’s strategy. Political implications relate
to the internal political landscape of the organisation. Political
issues are often bureaucratic issues and red tape which hinder
or inhibit the project from being performed as initially planned.
If these issues are visible at all levels of management, the project
becomes increasingly complex to manage. Stakeholders play
an important role during projects and the higher the number of
them, the higher the level of project complexity. Multiple
stakeholder groups introduce communication and coordination
challenges as well as conflicting expectations.
• Level of organisational change: The dimension looks at how
the project influences and contributes to organisational
change. Less complex projects have minimal influences such
as impacting one department, business process or IS. Highly
complex projects have widespread influences when the entire
organisation is impacted including internal business units,
multiple business processes, external joint ventures and
information systems. Inevitably, the organisation has to
transform as a result of a highly complex project.
• Level of commercial change: Commercial change pertains to
how the organisation adapts and changes the way they interact
within their industry, including activities such as advertising,
marketing and collaboration. The level of project complexity
directly influences how the organisation implements commercial
change.
• Risks, dependencies and external constraints: Risk increases as
the level of complexity increases. High risk projects carry
increased risk with regard to the above-mentioned dimensions.
Projects are always influenced by internal and external factors.
Dependencies assess the relationship between the various
factors as well as the impact they have on one another. Project
integration efforts are also associated with dependencies as
challenging integrations are often caused by large-scale projects
where multiple elements must be integrated to realise the
project’s goals. External constraints relate to regulatory
requirements within an industry or sector. Operating within a
familiar regulatory environment implies less complexity, whereas
highly regulated environments introduce multiple complexities
when embarking on a new, novel project such as NPDs.
38
Chapter 3
• Level of IT complexity: Information technology is a powerful
tool to implement and be used in projects. This dimension
determines what technology is used for any project type.
Similar to the NPD model, existing and understood technologies
traditionally lead to less complex projects. While innovation
may be the key, the usage of unproven and immature
technology creates complexity where specialist skill sets are
required from external vendors.
I nformation systems development
projects complexity model
The previous models have approached project complexity at a
generic level. The information system development project (ISDP)
complexity model was specifically developed for IS projects as
they ‘are inherently complex because they deal not only with
technological issues but with organizational factors largely
beyond the project team’s control’ (Xia & Lee 2004:70). Xia and
Lee (2004) dissect ISDP complexity into four components:
•• Structural organisational complexity: A number of elements
exist within this component. The level of project manager
control over resources is the most important element as lack of
control implies that the project is driven by other individuals
who are not actively and continuously involved in the project.
User support is the second element. IS projects preferably need
continuous user support and feedback to ensure the output is
a solution which the users need. Insufficient staffing is the third
element identified for structural organisational complexity. The
project cannot meet simple goals such as time and cost if
insufficient staff exists. The fourth element focuses on the
specialised staff and skills required during IS projects. A
deficiency of such staff will have detrimental effects on all IS
project types. The final element, insufficient top management
support, assesses how much support is garnered from senior
management, such as the project sponsor. IS projects cannot
be correctly aligned to organisational strategy if top
management support is lacklustre or non-existent.
39
Complexity of information system projects
• Structural IT complexity: Emphasis is placed on more technical
elements within structural IT complexity. Firstly, the
involvement of multiple user units influences this complexity
component as the different users will have different
perspectives and needs. Cross-functional teams are an
inevitable prerequisite for IS projects. The second element
assesses what level of cross-functionality is apparent as
various internal and external team members are required to
perform the project. Multiple software environments are the
next element within the structural IT complexity component.
IS projects often span various software environments that
further influence how the project is developed and installed.
The next element focuses on multiple technology platforms as
IS projects use a wide range of technologies to realise the
project’s goal. The inclusion of multiple technologies implies
that knowledge and skill are required to implement the
technologies effectively. This also directly relates to the next
element of integration with other systems as compatibility of
technology platforms and software environment come to the
fore. Enterprise-wide IS projects, for example, require full
integration across all systems and platforms to ensure the
users’ needs are met. The final element addresses the
complexity of multiple contractors and vendors. Outsourced
interventions during IS projects are commonplace as the
contractors and vendors assist with the implementation of the
project. Communication and collaboration must be effectively
managed to ensure the project delivers as initially proposed.
• Dynamic organisational complexity: This complexity component
places emphasis on pattern and rate of change during ISDPs.
Change in business processes is the first area of assessment as
IS projects introduce new ways of performing business tasks
and thus re-engineer business processes. Frequency of
information change must be managed as the users’ information
needs change rapidly during IS projects. Patterns regarding
information change must be identified and understood to ensure
the correct information is relayed to users at all times. Similar to
changes in business processes, how the processes are changed
from a user’s perspective is important to understand given that
they are the ones most likely to use the system for day-to-day
activities. Certain IS projects also change the structure of the
40
Chapter 3
organisation itself through the change and/or introduction of
new business processes and functions. Alternatively, a different
view is how a constantly changing organisational structure
influences the project itself. Organisations which rapidly change
structure during an IS project bring about added complexities
to the execution of the project.
• Dynamic IT complexity: The IT infrastructure changes
throughout its lifetime in an organisation. IT infrastructures
can change rapidly given the rapid rate of development within
IT. Constant changes in infrastructure add technical
complexities to IS projects as it becomes difficult to make
decisions when technological uncertainty arises. Furthermore,
there must be careful cognisance of the IT architecture as this
often dictates and influences structural IT complexities.
Software development is a high-paced environment with rapid
movement. Programming languages and tools are constantly
evolving to enhance IS functionality. Rapid change in languages
and tools must be considered at all times as these influence
how the project is executed, implemented and tested.
The above-mentioned project complexity models provide an
overview of project complexity and its subsequent components.
The following section takes an in-depth look at what exactly
constitutes project complexity and applies it to IS projects.
Constituents of project complexity
There are various views on project complexity and no clear
definition or understanding of what exactly constitutes this
phenomenon. This section goes beyond the project complexity
models and analyses in depth how multiple publications
conceptualise project complexity. Textual analysis was performed
through content analysis to identify the underlying components
of project complexity (Flick 2014; Martens & Carvalho in press;
Pade, Mallinson & Sewry 2008). The following research protocol
was applied when conducting the content analysis (Schön,
Thomaschewski & Escalona 2017). Key concepts were first
identified and articulated to develop search terms, for example
41
Complexity of information system projects
‘project complexity, project management complexity, complex
project management.’ Six databases were targeted as they were
identified as the primary databases which cover the key concepts.
Forward and backward sampling were used to enhance content
availability. Forward snowballing searches literature which has
cited the literature in question, while backward snowballing
searches the reference list for literature (Badampudi, Wohlin &
Petersen 2015; Jalali & Wohlin 2012; Schön et al. 2017). The final
step involved manual examination of literature sources to ensure
the concepts were well represented and articulated (Asher 2013;
Dube & Marnewick 2016; Schön et al. 2017).
Five underlying components were identified from the content
analysis, (1) organisational complexity, (2) technical complexity,
(3) environmental complexity, (4) uncertainty and (5) dynamics
(Baccarini 1996; Bakhshi, Ireland & Gorod 2016; Bosch-Rekveldt
et al. 2011; Dunović, Radujković & Škreb 2014; Floricel, Michela
& Piperca 2016; Geraldi, Maylor & Williams 2011; Remington &
Pollack 2007; Senescu, Aranda-Mena & Haymaker 2013; Vidal &
Marle 2008; Williams 1999). An overview of project complexity
components is illustrated in Figure 3.1. Each component
contributes to the level of project complexity to some degree.
The identification of the components is, however, only the first
step as more investigation is required to illuminate what exactly
these components consist of. The content analysis revealed that
each component consists of various elements which, in turn,
consist of various features. The following section delves deeper
into each component and their applicable elements and features.
Organisational complexity
Projects are generally seen as ‘temporary endeavors’ (Schwalbe
2013:4) within an isolated context, but this is far from reality as
they have a greater role within the organisational context. The
organisational context implies that all projects are influenced by
organisational aspects which are rarely taken into account during
all projects and especially IS projects. This section presents the
42
Chapter 3
Organisational
complexity
Technical
complexity
Dynamics
Project
complexity
Uncertainty
Environmental
complexity
FIGURE 3.1: Overview of the components of project complexity (derived from content
analysis).
multiple elements and features which contribute to project
complexity:
1. The first element of organisational complexity centres on
vertical
differentiation
(Baccarini
1996).
Vertical
differentiation deals with the formal structure of the
organisation, that is, whether the organisation has, amongst
others, a functional, matrix or flat structure. Each structure
has varying views on hierarchy as a functional structure has
strict levels of command, whereas a flat structure has no
43
Complexity of information system projects
levels of command effectively (Hobday 2000). The varying
structures influence project execution particularly as
communication and collaboration is different depending on
the structure (Geraldi et al. 2011).
2. Horizontal differentiation is the second element within
organisational complexity (Baccarini 1996). Two features form
the foundation of this element, that is organisational units and
task structure. Regardless of structure, each organisation has
organisational units which serve a particular purpose. The
number of units varies in each organisation and must therefore
be taken into account from a project complexity perspective
(Dunović et al. 2014). Task structure places focus on how
project tasks are divided and distributed to the relevant
responsible parties (Lu et al. 2015). This is particularly
important during the planning stage of a project, and thus
particular attention should be paid to defining tasks as best as
possible. Tasks are, however, not set in stone and are prone to
change during the project.
3. Organisational complexity’s third element is that of size, which
consists of multiple features:
•• Project duration: This feature relates to the constraint
of time (Bosch-Rekveldt et al. 2011). Time is commonly
used as a criterion for determining project success. Its
representation within project complexity is arguably
less vital given the sheer number of other complexity
elements and features to consider. Nevertheless, the
inclusion of duration is important as all projects have a
time goal in which they want to be operational. With
regard to IS projects, time is an important feature to
consider as these projects are launched to achieve or
maintain competitive advantage.
• Project method and tool variety: The project
management landscape is awash with various methods
and tools. Information system projects, for example, are
more commonly adopting the philosophy of Agile as a
new approach to deliver projects (Chan & Thong 2009).
The Agile landscape, however, is not simple as there
are multiple methods which can be chosen and used, for
example scrum, extreme programming, rapid application
44
Chapter 3
•
•
•
•
•
development and dynamic systems development
methods to name a few. Selecting from multiple methods
can become difficult especially when there is a lack of
understanding and knowledge amongst the project team
regarding the details of the method. Methods cannot be
adopted based on ‘buzzword’ status as this negates any
potential benefit from adopting the method(s).
Capital expenditure: This feature relates to the
constraint of cost (Bosch-Rekveldt et al. 2011). Significant
sums of money are spent on IS projects, which implies
their strategic importance to many organisations
(Joseph & Marnewick 2014). Cost is therefore an
important feature as failed projects do occur at the cost
of millions and reflect badly on the implementation of
other IS projects.
Work hours: Many hours are spent on projects of all
types to realise the project and business goals (Thomas
& Mengel 2008). The number of work hours is determined
by the scale of the project as well as the task structure.
Work hours should be meticulously managed during
large-scale IS projects particularly as there are a
multitude of interdependencies. Moreover, the number
of work hours is heavily influenced by IS projects which
span geographical regions.
Project team: The size of a project team directly
influences project complexity (Bosch-Rekveldt et al.
2011). Large teams include individuals from multiple
departments, thus introducing heightened levels of
complexity. The management of large teams can become
cumbersome for project managers as communication
and collaboration breakdowns are highly likely.
Site area: The physical size of the project site(s) is
important to identify as this will influence certain aspects
of the project (Bosch-Rekveldt et al. 2011). While the
initial plans dictate project activities amongst other
things, careful attention must be paid to how the physical
attributes of the site will influence these activities.
Number of locations: As mentioned previously,
geographically dispersed projects are commonplace
45
Complexity of information system projects
within multinational organisations particularly. These
dispersed projects affect project complexities such as
logistics where travel and access must be considered
when executing the project (Padalkar & Gopinath 2016).
IS projects often implement systems which span
offices across the globe and thus should be fully
integrated. Full integration, therefore, requires a robust
understanding of the locations where the system must
function.
4. The element of resources emphasises tangible and intangible
resources required for any given project. The following
features must be considered for the fourth element of
organisational complexity:
•• Project drive: Strategic goals underpin the need and
execution of IS projects. Project drive, therefore, pertains
to the level of strategic importance and support required
for a project (Milis & Mercken 2002). Inadequate support
implies that the project will not be aligned to the overall
goals of the organisation and thus not deliver the
benefits as initially stipulated. The drive of the project
must therefore be sound and understood by all parties
involved to ensure it realises the greater strategic goal.
• Resources and skills availability: Different projects
require different skills and resources even if the projects
seem similar on paper (Baccarini 1996). Specific
resources with regard to raw materials must be clearly
identified and acquired to implement the project
correctly. Project complexity is aggravated when
projects such as IS projects require very specialised
skills which need to be sourced externally. External
vendors are often brought in to provide these skills,
which add other complexity layers such as project team
composition, capital expenditure and work hours.
• Experience with parties involved: Stakeholder
management and its importance are documented in
project management standards such as the PMBOK®
Guide (Project Management Institute 2013). Experience
with involved stakeholders and parties creates somewhat
of a more predictable landscape during a project as
46
Chapter 3
•
•
•
•
there is a better understanding of the parties involved
(Bosch-Rekveldt et al. 2011). Unknown parties require
extra effort from the project manager and team as they
will have to engage more to ensure they perform as
required.
Health, safety, security and environment (HSSE)
awareness: HSSE is traditionally associated with
construction projects and not IS projects. HSSE should,
however, be applied to all projects as there are national
regulations overseeing the implementation of HSSE
(Bosch-Rekveldt et al. 2011). Project managers in
particular should be aware of all HSSE concerns in a
project as this will mitigate any possible litigation arising
from regulatory bodies.
Interfaces between disciplines: Cross-disciplinary
integration is inevitable in projects as specialists from
various fields are required to execute certain tasks
(Baccarini 1996). The interfaces or interactions between
the various disciplines must be identified and managed
accordingly as this influences other areas such as skills
availability, works hours, capital expenditure and project
duration, to name a few. The more disciplines required
for the project, the higher the level of project complexity.
Financial resources: Projects cannot be executed
without sufficient availability of financial resources
(Killen & Kjaer 2012). Financial resources, however,
should be managed in a sustainable manner to ensure
they are distributed correctly and not squandered on
ineffective tasks and resources. As mentioned before, IS
projects require significant expenditure but do not
always translate these financial resources into
organisational benefits.
Contract types: Resources are procured from various
suppliers, whether internal or external. Regardless,
contracts are negotiated and signed to ensure the required
resources are available for a project. Contractual
agreements and arrangements often become intricate and
complex and thus add to the complexity of a project
(Bosch-Rekveldt et al. 2011).
47
Complexity of information system projects
5. Intricacies relating to the project team are the fifth element
within the organisational complexity and consist of the
following features:
•• Different nationalities: Projects do not need to be
geographically dispersed to have the complexity of
different nationalities working on the project. The key to
different nationalities is that of understanding national
cultures and ensuring that they are understood and not
offended (Geraldi et al. 2011). Productive project teams
understand their boundaries and limitations when
working with different nationalities. Furthermore, it is the
responsibility of the project manager to manage these
cultural relations and mitigate any possible conflicts.
• Different languages: Different nationalities also
introduce difficulties associated with language (BoschRekveldt et al. 2011). Language barriers imply that team
members and stakeholders cannot understand one
another enough to effectively execute the project.
Language issues also arise when the main language
used for a project is not the first language for some
parties involved. It is therefore important that this social
aspect is identified early on and possibly before the
project initiates as this will ensure the project does not
experience difficulties during the project.
• Joint-venture cooperation: Many projects are executed
as a joint venture between two or more organisations
(Geraldi & Adlbrecht 2007). The roles and responsibilities
of each organisation must be clearly articulated before
project initiation and planning as they will dictate the
way forward for the project. Organisations could
perform the same tasks differently as they have varying
management styles and structures. Cooperation
between the parties involved should therefore be
documented and made transparent to all to ensure a
common understanding between all parties.
• Office hour overlaps: Overlapping of office hours
primarily occurs in projects which are executed in
multiple time zones. The project manager and team
48
Chapter 3
must be cognisant that certain tasks and activities can
only occur when there is office hour overlap between
time zones (Geraldi et al. 2011). On the other hand,
there could be instances where overlapping hours
could be minimal thus creating a heightened level of
complexity. It is therefore imperative that there is a clear
understanding amongst those operating within different
hours to ensure effective communication occurs during
the project.
6. The sixth element focuses on two features of trust, that is trust
within the project team and in the contractor (Bosch-Rekveldt
et al. 2011). The project team must operate as efficiently as
possible to ensure they deliver what is expected by the business.
The team would thus work best when trust is apparent between
all those involved (Geraldi & Adlbrecht 2007). Moreover, this
relates to the feature of experience with involved parties as
more experiences can arguably translate to increased trust to
perform certain tasks and activities. Similarly, trust must exist
with the contractor or outside vendor (Geraldi et al. 2011).
Trust in a contractor does not only entail trusting that they
play their part but, more importantly, that they provide the
required skills and knowledge needed for executing the
project. Trust is a social paradigm which is more focused on
soft aspects such as people management than on hard aspects
such as technical requirements management.
7. Risk is the seventh element within organisational complexity
where emphasis is placed on organisational risk specifically
(Bosch-Rekveldt et al. 2011). Thamhain (2013) asserts that there
are four categories of risk, (1) no impact on project performance,
(2) actual impact on project tasks and subsystems, (3) actual
impact on project performance and (4) actual impact on project
and enterprise performance. Category four of risk therefore
implies that the entire organisational performance is at
stake if project risk is not addressed. Risk can, however, be
mitigated through continuous stakeholder communication and
collaboration (Floricel et al. 2016).
8. Projects are fraught with interdependencies which further
complicate matters. Interdependencies are thus the eighth and
49
Complexity of information system projects
final element of organisational complexity. Interdependencies
consist of the following features:
•• Environmental dependencies: These span the internal
and external operational environment in which the
organisation operates (Vidal & Marle 2008). The
implication is that both environments must be surveyed
and understood as best as possible to ensure the project
is not negatively affected by underestimating its
environmental dependencies.
• Resource sharing: Organisations execute multiple
projects at once and thus share resources between them
(Vidal, Marle & Bocquet 2011). Furthermore, the same
resources are often shared with day-to-day activities
which further escalate project complexity. Resources are
not infinite and must be managed accordingly between
all relevant parties. It is predominantly the project
manager’s responsibility to ensure that required resources
are available when needed and to liaise with other project
managers for effective resource management.
• Schedule dependencies: Similar to resource sharing,
schedule dependencies require the same attention as
certain project activities, and tasks are conducted
sequentially while other tasks are run in parallel. A lack
of schedule dependency understanding inevitably
introduces increased complexity which could lead to
chaos within a project and subsequent project failure
(Baccarini 1996).
• Interconnectivity and feedback loops in task and project
networks: Communication is at the heart of this feature
as the emphasis is on feedback loops between the parties
involved (Vidal et al. 2011). There must be a clear level of
transparency amongst all stakeholders as this enlightens
and reassures what tasks have been performed as well as
the status of the task.
• Dependencies between actors: All project stakeholders
have some form of dependency on one another (Padalkar
& Gopinath 2016). Any project which is not cognisant of
that will perform poorly and not as intended. It is,
however, important that there are not an exorbitant
50
Chapter 3
•
•
•
•
•
number of communication and collaboration channels
and platforms as this will compromise and distort any
work being done.
Information systems dependencies: Various information
systems are used as a source of information during a
project (Baccarini 1996). The relationship between these
systems is important as not all systems provide the
same functionality. Furthermore, the technical nature of
information systems is important to understand to
ensure the most benefit is gained from them. There is
arguably a link between this element and skills availability
as the use of these information systems often requires
specialised skills to extract the maximum benefit.
Objective dependencies: Each project has goals which
are linked to greater strategic goals. The relationship
between them is important as there should be clear
and strict alignment between the project and strategic
goals (Vidal et al. 2011). Furthermore, the relationship
between the various project goals must be clearly
articulated as they work in tandem to realise strategic
goals.
Process interdependencies: Project management is a
process-based activity where each process serves a
function and feeds into another. Alternatively, projects
operate within daily business processes, and thus the
relationship between project and business processes
must be identified and managed accordingly to reduce
increased project complexity (Padalkar & Gopinath
2016).
Stakeholder interrelations: Both internal and external
stakeholders interact during a project’s lifecycle. These
interactions and interrelations directly influence the
level of project complexity as information and resources
are shared between these stakeholders to realise the
project’s goal (Baccarini 1996).
Team cooperation and communication: There is constant
reference to communication and cooperation in multiple
project complexity features, especially with regard to the
project team (Geraldi & Adlbrecht 2007). Internal feedback
51
Complexity of information system projects
loops amongst team members is critical to ensure the
project delivers as expected and project complexity is
managed effectively.
Technical complexity
Technical complexity originated from technological complexity
where the emphasis was on technology and its intricacies
(Baccarini 1996; Brown 2008). Over time, however, technical
complexity expanded to include elements and features which
place more emphasis on detailed aspects of a project (BoschRekveldt et al. 2011; Floricel et al. 2016). The following elements
constitute technical complexity:
1. Differentiation regarding inputs and outputs is the first
element of technical complexity (Green 2004). Project
processes and activities have various inputs and outputs
during the project’s lifecycle. The number and diversity of
inputs and outputs must be considered under the greater
umbrella of project complexity (Baccarini 1996). A large
number of inputs and outputs implies that there are multiple
interconnected parts which must be managed accordingly in
a process-driven environment such as project management.
On the other hand, the diversity and scale of the inputs and
outputs play a role in the level of importance of each
overarching process in which they operate. Project complexity
is therefore influenced by the number and diversity of inputs
and outputs as they underpin the project management
process itself.
2. The second element of technical complexity focuses on
project goals (Bosch-Rekveldt et al. 2011). Project goals
have been referred to in the project drive and objective
dependencies features in organisational complexity and,
again, in technical complexity which reiterates the
importance of understanding the project goal dynamic. The
first feature within project goals is that of the number of
goals. The more goals there are to achieve the more complex
the project becomes (Gällstedt 2003). This leads directly to
52
Chapter 3
the second feature, goal alignment, where the goals should
be aligned to one another and the strategic goals (Geraldi &
Adlbrecht 2007). Project goals which contradict one another
imply that the project is destined for failure as there is no
common ground or vision on what the project must achieve.
Goal alignment subsequently leads to the third feature of
goal clarity. Goals which are understood and transparent
to all the stakeholders are the key to the successful delivery
of a project (Shenhar, Levy & Dvir 1997). Conflict and
contradicting goals should be avoided at all costs as
previously mentioned.
3. Scope is the third element and focuses on scale of scope and
quality of requirements (Bosch-Rekveldt et al. 2011; Floricel
et al. 2016). The requirements dictate what a project should
achieve once they are completed. The scale of scope therefore
refers to what requirements must be successfully implemented
for the project to deliver business benefits (Vidal & Marle
2008). On the other hand, the quality of requirements is more
specific as it looks at whether the documented requirements
are well detailed and understood (Floricel et al. 2016). Quality
requirements should be correct, unambiguous, complete,
consistent, prioritised for importance and/or stability, be
verifiable, modifiable and traceable (Marnewick 2013). The
omission of any of these attributes implies that the level of
project complexity will be raised and that the project will not
deliver as initially planned.
4. Technical complexities relating to project tasks is the fourth
element to consider. Firstly, the number of tasks plays an
influential role as projects with many interconnected tasks
are more cumbersome to manage, as discussed in the
interdependencies element of organisational complexity
(Heaslip 2015). The number of tasks also relates to the
number of inputs and outputs as certain tasks act as inputs
while others act as outputs. Secondly, the variety of tasks
speaks to the varying difficulty and speciality of tasks as not
all tasks are equal and some are more specialised than others
(Senescu et al. 2013). Thirdly and finally is the feature of
conflicting norms and standards (Bosch-Rekveldt et al.
2011). This feature focuses on the misunderstanding of
53
Complexity of information system projects
organisational standards and procedures other than project
management ones. Although organisations strive to achieve
congruence amongst all standards there are spaces where
this is not the case. It is essential to discuss any conflicting
standards and decide on the best way forward before the
project is adversely affected.
5. Experience within technical complexity refers to technological
experience specifically. Experience with regard to new and
current technology is the focus of this element. New
technology is often punted as performing the same tasks
better and more efficiently, but the problem arises when the
new technology needs to be implemented as part of the
project (Tatikonda & Rosenthal 2000). A barrier to adopting
new technology is that of understanding as the project team
should understand the technology and how it will influence
the entire project if implemented. Experience with technology
is therefore important as the more experienced the team is
with the technology, the more likely they will be able to
implement it correctly (Tatikonda & Rosenthal 2000). Projects
which boldly implement new technology often suffer many
side effects such as integration issues and lacklustre user
acceptance as the technology is not thoroughly investigated
and understood.
6. The final element is that of technical risk where the focus is on
technological risks (Deutsch 1991). Technological risks include,
amongst others, what technology will be used, will the
technology integrate correctly, availability of technology and
whether technology will be obsolete before project completion
(Ahmed 2012:343). Furthermore, the frequency and impact of
these risks must be taken into account to ensure the project is
not adversely affected.
Environmental complexity
Organisations operate within various industries, and the projects
they initiate are influenced by the dynamics of these environments
(Bosch-Rekveldt et al. 2011). This project complexity component
54
Chapter 3
further illustrates that projects are not entirely isolated
endeavours as traditionally believed.
1. The first element focuses on stakeholders specifically and
their intricate role in projects. The stakeholder element
consists of various features:
•• Number of stakeholders: Stakeholder numbers have
a positive relationship with the level of project
complexity, that is, the more stakeholders there are, the
more complex the project becomes (Vidal & Marle
2008). Management of all stakeholders is important to
ensure there is consistent understanding by all the
participants.
• Varying stakeholders’ perspectives: Management of
stakeholders must also include an awareness of varying
perspectives, that is each stakeholder views the project
and its status in a different light (Bosch-Rekveldt et al.
2011). For example, senior management views the
project in a strategic light, while operational staff
assess the project with regard to how it will influence
their daily activities.
• Political influence: This can be viewed from both an
internal and an external perspective (Floricel et al. 2016).
The internal perspective looks at political influence
within the organisation, such as when the project team
is pushed by senior management to implement the
project as soon as possible for strategic goal realisation.
Alternatively, external political influences focus on
politics at the national and international level (Vidal &
Marle 2008). This is often through regulation and
legislation by which the organisation and project must
abide.
• Internal support: Projects must benefit from some
form of internal support for them to be successfully
implemented (Geraldi & Adlbrecht 2007). Senior
management in particular, should be heavily
involved in and continuously support the project
throughout its lifecycle. Lack of support has often
55
Complexity of information system projects
reared its head as a key factor influencing project
failure (Hastie & Wojewoda 2015; Joseph, Erasmus &
Marnewick 2014).
• Required local content: Many nations require
organisations to make use of local content and resources
as a means to ensure the organisation contributes to
economic growth and does not merely exploit national
resources.
2. The second element of environmental complexity centres
on the location of a project. The first feature deals
with interference with an existing site where any possible
interference with the project site is identified and understood
(Bosch-Rekveldt et al. 2011). Once identified and understood,
these interferences can be managed accordingly to avoid
adverse impacts on the project. Weather conditions are the
second feature within the location element. Projects operate
in geographically dispersed regions, and the effect the
weather has on the projects must be analysed beforehand
as weather can have a detrimental effect during project
execution particularly (Sohi et al. 2016). Alongside weather is
the remoteness of the location where some project locations
are isolated from business hubs and thus require special
attention regarding resources and logistics (Nguyen et al.
2015). The final feature focusses on country experience.
Similar to experience with involved parties in organisational
complexity, organisations which initiate projects in regions of
which they have experience are more likely to have fewer
hurdles than when introducing a project in a completely new
region (Floricel et al. 2016).
3. Market condition is the third element. A more specific
political influence of internal strategic pressure is the first
feature within market conditions (Bosch-Rekveldt et al.
2011). The project manager and team are prone to increased
pressure especially when the project in question is the
primary driver of a new strategic direction in the organisation.
The stability of the project environment also plays a role and
is the second feature to consider. Project environment
stability is primarily determined by the organisation’s
56
Chapter 3
stability regarding operations (Geraldi et al. 2011).
Organisations which are unstable and barely functioning
imply that the project has a minimal chance of being
executed correctly. The final feature is that of competition
level with regard to the organisation’s competitors (Senescu
et al. 2013). Increased competition requires an organisation
to act swiftly by using projects to push out products and
services quickly to ensure they remain competitive in their
relevant industry.
4. Environmental risk is the final element in environmental
complexity. Environmental risk focusses on man-made and
natural disaster risks (Floricel et al. 2016; Thomé et al. 2016).
On the other hand, risks associated with the elements and
features of environmental complexity should also be
considered within this element.
Uncertainty
Uncertainty is a concept centred on doubt with regard to the
various elements and features of project complexity (Williams
1999). The question, however, is how any level of doubt will
be managed to ensure any negative effect is mitigated during
a project. The first step is to identify the main elements of
uncertainty as this will assist doubt management. Various
elements constitute uncertainty in the project complexity
context:
1. Uncertainty regarding the traditional project management
triple constraint should be evaluated (Bosch-Rekveldt et al.
2011; Geraldi et al. 2011; Thomé et al. 2016). Uncertainty
about scope is arguably embedded in the scope element of
technical complexity as much emphasis is placed on project
requirements. Furthermore, scope creep and poor scope
management are commonplace during projects where
strategic pressure coerces the project team to take on a
project which is unfeasible or unrealistic. The same could be
argued for the next two features of cost and time uncertainty
where unrealistic budget and schedule expectations are set
57
Complexity of information system projects
for the project which are not met. Alternatively, cost and time
uncertainty also comes to the fore when there are outside
influences which were not expected such as Brexit (Dhingra &
Sampson 2016).
2. The second element of uncertainty concerns project
activities. Multiple project methods are available for
managing projects and uncertainty regarding these methods
inevitably arise (Vidal & Marle 2008). As mentioned
previously, this is particularly the case when adopting new
methods. On the other hand, it cannot be assumed that
all parties understand the method being used when
introducing new stakeholders and/or project team members
during a project. Method uncertainty leads to the next
feature of task uncertainty as project tasks are directly
influenced by the method being used (Maylor, Vidgen &
Carver 2008). Task and method uncertainty can be mitigated
by having adequate support structures and platforms in
place to which stakeholders and project team members can
refer.
3. Goal uncertainty is the third element which focuses
specifically on project goals and objectives (Geraldi et al.
2011; Maylor et al. 2008). This speaks to goal alignment and
clarity in technical complexity as uncertainty can be alleviated
by ensuring these two features are correctly addressed. The
core idea is that all parties are on the same page throughout
the project. Furthermore, effective communication and
collaboration will underpin transparent understanding
amongst all the participants.
4. Technological uncertainty is very specific and speaks to all
technological elements and features discussed previously.
Technological maturity and novelty are the two features
which underpin this uncertainty element. Whitney and
Daniels (2013) assert that a key feature of complex IS projects
is that of new technology which has not yet been fully
developed and tested, that is immature and novel technology.
Many projects, however, are deemed failures as the immature
and novel technology was not implemented correctly and
thus did not deliver expected business benefits. It is therefore
essential that novel and immature technology is understood
58
Chapter 3
and that there is a balance between new and old technology
for projects pursuing this route (Tatikonda & Rosenthal
2000).
5. Stakeholder uncertainty is the fifth element and refers to
undisclosed participants and competency. The overarching
nature of projects such as IS projects requires involvement
from multiple departments and business units. This could
arise when certain participants are not identified and their
presence is not disclosed and disclosed until later in the
project (Maylor et al. 2008). Omitting participants could lead
to incorrect or incomplete information being sourced. The
project manager must therefore continuously check if all the
required participants have been disclosed during the early
stages of the project. Competency is also a key feature which
is underestimated (Maylor et al. 2008). Many projects go
ahead on the assumption that all stakeholders have the
knowledge required for executing the project successfully.
This may not necessarily be the case, however, as key
individuals could be left out as mentioned previously.
Furthermore, competency research argues that although IS
project stakeholders deem themselves competent, the
mediocre performance of IS projects questions that notion
(Marnewick, Erasmus & Joseph 2016). If there are questions
around competency, support structures and materials must
be in place to mitigate any negative influences.
6. Information uncertainty is the last element to consider and
the focus is on incomplete information. Accurate and
complete information is an undeniable prerequisite for all
projects as this ensures the project is driven correctly (Vidal,
Marle & Bocquet 2007). Incomplete information can arise in
many forms such as, amongst others, undisclosed participants,
conflicting norms and standards, unclear goals, cooperation
and communication as well as trust.
Dynamics
Dynamics concerning project complexity refer to the element of
change management specifically. The change process is the first
59
Complexity of information system projects
feature to consider as it should be as robust and adaptable as
possible (Whyte, Stasis & Lindkvist 2016). Poorly defined change
processes imply that changes are not instituted correctly or
managed effectively thus negating any possible improvements
to a project. The number of changes is also important as projects
which exhibit multiple changes at once imply the project was
poorly planned from the outset (Geraldi & Adlbrecht 2007). A
combination of poorly-defined change processes and a high
number of changes points to an inevitable outcome for a project.
Changes are initiated for various reasons which influence the
scope of changes. For example, some changes might be minor
while others are widespread and more important (Whyte et al.
2016). Frequent changes are also a red flag during projects as
the implication is that there was poor planning and/or previous
changes were not carried out correctly thus resulting in high
levels of reworking (Muller, Geraldi & Turner 2012). Along with
the above-mentioned change management dynamics is that of
impact. The impact of changes must be clearly understood and
analysed before implementation as some changes are too risky
to the outcome of the project and should rather be deferred to
future projects or project support activities (Geraldi et al. 2011).
The final feature assesses change over time. Change over time is
the monitoring and controlling of the above-mentioned features
to ensure the project continues in the correct direction (Maylor
et al. 2008).
Conclusion
This chapter revealed that project complexity is ironically
complex to catalogue and understand. Five complexity
constructs were identified based on an extensive literature
review, that is organisational complexity, technical complexity,
environmental complexity, uncertainty and dynamics. Within
each construct there are various elements and features.
A total of 75 features across all constructs were identified
and discussed. Organisational complexity makes up the bulk
60
Chapter 3
of complexity features as this construct has 34 in total. The
remaining four constructs were fairly evenly divided, which
implies that organisational complexity is the one construct that
needs considerable attention.
61
Chapter 4
Insights into
information system
project success
This chapter focuses on project success and how the respondents
perceived project success within their respective environments.
The first section of the chapter focuses on the general information
with regard to the type of respondents and the type of projects
that organisations implement. This analysis provides us with a
general understanding of what the IS project landscape looks like.
The second part of the chapter focuses on project success itself
and how successful IS projects according to the five levels as per
Bannerman and Thorogood (2012) are. Specific attention is given
to the difference between Agile and Waterfall as methodologies
to implement IS projects.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Insights into information
s ystem project success’, in The symbiosis between information system project complexity
and information system project success, pp. 62–80, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.04
62
IT
s
es
in
1.6
2.3
3.4
3.7
4.1
4.4
6.0
6.5
9.6
Pr
oj
an
al
ys
t
m
an
ag
Pr
og
er
ec
ra
tl
m
ea
m
de
e
Po
r
m
an
rt
fo
a
ge
lio
r
m
an
a
A
ge
ss
Pr
r
is
oj
t
Pr
an
ec
oj
t
t
ec
PM
co
ti
or
Ite
m
di
ra
Pr
pl
na
tio
em
oj
to
ec
n
en
r
m
tm
ta
an
tio
an
ag
ag
n
er
m
em
an
en
ag
tc
er
on
su
lta
nt
10.7
13.0
15.9
PM
er
or
ni
O
th
Se
us
B
Pr
oj
ec
tm
an
ag
er
18.7
Chapter 4
FIGURE 4.1: Job description.
General information
The results in Figure 4.1 illustrate that various job titles exist
within the IS project management domain. The majority of
the respondents (31.7%) are either project managers or senior
project managers. The results also highlight that each and every
one of the respondents is involved in IT and specifically within
the discipline of project management.
Figure 4.2 indicates that organisations are involved with
various types of IS projects covering the full spectrum. The
majority of the projects (46%) are concerned with either the
full implementation of IS systems or solutions or the upgrade
of these systems (17%). This highlights that organisations are
permanently in turmoil as they are constantly changing or
upgrading the systems. This places enormous pressure on the IT
division as well as the users of the various systems.
63
Insights into information system project success
Integration,
11%
Customisation,
11%
System implementation
(full), 46%
Infrastructure,
15%
System implementation (upgrade)
17%
FIGURE 4.2: Type of information system projects.
The results in Figure 4.2 also highlight that customisations
and integrations are only about a fifth of the IS projects. It
must be noted that these are specific IS projects focusing on
customisation and integration. There might be customisations
and integrations within the full system implementations as well
as the upgrades.
Customisations and integration make use of various
development methodologies, and this is displayed in Figure 4.3.
The majority of these types of IS projects make use of either
the Agile method (41%) or the more traditional Waterfall method
(31%). A small percentage (8%) are starting to embrace Lean
and DevOps as ways to implement software solutions. A fifth of
IS projects incorporate other methodologies to customise and
integrate software solutions.
A cross-tabulation between the type of project and the
development method resulted in Figure 4.4. An interesting point
of observation is that full systems implementation incorporate
Agile as a method almost three times more than when an upgrade
64
Chapter 4
Other, 20%
Lean, 2%
Agile, 41%
DevOps, 6%
Waterfall, 31%
FIGURE 4.3: Development method.
Agile
System implementation:
upgrade
8%
System implementation:
full
22%
Integration
Infrastructure
2%
5%
2%
DevOps
4%
4%
Customisation
Waterfall
2%
4%
Lean
1%
Other
3%
17%
1% 5%
2%
3%
0%
2%
3%
6%
FIGURE 4.4: Crosstab between type of project and development method.
is performed. This might have to do with the fact that full systems
implementation is more pressured for delivery than upgrading
the system.
The next section focuses on IS project success, and the
discussion is based on the five levels of IS project success where
the first level focuses on the technical processes of an IS project.
65
Insights into information system project success
Project success
This section analyses the success of IS projects based on the
model of Bannerman (2008). Each level is analysed to determine
the level’s success. This analysis is done for the overall results
but also for IS projects that used Agile and Waterfall as a method
within the IS project.
Process success
This level focuses on the various technical and managerial
processes that are important at different times throughout
the project life cycle (Bannerman 2008). Technical processes
in this context refer to conducting the actual work to produce
a deliverable, while managerial processes refer to the oversight of
the afore-mentioned processes. On average, IS projects are 64%
successful in the deployment of either a technical or managerial
process. The detailed breakdown is illustrated in Figure 4.5. The
results indicate that IS project managers actually spend time
and effort on the selection, implementation and integration of
technical and managerial processes. In two-thirds of the instances,
these processes are aligned with the project’s overall processes.
However, two-thirds of IS projects cannot be perceived as
successful as they do not incorporate technical and managerial
processes into the IT project.
The results in Figure 4.5 compare the Agile and Waterfall
methods. Figure 4.6 clearly indicates that IS projects that use
Agile as a method are successful in incorporating technical and
managerial processes. In 88.25% of the instances, technical and
managerial processes are successfully incorporated. In 92%
of the cases, Agile processes are aligned with the project and
organisational strategies.
The results portrayed in Figure 4.6 are in stark contrast to
the results portrayed in Figure 4.5. The results highlight the
underlying factor why IS projects continue to fail. The Waterfall
66
Chapter 4
70%
65%
66%
64%
64%
63%
60%
55%
50%
Alignment
Implemented
Chosen
Integrated
FIGURE 4.5: Process success.
Agile
Chosen
86%
48%
Integrated
87%
45%
Implemented
88%
47%
Alignment
92%
48%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Waterfall
90%
100%
FIGURE 4.6: Process success (Agile vs Waterfall).
67
Insights into information system project success
processes are not successfully managed and in only 47% of the
cases are the processes successfully managed. This is a difference
of 41.25% compared to the Agile processes indicating that Agile
processes are better managed than the Waterfall processes.
The results of the study indicate that Agile as a method
provides an advantage and that the integration, implementation
and alignment of Agile processes are more successful than the
integration, implementation and alignment of Waterfall processes.
The second level of success is based on the project itself, that
is, was the project delivered within the constraints of time, cost
and scope?
Project success
The constraints of time, cost and scope are the original project
constraints (Marnewick & Labuschagne 2012). The IT industry
adopted these constraints from the engineering discipline and IS
projects should also be delivered within these constraints. Most
of the research that focuses on IS project success rates use the
triple constraint as the basis for their analysis.
Figure 4.7 compares the cost and time constraints against the
type of IS projects. In four of the instances, IS projects do cost
more than what was originally budgeted. The only difference is
with integration projects where the actual cost is 133% cheaper
than the budgeted cost. When these types of projects are left
out of the equation, then IS projects are on average 16% more
expensive than originally budgeted. This implies that 16 cents
must be added for every one rand that is budgeted.
The time constraint shows the same kind of tendency as that
of the cost constraint. The results indicate that IS projects, on
average, take almost 2 months longer. The biggest discrepancy
occurs with the implementation of full IS systems. These projects
take 3 months longer than anticipated.
The results do not paint such a bleak picture. Although IS
project managers should strive to deliver the project within
68
Chapter 4
Actual Cost
Orginal Budget
Planned Time
Actual Time
18.00
30%
20%
10%
R 8 865 278.86
R 29 389 832.93
40%
9.37
R 12 102 987.69
12.46
11.51
10.06
0%
14.00
12.00
10.00
6.00
4.00
2.00
pl
(u em
pg en
ra ta
de tio
) n
em
(f en
ul ta
l) ti
o
pl
Im
Im
n
n
ra
tio
te
g
In
C
us
to
m
tr
is
uc
at
tu
io
re
n
0.00
fr
as
In
16.00
8.00
R 8 921 321.34
10.51
50%
12.87
11.32
R 20 751 185.76
60%
11.85
15.29
R 17 685 095.86
70%
13.98
R 43 288 878.07
80%
R 9 567 182.51
R 35 083 112.24
90%
R 18 553 474.98
100%
FIGURE 4.7: Cost and time comparison.
the constraints of time and cost, the deviance is not as bad
as anticipated. IS projects are delivered 3 months later at an
additional cost of 16 cents to a rand.
Table 4.1 presents the comparison between Agile and
Waterfall methods. It is interesting to note that Agile projects are
30% more expensive than the original budget. Waterfall projects
are, on the contrary, 11% cheaper than originally budgeted. When
Agile and Waterfall projects are compared with each other about
time, then Waterfall projects take 18% longer than estimated and
Agile projects take 12% longer than estimated.
The results presented in Table 4.1 convey a mixed message.
According to the literature, Agile projects should be delivered
quicker and cheaper than Waterfall projects but this is not the
case in this instance. This study itself was of a quantitative
69
Insights into information system project success
TABLE 4.1: Cost and time comparison: Agile versus Waterfall.
Cost and time
Agile
Waterfall
Original budget
R 5 526 876.09
R 39 398 302.94
Actual cost
R 7 882 681.12
R 35 396 477.77
Original time
9.60
15.22
Actual time
10.91
18.63
nature and no evidence is uncovered why these discrepancies
exist. It might be useful to conduct interviews with the
various IS project managers to uncover the truth behind these
discrepancies.
The third constraint is the scope of the project. In the context
of a project, scope is defined as the features and functions that
characterise the project’s deliverable (Project Management
Institute 2013). The majority of IS projects deliver on the scope
of the project with 87.5% of these projects delivering on the
scope between 60% and 100% of the time. Figure 4.8 shows the
comparison between Agile and Waterfall projects. There is no
difference between these two methods when it comes to the
delivery of the scope. Agile projects deliver in 87.5% of the cases
between 61% and 100% of the scope in comparison with Waterfall
projects that deliver 89.5% of the scope.
When Agile and Waterfall methodologies are compared with
each other with regard to the triple constraint, then there is not
much difference between the two methods. Project success is
therefore not dependent on the method that was chosen.
The third level of success measures the product itself and
focuses on aspects such as meeting the specifications, meeting
requirements, meeting client and/or user expectations and the
final acceptance of the project deliverable by the user.
Deliverable or product success
The success of the project deliverable or product was measured
around seven criteria as illustrated in Figure 4.9. A weighted
70
Chapter 4
Agile
70
Waterfall
62.3
60
50
40
30
27.2
61
20
26.5
7.4
10
0
1
2.5
3
8.5
< 20%
21%–40%
41%–60%
61%–80%
> 80%
FIGURE 4.8: Scope comparison (Agile vs Waterfall).
average score was calculated for each of the seven criteria.
The results show that the deliverable is only perceived as 68%
successful when success is determined across all seven criteria.
This implies that close to a third of the users are not satisfied with
the project deliverable and that they are actually not using it at all.
The results indicate that business analysts are fairly competent
in determining the product’s specifications (71%) as well as the
users’ requirements (70%). They still cannot determine in 30%
of the instances either the specifications or the requirements.
This has a direct result on the remaining five criteria where the
product is used and accepted in only 68% of the cases. A third
of the users feel that they are not satisfied with the project
deliverable and that their expectations were not met.
71
Insights into information system project success
75%
70%
71%
70%
68%
68%
65%
67%
67%
67%
60%
55%
ns
re
xp
e
at
rs
U
se
se
U
its
ef
en
B
ct
at
io
ie
is
f
lis
re
a
ta
cc
ep
ra
se
U
d
ed
nc
e
d
se
uc
tu
Pr
od
ui
eq
R
Sp
ec
ifi
ca
t
io
re
m
en
ts
ns
50%
FIGURE 4.9: Deliverable success.
The results in Figure 4.10 are also not as promising as anticipated.
On average, Agile projects are only successful 71% of the time in
delivering a product that meets all the criteria. One of the principles
of the Agile Manifesto focuses on involving the users or customers
from the onset. The rationale is that when users or customers are
involved from the onset, then the chances are better that they will
accept the project deliverable and actually use it. This builds onto
the notion that they are involved from the beginning of the project
and should provide accurate requirements and specifications.
The concern highlighted by the results is that a quarter of the
users are not satisfied with the requirements and specifications
of the project deliverable. This means that the Agile principles
are not adhered to and that the project team is not trained in the
various Agile methodologies.
The average product success for Waterfall projects is 65%, which
is 6% lower than that of Agile projects as depicted in Figure 4.10.
72
Chapter 4
Agile
Benefits realised
69%
65%
User expectations
69%
65%
Product used
70%
62%
User satisfied
70%
64%
User acceptance
71%
64%
Specifications
73%
69%
Requirements
74%
75%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Waterfall
90%
100%
FIGURE 4.10: Deliverable success (Agile vs Waterfall).
The results highlight that in two-thirds of IS projects that follow
the Waterfall method, the deliverable does not meet the criteria.
This creates a serious concern as this implies that business and
strategic success cannot be achieved.
The next section focuses on business success and how the
deliverable of an IS project contributes to the overall success of
the business. Six criteria contribute to the success of the business.
Business success
Organisational leaders invest in a project to gain some benefits.
Criteria that organisational leaders interrogate are whether the
project meets the business and project objectives, is the business
case validated and are the benefits realised as indicated in the
business case?
The results in Figure 4.11 indicate that business success is
not that easily achieved. Business success is achieved in 62% of
73
Insights into information system project success
75%
70%
71%
65%
65%
64%
63%
60%
55%
54%
52%
ct
s
s
de
nt
en
ni
U
U
ni
nt
en
G
de
d
d
be
ov
er
na
ne
im
pa
fit
nc
e
io
n
at
B
en
ef
B
its
us
in
re
a
es
liz
s
G
pl
oa
ls
an
50%
FIGURE 4.11: Business success.
IS projects. The business success rate increases to 66% when
the criteria ‘Unintended benefits’ and ‘Unintended impacts’ are
removed. It is not always that easy for the project manager to
plan for these two criteria. The implication is still that a third of all
IS projects are not perceived as successful at this level.
In the remainder of the IS projects, IS project managers can
align the project with the organisational goal (71%) and this results
in the realisation of benefits (64%). This figure is still extremely
low given the fact that there is an emphasis on benefits realisation
in the last couple of years (Aguilera 2016; Bennington & Baccarini
2004; Marnewick 2016). Adherence to corporate and project
governance is also disappointingly low (63%) implying that IS
project managers are not always doing the right thing.
When the results are analysed based on the method that was
used, then it seems as if there is no difference between whether
a project used Agile or Waterfall as a method. The results in
Figure 4.12 illustrate that there is no difference between these
two methods.
74
Chapter 4
Agile
Unintended impacts
51%
52%
Unintended benefits
55%
54%
Benefits realization
65%
63%
Governance
63%
62%
Business plan
65%
63%
Goals
71%
70%
0%
20%
40%
60%
80%
Waterfall
100%
FIGURE 4.12: Business success (Agile vs Waterfall).
Using Agile as a method improves the chances of
achieving business success by 1% on average (Agile = 62% vs
Waterfall = 61%). The results raise more questions. One of the
questions that needs to be answered is whether IS projects
actually follow Agile methods or is it merely a lip service?
The last level of IS project success is determined at a strategic
level.
Strategic success
Investment in an IS project is perceived as a strategic success
when the project’s deliverable has a positive impact on the market,
competitors, investors and industry at large. The strategic success
rate is also not as high as one would hope for. The average success
75
Insights into information system project success
rate is 61% implying that two-fifths of IS projects are failures in
achieving strategic success for the organisation at large.
IS projects using an Agile method are far more strategically
successful than IS projects that are using Waterfall as a method
(Figure 4.14).
IS projects using Agile as a method are on average 41%
more successful than IS projects that use Waterfall as a
method. The reason is quite obvious. Project deliverables are
delivered quicker through Agile opening the opportunity for
quicker impact on the environment at large. The results portrayed
in Figure 4.14 corroborate the results displayed in Table 4.1. The
results highlight that Agile projects are delivered 7.7 months
quicker than projects that use Waterfall as a method.
Overall IT project success
People are not necessarily interested in the detail and want to
know what the overall success rates are of IS projects. The overall
70%
65%
62%
60%
62%
60%
60%
60%
55%
FIGURE 4.13: Strategic success.
76
ct
pa
im
ry
In
du
st
im
pa
ct
pa
im
y
ul
at
or
eg
R
In
ve
st
or
ct
t
im
ke
t
ar
M
C
om
pe
tit
iv
e
im
pa
c
pa
ct
50%
Chapter 4
Agile
Waterfall
Investor impact
81%
44%
Regulatory impact
83%
45%
Competitive impact
86%
45%
Industry impact
86%
41%
Market impact
87%
43%
0%
20%
40%
60%
80%
100%
FIGURE 4.14: Strategic success (Agile vs Waterfall).
59%
Strategic success
62%
Business success
68%
Deliverable success
Process success
50%
64%
52%
54%
56%
58%
60%
62%
64%
66%
68%
70%
FIGURE 4.15: Overall success.
success rate for IS projects are displayed in Figure 4.15. The project
success level is not included as it is difficult to convert time, cost
and scope into mere percentages. None of the four levels are
above 70%, and the average success rate is 63%.
77
Insights into information system project success
The success rate of 63% is a dramatic change from the 2013
figure of 34% (Marnewick 2013). It is a positive increase of
29%. This dramatic increase can be attributed to the way that
project success was measured in this study. Previous studies
focused on the success of an IS project with regard to time,
cost and scope. They did not focus on the other levels of
success.
The longitudinal analysis of IS project success is displayed in
Figure 4.16.
The overall success rates are further analysed based on the
method that was used, that is Agile or Waterfall. The comparison
is illustrated in Figure 4.17. The two major distinctions between
Agile and Waterfall are when process and strategic success
are measured. IS projects making use of Agile principles are
88% successful when process success is measured and 85%
successful when strategic success is measured. This is in stark
contrast with the results of IS projects that made use of the
Waterfall method.
70%
63%
60%
59%
50%
43%
40%
37%
34%
30%
20%
10%
0%
2002
2004
2006
2008
2010
2012
2014
2016
FIGURE 4.16: Longitudinal analysis of information technology project success rate.
78
2018
Chapter 4
Agile
Waterfall
Overall
100%
90%
43%
47%
80%
65%
70%
64%
60%
61%
68%
62%
59%
50%
40%
85%
88%
30%
71%
62%
20%
10%
cc
es
s
ss
su
su
cc
e
ic
s
B
us
in
St
ra
te
g
es
le
iv
er
ab
D
el
Pr
oc
es
s
su
su
cc
e
cc
es
s
ss
0%
FIGURE 4.17: Overall information technology project success.
TABLE 4.2: Overall information technology project success rates.
Item
%
Overall
Agile
Waterfall
Success average
63
77
54
Overall rule of 9’s
16
33
8
The concept of the ‘Rule of 9’s’ appears in the discipline of IT
service management (ITSM) (Schiesser 2010). Table 4.2 presents
the average IS project success rates, and it is evident that IS
projects using the Agile principles are 77% successful versus the
54% of IS projects that used the traditional Waterfall method.
The table also illustrates that the success rate of IS projects
drops from 63% to a mere 16% when the Rule of 9’s is applied.
This is also the case with Agile and Waterfall where the success
rates drop to 33% and 8% respectively.
79
Insights into information system project success
Conclusion
IS projects are still not out of the woods although there is an
increase in the success rates. The results highlighted two
important aspects. IS project success cannot be measured based
on the triple constraint and a new way of measuring is needed.
The results underline this principle where a strategic approach
is needed to measure IS project success. The aim is to deliver a
product or service that can be used by the customer and that
provide benefits to the organisation. This new way of thinking
has seen the increase of IS project success rising to 63%.
Secondly, it seems that incorporating Agile principles do have
a positive impact on the success of IS projects. Throughout the
analysis, projects that incorporate Agile principles do perform
better. This confirms the results of the 2015 Chaos Chronicles
where there is a 28% positive difference when Agile principles
are applied. The South African results indicate a difference of
23% when Agile principles are applied.
80
Chapter 5
Chapter 5
Insights into
information system
project complexity
IS project complexity does not have extensive exposure within
literature and thus requires further empirical investigation.
Chapter 3 revealed that IS project complexity was found to
have 75 features in total with 34 associated with organisational
complexity, 13 with technical complexity, 12 with environmental
complexity, 6 with dynamics and 10 with uncertainty. This
chapter aims to provide an initial analysis of IS project complexity
constructs and their respective features. Initial analysis provides
an overview of which complexity features to be aware of in
an IS project environment. Furthermore, analysis on IS project
complexity and IS project development method is also employed
for further insight.
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Insights into information
system project complexity’, in The symbiosis between information system project
complexity and information system project success, pp. 81–99, AOSIS, Cape Town. https://
doi.org/10.4102/aosis.2017.itpsc45.05
81
Insights into information system project complexity
I nformation system project
complexity features
Each IS project complexity construct was analysed to identify
the top five features.
Organisational complexity
The construct of organisational complexity is directly associated
with internal complexities in an organisation and consists of the
most complexity features. Table 5.1 displays the top five features
within organisational complexity.
Schedule dependencies is the number one feature to consider
as it relates to how project tasks and activities are planned and
allocated. Furthermore, an IS project must be scheduled within
the context of the organisation so that it has minimal impact
on day-to-day operations. Skills availability is ranked second
and implies that the appropriate skills are available to perform
project tasks. IS projects often require extensive technical
skills particularly during implementation, as well as soft skills
for effective management throughout the project (Marnewick,
Erasmus & Joseph 2016). Capital expenditure is ranked third
and reiterates the importance of understanding the financial
support required to execute the project. Experience is ranked
fourth and relates to experience with involved parties. This
implies that IS projects perform better if there is some form
of previous experience with all involved parties as there is a
better level of understanding and collaboration amongst all.
TABLE 5.1: Organisational complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Schedule dependencies
2
Skill availability
3
Capital expenditure
4
Experience
5
Project duration
82
Chapter 5
Finally, project duration is ranked fifth amongst organisational
complexity features. The duration of a project is a key factor to
consider when embarking on a new project as this is dictated
by the strategic importance of the project. As per Table 4.1, it is
complex to allocate project duration as IS projects are infamous
for their poor performance regarding the time constraint.
Further analysis was performed to determine whether there
was any difference in the organisational complexity feature
ranking with regard to the IS project development method, that
is Agile and Waterfall. Table 5.2 shows the top five rankings for
IS projects using Agile as a method.
The top two features are the same as the overall ranking of
organisational complexity features. Project duration moved to
position three compared to position five. This implies duration
is more of a complexity feature for Agile projects. It could be
argued that Agile places more emphasis on delivering quick
iterations to facilitate a faster project delivery rate. Task
structure is ranked fourth, which is somewhat surprising given
that Agile places less emphasis on structure and more on
deliverables. Conversely, task structure could be more pivotal
for Agile projects as the project team must continuously reevaluate their progress and realign task structures to meet
the ever-changing IS project environment. Information system
dependencies is the fifth ranked feature. The drive to deliver
iterations to realise project goals requires the support of
information systems which facilitate an enhanced solution
development. It is therefore logical that IS dependencies are
considered as a complexity feature.
TABLE 5.2: Organisational complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Schedule dependencies
2
Skill availability
3
Project duration
4
Task structure
5
Information system dependencies
83
Insights into information system project complexity
TABLE 5.3: Organisational complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Organisational structure
2
Schedule dependencies
3
Resource sharing
4
Skill availability
5
Organisational units
The ranking of organisational complexity features for IS
projects using Waterfall as a method is depicted in Table 5.3.
Waterfall complexity features are considerably different to the
Overall and Agile views.
Firstly, organisational structure is ranked as the highest
complexity feature to consider for IS projects which apply the
Waterfall method. Given that the Waterfall method is heavily
structured approached and sequential in nature, it could
be implied that IS projects must be more cognisant of the
structure when planning and executing the project. Schedule
dependencies come out second, which aligns closely to the
Overall and Agile views. It therefore can be concluded that,
regardless of the method, scheduling is of utmost importance.
Resource sharing is ranked third and is closely associated with
the organisational structure as the structure must be understood
to ensure resources are shared accordingly. Multiple projects
of various types are executed at any single point in time, thus
making resource allocation important for Waterfall projects as
they require significant upfront planning and task delegation.
Skills availability is ranked fourth and is comparable to the Overall
and Agile views. Organisational units is ranked fifth for Waterfall
projects. Similar to the organisational structure’s importance to
the Waterfall method, understanding what role each unit plays
during a project is important to ensure the project delivers
accordingly. IS projects span multiple departments and units
thus making them increasingly complex to manage.
The next section analyses the IS project complexity construct
of technical complexity and its inherent features.
84
Chapter 5
Technical complexity
Technical
complexity
assesses
strategic
and
tactical
characteristics which directly influence the project. Table 5.4
shows the top five technical complexity features for IS projects.
Risks associated with the technical aspects of an IS project
are ranked first. Technical project characteristics are usually
considered during the initiation and planning phases but are
influenced during a project as well. The implication is that
technical characteristics must be part of the continuous risk
management as these add to the complexity of managing a
project. IS projects thrive on technology and employ new
technology wherever possible. Newness of technology is ranked
second and confirms that the use of new technology poses risks
as increased complexity arises. Chapter 4 notes that 71% and 70%
of specifications and requirements are met respectively (refer to
Figure 4.9). Scale of scope is ranked third and implies that project
scope is an important feature to consider to ensure a project
does not become overly complex. Not only must the scope be
well defined but also realistic to ensure the project can actually
be delivered. The number of tasks is ranked fourth. Project tasks
form the basis of any project and the number of them should not
be overwhelming and make the project increasingly difficult to
execute. The number of tasks is associated with the task structure
in organisational complexity as these work in tandem. It could be
argued that the number of tasks could be attributed to IS projects
deviating from the original time and cost (Table 4.1). Finally, the
variety of tasks is ranked fifth for technical complexity features.
Variety of tasks speaks to the skills availability of organisational
TABLE 5.4: Technical complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Technical risks
2
Newness of technology
3
Scale of scope
4
Number of tasks
5
Variety of tasks
85
Insights into information system project complexity
complexity as many tasks require different skill sets at different
proficiency levels. The project can only be delivered if the
appropriate skills are available or sought after.
The top five features of technical complexity when Agile is
adopted are presented in Table 5.5.
Technical risks and newness of technology are once again
ranked first and second for Agile projects respectively. Variety of
tasks is ranked third and implies that Agile projects include more
task variety during a project. The adaptive and flexible nature of
Agile suggests that there will be more task variety as solution
development will go through multiple iterations based on user
feedback particularly. Diversity of inputs and outputs is ranked
fourth and relates to the argument around the variety of tasks
as well. Furthermore, inputs and outputs are not predefined for
Agile projects implying that there is more inherent diversity which
contributes to complexity. Scale of scope is ranked fifth and
implies that although Agile projects also rely on well-documented
scope, they are more open to scope changes and alterations to
ensure the project delivers as intended. Furthermore, Chapter 4
revealed that Agile projects meet specifications and requirements
more successfully than Waterfall projects.
The ranking of technical complexity features for IS projects
using Waterfall as a method in Table 5.6 is very similar to the
Overall view of complexity features albeit in different order.
Technical risks is ranked first for the Overall, Agile and
Waterfall views of IS projects which confirms its importance
from a complexity perspective. Scale of scope is ranked second
highest in Waterfall projects. The Waterfall method is much more
TABLE 5.5: Technical complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Technical risks
2
Newness of technology
3
Variety of tasks
4
Diversity inputs/outputs
5
Scale of scope
86
Chapter 5
TABLE 5.6: Technical complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Technical risks
2
Scale of scope
3
Number of tasks
4
Newness of technology
5
Variety of tasks
procedural and thus requires significant time spent on planning
and designing an IS project solution. The scope is expected to
be more detailed and complete, which makes it a significant
technical complexity feature. Alternatively, Figure 4.10 contends
that Waterfall projects deliver less on requirements and
specifications, which contrasts with its approach of well-defined
scope development. The number of tasks is ranked third and is
more important for Waterfall projects as the number of tasks is
defined early and is not as flexible as Agile projects. Waterfall
projects rank newness of technology fourth implying that,
although it is an important feature, it does not have the same
significance as in the Overall and Agile views. It could be that new
technologies are intensively evaluated up front before adoption
to decrease possible project complexities. Finally, the variety of
tasks is ranked fifth and implies that Waterfall projects consider
task variety somewhat less than Agile projects. This does not,
however, negate the importance of understanding the various
tasks required to execute an IS project.
An analysis of environmental complexity features is performed
in the following section.
Environmental complexity
Environmental complexity assesses the internal and external
organisational environment in which the project operates. The top
five environmental complexity features are shown in Table 5.7.
Stakeholder perspectives can vary during IS projects thus making
it difficult to satisfy all stakeholders. Stakeholder perspectives is
ranked number one for IS projects in general, which implies it is
87
Insights into information system project complexity
TABLE 5.7: Environmental complexity top five complexity features (Overall).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Internal strategic pressure
3
Number of stakeholders
4
Stability of project environment
5
Political influence
increasingly complex to manage stakeholder expectations and
to realise stakeholder satisfaction across the board. Constant
communication and interaction with all stakeholders are a means
to limit the complexity associated with varying perspectives.
Internal strategic pressure results from the pressure of senior
management expectations regarding the project. This feature
is ranked second and implies that IS projects experience higher
levels of complexity because of internal strategic pressure. As
mentioned, meeting all expectations is difficult and should be done
as best possible. The number of stakeholders is ranked third and
speaks to the complexity managing multiple internal and external
stakeholders involved in a project. Project communication is
more difficult than previously believed and is a skill set required
to ensure all stakeholders have an equal understanding of the
project at hand (Marnewick et al. 2016). IS projects which have
a large number of stakeholders increase complexity given the
communication challenges. Projects should operate within a
stable environment and with minimal negative impacts occurring.
The stability of project environment is ranked fourth implying
that it is a challenge maintaining a stable environment for the
project to thrive and exist freely. The organisational environment
has a direct impact on the project environment as any instability
would influence how a project is executed. Political influence is
ranked fifth and relates to internal politics particularly. Internal
politics primarily arise from stakeholders with senior authority,
such as executives. There could be cases where executives insist
on changing business requirements and scope without fully
understanding the intricacies and influences on other complexity
constructs and features.
88
Chapter 5
The top ranking environmental complexity features when
using Agile as a method, is shown in Table 5.8.
Stakeholder perspectives remain top, which further iterates
the importance of stakeholder management. The number
of stakeholders is ranked second, one position higher than
the Overall view. The implication therefore is that Agile
projects are more complex with regard to the management of
stakeholders given the top two rankings. Furthermore, this is
in line with the Agile Manifesto, which stresses a people rather
than a process focus (Beck et al. 2001). Internal strategic
pressure is ranked one position lower but still indicates that
the organisation at large has a direct influence on IS project
management. Although Agile IS projects are more flexible
and adaptable, there must still be the semblance of a stable
operating environment. Stability of the project environment
is ranked the same at position four and further solidifies its
importance for Agile projects. Interestingly, Agile projects
are more complex with regard to understanding the level of
competition in the industry as it is ranked fifth. Agile projects
aim to deliver projects rapidly so that business value can be
realised as soon as possible. Complexity arises when competing
within the organisation’s industry as this requires even more
focus delivering solutions rapidly to gain or expand market
share. This notion is further support by findings in Chapter 4,
which confirm that Agile has greater market and industry
impact (refer to Figure 4.14).
The environmental complexity features for Waterfall projects
are shown in Table 5.9.
TABLE 5.8: Environmental complexity top five complexity features (Agile).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Number of stakeholders
3
Internal strategic pressure
4
Stability project of environment
5
Level of competition
89
Insights into information system project complexity
TABLE 5.9: Environmental complexity top five complexity features (Waterfall).
Ranking
Complexity feature
1
Stakeholder perspectives
2
Internal strategic pressure
3
Number of stakeholders
4
Political influence
5
Internal support
Stakeholder perspectives is still ranked number one and
confirms that it is a complexity feature which needs the utmost
attention. Internal strategic pressure maintains its top three
ranking as it is ranked second for Waterfall projects. The number
of stakeholders also holds its top three position as it is ranked
third. The top three for the Overall, Agile and Waterfall views
is particularly focused on stakeholder management, which is
more prevalent in modern project success literature (Joseph &
Marnewick 2014; Todorović et al. 2015; Williams 2016). Political
influence is included for Waterfall projects and is ranked fourth.
Internal politics seem to affect the Waterfall project complexity
more and must therefore be mitigated and managed as
effectively as possible. Finally, internal support is introduced
for the Waterfall projects as it is ranked fifth. Waterfall
projects arguably suffer from a lack of management support
from stakeholders such as project sponsors. This introduces
increased complexity as management support is required to
ensure the project aligns to the greater organisational goals.
Project complexity includes the construct of dynamics, which
is analysed in the next section.
Dynamics
The construct of dynamics focuses specifically on change
management practices and characteristics within an IS project.
Rather than ranking the top five, Table 5.10 ranks all the features
as there are only six features within the dynamics construct.
The number of changes is ranked first overall and implies
that the actual quantity of changes is complex to manage.
90
Chapter 5
TABLE 5.10: Dynamics top six complexity features (Overall).
Ranking
Complexity feature
1
Number of changes
2
Impact of changes
3
Change process
4
Scope of changes
5
Change over time
6
Frequency of changes
IS projects inherently have multiple changes throughout the
project, but the number of these changes should not be high
as multiple changes could imply that the project was not
completely understood and thus poorly developed. The impact
of changes is ranked second and should not be ignored as small
changes can have a large impact either positively or negatively.
Complexity increases particularly when negative changes occur
which derail the project, especially with regard to time and
cost. Complexity around the actual change process is ranked
third. Given that change is inevitable, an appropriate and welldesigned change process should exist to ensure changes are
managed effectively and are predominately positive. Scope of
changes is ranked fourth and focuses on the detail around the
expected changes. Similar to number and impact of changes,
the scope of changes should not be overwhelming as this would
suggest poor design. Although there are multiple changes
throughout a project, changes should have a fluctuation
pattern rather than maintain a continuous high level of changes.
Change over time and frequency of changes is ranked fifth and
sixth respectively and are comparable to scope of changes.
It becomes increasingly complex to manage a project with
frequent changes which change significantly over time.
The top six dynamics features when adopting Agile as a
method are presented in Table 5.11.
Managing the number of changes is still complex for Agile
projects as it is again ranked first. Change process has more
emphasis in Agile projects, which is logical given that Agile uses
continuous feedback to update and enhance the solution. The
change process must therefore be expedited to maintain iterative
91
Insights into information system project complexity
releases. Scope of changes is ranked one position higher at third
and implies that Agile projects face complexities around change
scope when delivering the various iterations. The impact of
changes is ranked lower at fourth, which arguably is consistent
with the fact that Agile minimises change impact through iterative
releases. Change frequency is important regardless and is ranked
one position higher for Agile at fifth. Interestingly, change over
time is considered the least complex for Agile projects, which
also corresponds with the notion that iterative releases facilitate
change management more effectively.
Dynamic complexity features for IS projects using the
Waterfall method, is ranked in Table 5.12.
The impact of changes is ranked top for Waterfall projects
which is significantly higher than the Agile project rankings. This
implies Waterfall projects face greater challenges when managing
change impact. The number of changes maintains its top two
ranking for the Overall, Agile and Waterfall views. This confirms
that it is important to not have too many changes at any single
point in time as this could detract from IS project execution and
negatively affect realising the project goals. Complexity around
TABLE 5.11: Dynamics top six complexity features (Agile).
Ranking
Complexity feature
1
Number of changes
2
Change process
3
Scope of changes
4
Impact of changes
5
Frequency of changes
6
Change over time
TABLE 5.12: Dynamics top six complexity features (Waterfall).
Ranking
Complexity feature
1
Impact of changes
2
Number of changes
3
Change process
4
Change over time
5
Scope of changes
6
Frequency of changes
92
Chapter 5
the change process is also apparent for Waterfall projects and thus
signifies the importance of having a well-designed change process
regardless of the project methodology employed. Waterfall
projects consider it more complex to manage change over time
as it is ranked fourth. This could be that Waterfall projects mainly
address changes towards the end of the project rather than
continuously and throughout the project. Interestingly, scope of
changes is ranked fifth and is considered not as complex compared
to the previously discussed features. Waterfall projects arguably
do not worry as much about the scope of changes because they
expect to implement multiple changes during the final project
stages. Frequency of changes maintains its low ranking at sixth
and serves to confirm that complexity around this feature is low as
the previous features aim to mitigate frequent changes.
The following section analyses the final project complexity
construct of uncertainty.
Uncertainty
Uncertainty assesses the level of doubt and vagueness inherent
in IS projects, and the Overall ranking for IS projects is showed
in Table 5.13.
Uncertainty regarding time is the most highly ranked
complexity feature overall. Time is one of the triple constraints
which are often argued as a key success criterion within project
management. Complexity around managing time uncertainty
therefore makes logical sense. Incomplete information is ranked
second and implies that IS projects experience significant
TABLE 5.13: Uncertainty top five complexity features (Overall).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Cost
4
Competency
5
Scope
93
Insights into information system project complexity
complexity regarding poor information dissemination. Incomplete
information such as poor requirements and specifications has a
detrimental effect on project delivery and subsequent success.
Cost is another component of the triple constraints which is
argued as important. It is ranked third from an uncertainty
perspective. Doubt around cost escalates quickly as it has a
knock-on effect on the project as a whole and can easily overshoot
planned estimates. Project competency is a strongly debated
topic in the IS project realm and brings to question whether IS
project managers have the appropriate skills and knowledge to
execute projects (Joseph & Marnewick; Marnewick et al. 2016).
Competency is ranked fourth and implies that it is increasingly
complex to ensure adequate competency exists for the project to
be executed correctly. Scope is ranked fifth within the uncertainty
construct of the IS project complexity. Scope uncertainty exists
predominantly when poor understanding and design exists.
Quality requirements is somewhat of a misnomer as literature
argues that practitioners do not take a holistic view during the
design of a solution and subsequently produce mediocre inputs
for development (Fernandez et al. 2015; Tamai & Kamata 2009).
Agile projects’ top uncertainty features are shown in Table 5.14.
The top three features are identical to the Overall view signifying
their importance. Scope is ranked one position higher at fourth,
implying Agile environments are slightly more complex regarding
the management of scope uncertainties.
Agile’s iterative and flexible environment suggests that scope
must be managed more carefully, otherwise the project could
become disjointed and not deliver as expected. Interestingly,
Agile introduces the feature of technological maturity as it is
TABLE 5.14: Uncertainty top five complexity features (Agile).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Cost
4
Scope
5
Technological maturity
94
Chapter 5
TABLE 5.15: Uncertainty top five complexity features (Waterfall).
Ranking
Complexity feature
1
Time
2
Incomplete information
3
Scope
4
Competency
5
Cost
ranked fifth. Agile arguably prefers using mature technology as
this would facilitate the fast-tracking of solutions to the market
as the team would have experience with adopted technology.
Conversely, it is complex to manage Agile projects which use
innovative and untested technology as experience will be lacking.
Table 5.15 shows the top five rankings for uncertainty features
for Waterfall projects. Time and incomplete information maintain
their top two positions once again.
It is therefore clear that that these two features add to IS
project complexity regardless of the methodology employed.
Furthermore, time uncertainty is arguably apparent in Table 4.1
where actual time deviates significantly from originally planned
time. Scope uncertainty is ranked highest for Waterfall projects,
which implies there is considerable doubt regarding upfront
scoping activities and that these projects battle with scope issues
throughout. Similar to the Overall view, competency is ranked
fourth when adopting the Waterfall method. Cost uncertainty
is ranked fifth implying that Waterfall projects do not consider
cost as a complex feature. This aligns to the findings in Chapter
4, which argue that Waterfall projects’ actual cost is less than the
original budget (Refer to Table 4.1).
The following section provides a holistic view of complexity
features by analysing them across all constructs.
Overall complexity view
The previous sections focus on the rankings of features within
a single complexity construct. The aim of the section is to
95
Insights into information system project complexity
elaborate on the previous findings by investigating the top five
and bottom five rankings across all five constructs. Table 5.16
provides an overview of the top and bottom five ranked features
of all constructs regardless of the method of orientation.
Technical risks ranked top overall implying that IS projects
complexity is primarily driven by project technicalities, that is
project goals, scope, tasks and technology experience. Schedule
dependencies is ranked second, which is logical given that project
management is a culmination of tasks required to deliver a successful
project. IS projects often face the dilemma of selecting technology
to adopt and implement. This is confirmed by the ranking of
newness of technology at third. Scope has been argued in previous
sections as a contentious issue which plagues IS projects. IS
projects face significant complexities regarding the scale of scope
as it is ranked fourth. Finishing off the top five is skill availability and
speaks directly to one of the most important resources required
for delivering a project. The project team particularly requires
extensive skills to not only manage an IS project but also implement
it. Interestingly, the top five features are predominantly technical
complexity features implying that IS projects should focus more
on technical aspects than anything else. It could be argued that
dealing with technical complexities could have a positive effect on
other complexity constructs and features.
The bottom five begins with undisclosed participants. IS
project environments do not consider this a complexity feature
which requires much attention. It has previously been argued
that all stakeholders should be accounted for to ensure the
TABLE 5.16: Top five and bottom five complexity features across all construct.
Ranking
Top 5
Bottom 5
1
TC technical risks
U undisclosed participants
2
OC schedule dependencies
OC HSSE
3
TC newness of technology
OC different languages
4
TC scale of scope
EC remoteness
5
OC skill availability
EC weather conditions
HSSE, health, safety, security and environment; TC, technical complexity; OC, organisational complexity;
EC, environmental complexity.
96
Chapter 5
project delivers accordingly. Yet, this feature is ranked as one of
the lowest. This could possibly be a fundamental indication why
IS projects perform poorly because they merely move forward
without comprehensive input from all involved. The second
lowest ranked feature is health, safety, security and environment
awareness implying that IS project environments omit complexities
associated with health and safety. Different languages used in a
project is considered the third lowest complexity feature, which
is surprising in the South African context given that the diverse
nature of the country includes the use of multiple languages.
Nevertheless, complexity around language is considered mediocre
and does not contribute sufficiently to IS project complexity. The
fourth lowest ranking is remoteness regarding the location or site
of the project deployment. The implication is that team members
and stakeholders do not face any difficulties accessing the project
site and logistics are not as complex. Weather conditions was
ranked the lowest of all the complexity features and implies that
IS projects continue regardless of the weather.
Similar to the individual assessment of complexity features,
this section will analyse features when different methodologies
are employed. Table 5.17 indicates the top and bottom five
feature rankings in an Agile project.
Schedule dependencies is the most highly ranked complexity
feature, which confirms that IS projects battle to manage their
schedule as the environment continuously changes during the
project. Agile projects view technical risks as the second most
important and is comparable to the overall view of complexity
features. Newness of technology retains its position at third
TABLE 5.17: Top five and bottom five complexity features across all constructs (Agile).
Ranking
Top 5
Bottom 5
1
OC schedule dependencies
U undisclosed participants
2
TC technical risks
OC different nationalities
3
TC newness of technology
EC remoteness
4
OC skill availability
OC different languages
5
D number of changes
EC weather conditions
OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics.
97
Insights into information system project complexity
and further iterates the importance of technology adoption and
implementation. Fourth is skill availability, which arguably confirms
that skills development and exploitation is a prerequisite in the IS
project realm. Agile projects are known for their iterations based on
feedback which lead to evolving changes. The number of changes
is ranked fifth and confirms that Agile projects face complexity
challenges regarding the management of multiple changes. Even
though Agile proclaims adaptation, multiple changes can become
cumbersome and adversely impact an IS project.
Undisclosed participants is once again ranked first further
implying its lack of complexity. Agile projects rank different
nationalities as the second lowest suggesting that organisations
have embraced the inclusion of multiple nationalities working
together given the modern landscape in which they operate.
Remoteness is ranked third while different languages is ranked
fourth. Weather conditions continues not to be a complex matter
as it is once again ranked last.
Table 5.18 indicates the top and bottom five feature rankings
in Waterfall projects.
Waterfall projects rank technical risks as top, which confirm
their complex nature to manage. Varying stakeholder perspectives
are introduced as a high-ranking complexity feature at position
two. It seems increasingly difficult to maintain and manage
various perspectives for Waterfall projects, which could be a key
attributing feature influencing IS project performance. Scale of
scope appears again as it is ranked third. The rigid nature of the
Waterfall method could be the reason why scope continues to be
a complex issue as the idea is that the scope is defined upfront
TABLE 5.18: Top five and bottom five complexity features across all constructs (Waterfall).
Ranking
Top 5
Bottom 5
1
TC technical risks
U undisclosed participants
2
EC stakeholder perspectives
OC HSSE
3
TC scale of scope
OC different languages
4
TC number of tasks
EC remoteness
5
TC newness of technology
EC weather conditions
OC, organisational complexity; TC, technical complexity; EC, environmental complexity; D, dynamics.
98
Chapter 5
and should not change. The fourth-ranking feature combines
some tasks that imply that Waterfall projects are not as adept at
task management compared to Agile projects. Although ranked
lower than the Overall and Agile views, newness of technology
maintains its position in the top five complexity features. IS
projects emphasise technology and it is, therefore, logical that
new technology complexities inherently exist for IS projects.
Technical complexities make up four of the five top ranked
features, which is similar to the argument made for the Overall IS
project complexity view.
The bottom five features are comparable to the Overall and
Agile views, which confirms that they are far simpler to manage
than other complexity features.
Conclusion
The aim of this chapter was to indicate which features in an IS
project are considered most complex so that practitioners can
make adequate provision for managing them. The rankings
for the overall and individual views of constructs show that no
environment is the same and that each view complexity in a
different light. Many features align with the environment they
operate in, that is, Agile and Waterfall. The analysis of the top
five complexity features does not show one construct as more
complex than another construct. What is evident is that features
from technical complexity construct occur nine times within the
top five features with organisational complexity in the second
place. IS project managers should analyse the various complexity
constructs and address the features one by one in order to
reduce the overall complexity of the project.
The subsequent question is: How does one manage these
complexity features to ensure they do not adversely affect
project delivery? Ironically, understanding IS project complexity
is complex in itself, which is why further analysis is required to
illuminate its inherent intricacies.
99
Chapter 6
Symbiosis between
IS project success
and complexity
All the constructs related to IS project success and IS project
complexity are represented in Appendix A. The various respective
elements and features are also included for ease of reference.
Moreover, observed variable names were defined as this would
act as a cross-referencing tool for the data analysis below.
onceptualising the symbiosis
C
between information system project
success and complexity
Project success and complexity are often viewed in isolation with
no real link argued between the two. However, in the real world
there is an indefinite association between the two concepts.
Chapters 2 and 3 discussed the concepts separately in detail as
these formed the foundation of articulating the symbiosis which
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Symbiosis between IS project
success and complexity’, in The symbiosis between information system project complexity
and information system project success, pp. 100–136, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.06
100
Chapter 6
inherently exists. The models represented in this chapter are based
on the logical mappings depicted and argued in this section.
The concept of project success has many definitions which
have varying perspectives and thus create an element of
incongruity in the project management landscape. Chapter 2
presented the five level model of project success to encapsulate
the concept from an IS perspective. The concept of project
complexity has also resulted in multiple views being developed,
which has culminated in a multidimensional perspective of the
concept. Chapter 3 subsequently presented a five dimensional
view for IS project complexity based on an extensive literature
review. The question posed here is how these views relate
theoretically and logically prior to further data exploration.
A conceptual theoretical model for the symbiosis between
IS project success and IS project complexity is presented in
Figure 6.1.
Organisational complexity spans the entire five level view of
project success as IS projects are executed within the organisational
context to facilitate the realisation of the business and strategic
goals. An organisation’s structural orientation affects everything
Organisational complexity + Environmental
complexity
Project
Process
success
Project
management
success
Product
Deliverable success
Organisational benefit
Business
success
Strategic
success
Technical complexity +
Dynamics + Uncertainty
FIGURE 6.1: Symbiosis of information system project success and information system
project complexity.
101
Symbiosis between IS project success and complexity
from the project process to long-term strategic success as the
organisational structure and business units directly influence how a
project is executed. The element of size pertains to attributes of an
IS project such as project duration, variety of methods and capital
expenditure, for example. Size thus plays a role that influences
process and project management success as each attribute pertains
to the groundwork that is performed for a project. Resources within
organisational complexity elaborate areas which pertain to business
and strategic success distinctly, such as project drive. Areas such as
resource and skills availability as well as experience with involved
parties align to project management and deliverable success as
both embrace effective project management execution to deliver
valuable product output. The project team and trust elements have
implications regarding process and project management success as
social dynamics propel and support the execution of an IS project.
Interdependencies and risk span the entire five level landscape as
each feature influences one or multiple success levels.
Environment complexity comparably covers all five levels of
project success as well. Process and project management success
are encapsulated by the elements of stakeholders and location.
The location element speaks to attributes and intricacies regarding
the project site. Process and project management success is
dependent on these environmental attributes as they influence the
activities required to execute a project. Stakeholders is an element
which emphasises stakeholder management, which is key to
realising process and project management success. Furthermore,
stakeholders aligns to deliverable success as the management of
stakeholders such as the end user aims to ensure the project delivers
its output goal. Business and strategic success is driven by the need
to compete within a competitive global landscape. These two levels
of organisational benefit are affected by complexities surrounding
environmental stability, strategic pressure and competition
level, which are represented in the market conditions element of
environmental complexity. Environmental risks span all success
levels as risks are inherent regardless the status of each level.
Technical complexity is inherently focused project management
as each of the features revolve around project management activities
102
Chapter 6
specifically. Inferences exist, therefore, that technical complexity
engages with the levels of process and project management
success. Differentiation relates to input and output diversity, which is
intrinsic of project management as a whole and the processes which
support it. Goals is specific to project goals and their alignment to
greater strategic initiatives. This is dealt with on the ‘ground’ level
where project activities are executed as each activity is aligned to
the greater project goal. The realisation of the project goal is not
the main concern during the project management phase as the
focus is on delivering the project with assessment done later on.
The elements of scope and task once again focus on actual activities
and how they are performed, which is project management itself.
Experience from a technical complexity view regards the challenges
dealing with technology in an IS project. This experience, therefore,
relates to project management success as the focus is on how
technology is used in the project to realise the project goal. Similar
to organisational and environmental risks, technical risks appeal to
process and project management risks at the ‘ground’ level.
Uncertainty incorporates elements and features around doubt
and vagueness, which is directly associated with process and
project management success. The triple constraints of time, cost
and scope are a project management assessment tool and are
specific to an individual project. Method and task uncertainty has
a process and project management orientation that is particular
to hands-on activities. The elements of goals, technology and
stakeholders uncertainty are project management specific as
they all deal with characteristics of the project itself and not
success areas after the project. This, however, does not negate
any possible propagating effect to the following project success
levels. Information uncertainty and vagueness occur regardless
of the various project management processes in place, which is
why it relates to process and project management success.
Project experience changes throughout
change management practices to maintain
Change management is covered in the
and is particular to the project itself, which
and requires robust
project momentum.
dynamics construct
implies that process
103
Symbiosis between IS project success and complexity
and project management success are once again influenced.
Change management is particularly important for IS projects as
methodologies have different approaches which influence its
practice. For example, Agile projects profess adaption and iteration
which require robust change management practices and processes.
The discussion above argues the logical mapping of IS project
success and complexity to convey symbiosis of the two concepts.
The subsequent model development and analysis is based on
these mappings to illuminate the symbiosis.
evelopment and analysis of IS
D
project success models
The third section of the questionnaire requested the respondents
to provide their impressions regarding what affects project
success on various levels. These five levels were identified from
the research performed by Bannerman (2008):
•• Level 1: Process success. The need to consider technical and
managerial aspects in completing the project task.
• Level 2: Project management success. The immediate
performance of the project with regard to budget, scope
and schedule.
• Level 3: Deliverable success. The measures of information
quality, system quality, service quality, intention to use, actual
use, user satisfaction, and net benefits.
• Level 4: Business success. The ability of the project to
successfully meet the needs or solve a business problem the
customer is experiencing.
• Level 5: Strategic success. This criterion represents the highest
level of benefit achieved by a project, despite the possibility of
failures against lower level criteria, as recognised by external
stakeholders such as investors, industry peers, competitors, or
the general public, dependent upon the nature of the project.
One level is omitted in the discussion that follows, that is Level 2
that focuses on project management success. The questionnaire
requested specific data from the respondents which is not
104
Chapter 6
conducive for modelling. The other four levels were measured
using a 5-point Likert scale. Suffice to say that various other studies
have been able to determine the various critical success factors and
causes of failure (Marnewick, Erasmus & Joseph 2016).
What follows is a discussion on the Overall factors and model
as well as an investigation into the differences between Agile
and Waterfall projects.
Overall results
The Overall results closely reflected the research done by
Bannerman (2008) in that three of the levels were clearly
identified. The following factor loading is the result of factor
analysis through statistical software (Figure 6.1).
All the relevant variables associated with the different levels
associated with four factors. Factor 1 included all the variables of
deliverable success. These were:
••
•
•
•
•
•
•
requirements met
specifications met
client and/or user specifications met
client and/or user acceptance
product and/or system used
client and/or user satisfied
client and/or user benefits realised.
These clearly relate to Level 3 of the Bannerman (2008) model
and therefore Factor 1 can confidently be labelled as Deliverable
success. However, there are other variables, not thought of
as part of deliverable success in the original model, that are
associated with this factor. These are:
•• goals and/or objectives
• business plan
• benefits realisation.
These variables are identified as forming part of Business
success or Level 4. On examination it would seem these three
variables bear some relation to product success in the mind of
the respondents.
105
Symbiosis between IS project success and complexity
TABLE 6.1: Overall factor loadings with Pattern Matrix.
Observed
variablea
DS_06
Factor
1
2
3
4
0.851
DS_04
0.842
DS_03
0.800
DS_02
0.748
DS_07
0.728
DS_05
0.648
DS_01
0.626
BS_04
0.574
BS_01
0.561
BS_02
0.370
SS_03
0.756
SS_04
0.734
SS_01
0.722
SS_02
0.690
SS_05
0.603
SS_06
0.587
PS_01
0.772
PS_03
0.735
PS_02
0.698
PS_04
0.654
BS_05
1.018
BS_06
0.587
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
Factor 2 contained all the variables associated with strategic
success on Level 5 of Bannerman’s model. These are:
••
•
•
•
•
•
market impact
industry impact
competitive impact
investor impact
regulator impact
other impacts.
Therefore, Factor 2 can be labelled as Strategic success and
correlates strongly with what literature determines.
106
Chapter 6
Factor 3 includes all the variables labelled as part of process
success. These are:
••
•
•
•
Processes
Processes
Processes
Processes
appropriately chosen for the intended purpose.
aligned with project objective.
appropriately integrated with one another.
effectively implemented.
Therefore, Factor 3 correlates strongly with what Bannerman
(2008) identified as Level 1 and can be labelled as Process
success.
Two remaining variables are grouped into Factor 4. These
variables are:
•• Extent to which the project achieved unintended benefits.
• Extent to which the project achieved unintended consequences.
These variables are associated with business success in
literature. However, on their own, it may not be apparent that
they belong there. Given the ‘unknown’ description of both of
these variables, perhaps the data can be interpreted differently.
This factor is labelled as the Unknowns of project success as it
refers to impacts and consequences of conducting project work.
These impacts are difficult to plan for or to anticipate without
extensive due diligence activities.
These factors are all confirmed with Cronbach Alpha values
of 0.9 and above (Field 2013). Therefore, the researchers are
confident about the validity of the four identified factors. These
could be depicted as per Figure 6.2.
The next step is to attempt to determine a model. The purpose of
such a model is to ascertain whether there are links between these
different factors and whether or not there are correlations between
one another. This is done through the process of Structural
Equation Modelling (SEM). The following model (Figure 6.3)
emerged after numerous iterations.
This model clearly indicates that these different levels have
medium to strong relationships to one another, the strongest
being between Process success and Deliverable success. This is an
107
Symbiosis between IS project success and complexity
Deliverable
success
Unknowns
(of project
success)
Project
success
Strategic
success
Process
success
FIGURE 6.2: Project success level factors.
expected result as it would be difficult to imagine that a deliverable
can be produced without completing proper processes. Recall
that Bannerman (2008) indicated that these levels need not
necessarily be related to achieve success on higher levels. While
these results do not directly contradict Bannerman (2008), they
indicate that there is a relationship nonetheless. The outcome on
lower levels would seem to have an impact on the outcome on
higher levels.
108
Chapter 6
DS_06
DS_04
.80
DS_03
.80
DS_02
.80
.79
DS_07
DS_05
.71
.64
Deliverable
success
.74
DS_01
BS_04
.73
.68
.64
BS_01
.67
BS_02
SS_03
.76
SS_04
SS_01
.72
.74
SS_02
SS_05
.76
.65
.50
Strategic
success
.63
.63
SS_06
.52
PS_01
.68
PS_03
.76
PS_02
.72
.57
Process
success
.79
.45
PS_04
BS_05
.84
.76
BS_06
‘Unknown’
of success
FIGURE 6.3: Unconfirmed model for project success levels.
109
Symbiosis between IS project success and complexity
This model can be confirmed as valid. The following model
fit data was obtained from the SEM process as depicted in Table 6.2.
Therefore, for the purposes of this data set, we can confidently
conclude that IS project managers take cognisance of the
following levels of project success:
•• Level 1: Process success.
• Level 2: Project management success as determined by previous
studies.
• Level 3: Deliverable success.
• Level 4: Strategic success.
TABLE 6.2: Model fit data for Overall model for project success.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
Relative fit
measures
Fit measures
based on the
non-central
chi-square
distributions
Cut-off
levels
employed
≤5
Results
RMR
≤ 0.05
0.04
GFI
≥ 0.9
0.92
NFI
≥ 0.9
0.93
TLI
≥ 0.9
0.94
CFI
≥ 0.95
0.95
RMSEA
≤ 0.08
0.06
2.82
Reference
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney
et al. (2002); Roh, Ahn and
Han (2005) ; Ullman (1996);
Yatim (2008)
Roh et al. (2005);
Tabachnick and Fidell (1996);
Doloi, Iyer and Sawhney
(2011); Kim et al. (2009); Roh
et al. (2005);Tabachnick and
Fidell (1996)
Doloi et al. (2011); Stahl
(2008); Tabachnick and
Fidell (1996); Yatim (2008);
Doloi et al. (2011); Hair et al.
(2006); Stahl (2008); Yatim
(2008)
Anglim (2007); Doloi et al.
(2011); Gaskin (2013e); Hair
et al. (2006); Roh et al.
(2005); Tabachnick and
Fidell (1996); Stahl (2008);
Yatim (2008)
Hoyle (2011); Marsh, Hau and
Wen (2004); McQuitty and
Wolf (2013); Nunkoo and
Ramkissoon (2012); Reisinger
and Mavondo (2007)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit
Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean
Square Error of Approximation.
110
Chapter 6
The variables for business success (Level 4) are distributed
between Process success and Deliverable success. However,
project professionals also take note that unintended impacts
and consequences somehow form part of the model of project
success. It does, however, seem that these are separated from
other measures of project success considerations in that they
cannot be taken into account.
Results for Waterfall projects
The data can be separated into projects conducted using the
Waterfall and Agile methods, the purpose being to determine
if there are differences in how project success is perceived and
determined between the two methods.
Four factors closely mirroring those of the Overall results
were obtained. The factors were once again confirmed as
valid with a Cronbach alpha value of above 0.9 for all of them.
Table 6.3 indicates the factors loading for each variable and their
associated factors.
Slightly less clarity is obtained from this analysis because the
number of responses is now less than in the Overall view. On the
face of it, the result is very similar to that of the Overall result.
The factor groupings remain the same as in Table 6.1:
•• Factor 1: Deliverable success. The only difference is the
omission of the Goals and Objectives variable, which is now to
be found in Factor 3, Process success. This could be because
Waterfall projects are very structured and are initiated with the
goal of the project in mind right from the start.
• Factor 2: Strategic success. Is identical to that of the Overall
result.
• Factor 3: Process success. Is identical except for the variables
discussed above and for the addition of one variable associated
with business success. Interestingly enough, this variable is
Governance. In order for the factors and model to make sense,
governance is required. As a Waterfall project follows a very
rigid and formalised approach, strong governance lies at the
heart of it.
111
Symbiosis between IS project success and complexity
TABLE 6.3: Factors for project success with a Pattern Matrix (Waterfall).
Observed
variablea
DS_04
Factor
1
2
3
DS_03
0.861
DS_06
0.794
DS_07
0.694
DS_05
0.672
DS_02
0.653
BS_04
0.517
DS_01
0.393
BS_02
0.363
0.304
0.360
SS_05
0.834
SS_06
0.746
SS_04
0.725
SS_01
0.721
SS_03
0.590
SS_02
0.517
PS_01
0.803
PS_04
0.767
PS_03
0.766
PS_02
BS_01
BS_03
4
0.898
0.678
0.398
0.462
0.319
BS_05
0.812
BS_06
0.738
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
• Factor 4: Unknowns. Of a project success also remains
unchanged.
The SEM model (Figure 6.4) for these factors is also generated
and revealed to be as such.
Here even stronger interrelationships are identified, the
strongest relationship once again being between Process success
and Deliverable success. This correlation is very strong. This
would imply that the outcome in the preceding level of Process
success would directly and very strongly impact Deliverable
success. This is a clear indication on how the Waterfall method
impacts the outcome. The Waterfall method is initiated with a set
112
Chapter 6
DS_04
DS_03
DS_06
DS_07
DS_05
.79
.80
.78
.68
.57
.79
DS_02
.76
BS_04
.76
DS_01
Deliverable
success
.64
.67
BS_02
SS_05
.63
SS_06
.63
.66
SS_04
.72
SS_01
.94
Strategic
success
.76
.51
.75
SS_03
SS_02
.57
PS_01
.56
PS_04
.58
.69
PS_03
PS_02
BS_01
.63
.66
Process
success
.69
.51
.49
BS_03
BS_05
.85
.76
BS_06
‘Unknown’
of success
FIGURE 6.4: Unconfirmed model for Waterfall project success levels.
113
Symbiosis between IS project success and complexity
goal in mind to deliver a specific product. To obtain this product,
many processes are performed in an iterative fashion.
The model fit measures for this results were obtained as
depicted in Table 6.4.
The proposed model can be confirmed given the model fit
measures. It is clear that the conclusions for the Overall model
also apply to Waterfall projects. The one aspect that that is
different is how strongly goals and objectives are associated
with Level 1, Process success.
Results for Agile projects
The Agile method requires that its adherents only do what is
required to successfully complete the delivery of a product. This
TABLE 6.4: Model fit for Waterfall project success mode.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
RMR
GFI
Relative fit
measures
NFI
TLI
CFI
Fit measures
based on the
non-central
chi-square
distributions
RMSEA
Cut-off
Results Reference
levels
employed
≤5
2.7
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney et al.
(2002); Roh et al. (2005); Ullman
(1996); Yatim (2008)
≤ 0.05
0.04
Roh et al. (2005); Tabachnick and
Fidell (1996)
≥ 0.9
0.92
Doloi et al. (2011); Kim et al.
(2009); Roh et al. (2005);
Tabachnick and Fidell (1996)
≥ 0.9
0.93
Doloi et al. (2011); Stahl (2008);
Tabachnick and Fidell (1996);
Yatim (2008)
≥ 0.9
0.94
Hair et al. (2006); Doloi et al.
(2011); Stahl (2008); Yatim (2008)
≥ 0.95
0.95
Anglim (2007); Doloi et al. (2011);
Gaskin (2013e); Hair et al. (2006);
Roh et al. (2005); Stahl (2008);
Tabachnick and Fidell (1996);
Yatim (2008)
≤ 0.08
0.06
Hoyle (2011); Marsh et al. (2004);
McQuitty and Wolf (2013);
Reisinger and Mavondo (2007);
Nunkoo and Ramkissoon (2012)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit Index;
NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean Square
Error of Approximation.
114
Chapter 6
approach in no way absolves its adherents of the requirement of
a formalised approach.
The results in this data set once again yielded the same
four factors as found in the Overall and Waterfall models. All
four factors were confirmed as valid with a strong Cronbach
alpha above 0.9. The factor loadings obtained are depicted in
Table 6.5.
•• Factor 1: Deliverable success. Is identical to that of the Overall
model. This of course differs from the Waterfall project factors
where objectives and goals are excluded in favour of Factor 3:
Process success. For Agile projects, it seems that objectives
TABLE 6.5: Factors for Agile project success with Pattern Matrix.
Observed
variablea
Factor
1
DS_06
0.851
DS_03
0.834
DS_02
0.782
DS_01
0.737
DS_04
0.735
DS_07
0.671
BS_01
0.633
BS_04
0.574
DS_05
0.545
BS_02
0.421
2
SS_03
0.745
SS_02
0.729
SS_01
0.723
SS_04
0.714
SS_06
0.500
SS_05
0.433
PS_03
3
4
0.749
PS_04
0.733
PS_01
0.667
PS_02
0.607
BS_05
1.019
BS_06
0.509
Notes: Pattern Matrix: Rotation converged in 7 iterations, Extraction Method: Maximum Likelihood and
Rotation Method: Promax with Kaiser Normalisation.
a
, Variable names and associations are presented in Appendix A.
115
Symbiosis between IS project success and complexity
and goals form part of Factor 1: Deliverable success. This may
be because, in Agile projects, not all requirements are
immediately visible or identified but only developed during
further iterations of the process.
• Factor 2: Strategic success. Is identical to all previous results.
• Factor 3: Process success. Is identical to the Overall result and
only differs from the Waterfall projects’ results in two aspects.
The model for Agile project success does (1) not require
governance or (2) goals and objectives variables must be
coherent. This is an interesting result, given the propensity for
many Agile adherents to summarily dispense with valuable,
formalised techniques. Governance is the activity of guiding
behaviour to achieve a desired outcome and objective (Joseph,
Erasmus & Marnewick 2014). The fact that the respondents to
this questionnaire who practice Agile principles do not see value
or need for governance as a contributing factor project success
is cause for concern.
The Agile project success model was derived as in Figure 6.5.
This model once again indicates medium to strong relationships
between the four factors that were confirmed. Table 6.6 shows
the model fit measurements that were obtained.
This model is also confirmed as valid and can be accepted.
The medium to strong relationship indicates that once again
there are influences amongst the levels of project success that
cannot be ignored.
evelopment and analysis of IS
D
project complexity models
It must be noted that, unlike the IS project success models
presented above, no viable or feasible SEM models were
possible for all complexity constructs. Exploratory models are
subsequently presented as they still provide insight regarding
what complexity features to consider for IS projects.
116
Chapter 6
DS_06
DS_03
.80
DS_02
.80
.79
DS_01
DS_04
DS_07
BS_01
BS_04
.74
.80
.71
Deliverable
success
.68
.73
.64
.64
DS_05
.67
BS_02
SS_03
.76
SS_02
SS_01
.72
.65
SS_04
SS_06
.76
.74
.50
Strategic
success
.63
.63
SS_05
PS_03
PS_04
PS_01
.52
.57
.76
.79
.68
Process
success
.72
.45
PS_02
.84
BS_05
.76
‘Unknown’
of success
BS_06
FIGURE 6.5: Unconfirmed model for Agile project success levels.
117
Symbiosis between IS project success and complexity
TABLE 6.6: Agile model fit measurements.
Model fit
measures
Description
Absolute fit
measures
CMIN/DF
Relative fit
measures
Fit measures
based on the
non-central
chi-square
distributions
Cut-off
levels
employed
≤5
Results
RMR
≤ 0.05
0.04
GFI
≥ 0.9
0.92
NFI
≥ 0.9
0.93
TLI
≥ 0.9
0.91
CFI
≥ 0.95
0.95
RMSEA
≤ 0.08
0.06
2.8
Reference
Gaskin (2013e); Marsh and
Hocevar (1985); McKinney et al.
(2002); Ullman (1996); Roh
et al. (2005); Yatim (2008)
Roh et al. (2005); Tabachnick
and Fidell (1996)
Doloi et al. (2011); Kim et al.
(2009); Roh et al. (2005);
Tabachnick and Fidell (1996);
Doloi et al. (2011); Stahl (2008);
Tabachnick and Fidell (1996)
Yatim (2008)
Doloi et al. (2011); Hair et al.
(2006); Stahl (2008); Yatim
(2008)
Anglim (2007); Doloi et al.
(2011); Gaskin (2013e); Hair
et al. (2006); Roh et al. (2005);
Stahl (2008); Tabachnick and
Fidell (1996); Yatim (2008);
Hoyle (2011); Reisinger and
Marsh et al. (2004); Mavondo
(2007); McQuitty and Wolf
(2013); Nunkoo and
Ramkissoon (2012)
CMIN/DF, Chi-squared /Degrees of freedom; RMR, Root Mean Square Residual; GFI, Goodness-of-Fit
Index; NFI, Normal Fit Index; TLI, Tucker-Lewis Index; CFI, Comparative Fit Index; RMSEA, Root Mean
Square Error of Approximation.
rganisational complexity and project
O
success
Organisational complexity was identified as the IS project
complexity construct with the most features at 34. Furthermore, it
was depicted and discussed that organisational complexity spans
across all the project success levels. Exploratory factor analysis
(EFA) was performed to determine the latent constructs within
organisational complexity from an Overall, Agile and Waterfall
perspective. However, the EFA process was unsuccessful as a valid
and reliable exploratory model could not be determined based on
the current dataset. It was therefore established that future studies
will have to be performed to gain a better understanding and clarity
around the organisational complexity construct for IS projects.
118
Chapter 6
The irony that organisational complexity is complex to articulate
further iterates the importance of understanding this construct.
Environmental complexity
Failure of the organisational complexity EFA process resulted
in environmental complexity being analysed independently as
this would still provide value regarding what complexities to
assess from an environmental perspective. Similarly, EFA was
performed from an Overall, Agile and Waterfall perspective.
verall exploratory factor analysis modelling
O
of environmental complexity
Various measures were applied when validating the discovered
exploratory models. Firstly, the Kaiser-Meyer-Olkin (KMO) was
assessed at 0.848, which is a very good adequacy measure
(Field 2009; Gaskin 2016; Kaiser 1974). The KMO value was
also significant (0.000), which further validates this adequacy
measure. Extraction values from the communalities results are
also used to determine adequacy and are required to be above
0.3 (Gaskin 2016). This was confirmed as all values were above
the acceptable threshold. The total variance explained is another
adequacy measure which needs to be assessed. The threshold
for this measure is preferably above 50% (Gaskin 2016; Reio &
Shuck 2015), but the result was 44.4%. For the sake of research,
the results of this EFA will still be discussed as the other validity
and reliability measures were acceptable. Convergent validity was
established via factor loadings, which are required to be above 0.5
with an average loading, within a factor, of above 0.7 (Ferguson
& Cox 1993; Gaskin 2016; Hair et al. 2006). Table 6.7 presents
the factor loadings and reveals that further validation is required
to confirm the loading values. Cronbach’s alpha was used as a
reliability check with the threshold set at 0.7 (Badewi 2016; Chow
& Cao 2008; Hair et al. 2006). Cronbach values are represented in
Table 6.7 next to the factor number in brackets. Both values are
119
Symbiosis between IS project success and complexity
TABLE 6.7: Environmental complexity exploratory factor analysis Patten Matrix.
Observed variablea
Factor
1 (0.860)
EC_09
2 (0.811)
0.779
EC_08
0.701
EC_07
0.678
EC_13
0.664
EC_06
0.542
EC_12
0.542
EC_10
0.513
EC_05
0.496
EC_11
0.470
EC_04
0.419
EC_01
0.867
EC_02
0.835
, Variable names and associations are presented in Appendix A.
a
acceptable as Factor 1 and Factor 2 have a score of 0.860 and
0.811 respectively and confirm the factor loadings. Discriminant
validity was assessed via the factor correlation matrix where there
should be no correlations above 0.7 (Gaskin 2016). The correlation
between Factor 1 and Factor 2 was below the threshold at 0.533.
A factor plot is also used to visualise the groupings for each
factor (Figure 6.6). It must be noted that factor plot diagrams can
only represent three factors effectively as they are limited to three
dimensions. The groupings are distinct and confirm the loadings.
An exploratory model for the environmental complexity of IS
projects is depicted in Figure 6.7. The EFA revealed that one
factor had to be removed, that is political influence (EC_03).
Political influence, therefore, has no effect on IS project
complexity and subsequently IS project success. Political
influence could be a feature which must be handled by external
parties such as senior management, as the project should be
left to its own devices to deliver as required. Factor 1 is labelled
strategic and tactical conditions as the inherent features revolve
around strategic aspects such as internal strategic pressure
and level of competition. Strategic aspects focus on the greater
project goal and its relation to strategic intent. Tactical aspects
120
Chapter 6
Factor plot in rotated factor space
1.0
EC_01
EC_02
0.5
Factor 2
EC_11
EC_04
EC_05
EC_06
0.0
EC_10
EC_12
EC_13
EC_09
EC_08
EC_07
–0.5
–1.0
–1.0
–0.5
0.0
Factor 1
0.5
1.0
FIGURE 6.6: Environmental complexity factor plot diagram.
Strategic and tactical conditions
Stakeholder management
• Internal support
• Required local content
• Weather conditions
• Interference with existing site
• Remoteness of location
• Experience in country
• Internal strategic pressure
• Level of competition
• Stability of project environment
• Environmental risks
• Number of stakeholders
Environmental
complexity
• Variety of stakeholder
perspectives
FIGURE 6.7: Exploratory model for environmental complexity of information system project.
include, amongst others, remoteness of location, experience in
the country, risks and weather conditions. Tactical aspects focus
on practices and considerations around ground level activities of
the project itself.
121
Symbiosis between IS project success and complexity
gile exploratory factor analysis modelling of
A
environmental complexity
The Agile EFA model of environmental complexity applies the
same acceptance criteria as before. The KMO was significant
(0.000) and accepted at 0.849. All extraction values are above
the 0.3 threshold. Total variance explained is accepted on the
limit at 50%. Factor loadings presented an issue again, thus
Cronbach alpha was applied. The results were 0.823 and 0.832
for Factor 1 and Factor 2 respectively (Table 6.8). Reliability and
factor loading validity are therefore accepted and confirmed.
The correlation between Factor 1 and Factor 2 was below the
threshold at 0.558.
Distinct groupings are represented in the factor plot diagram
(Figure 6.8). Complexity features EC_05, EC_06, EC_07 and
EC_09 were removed to enhance EFA model validity and
reliability.
The results imply required local content, interference with
existing site, weather conditions and experience in a country
are not complexity features for Agile projects. Local content
TABLE 6.8: Environmental complexity exploratory factor analysis Patten Matrix (Agile).
Observed variablea
Factor
1 (0.823)
EC_09
0.892
EC_13
0.687
EC_10
0.644
EC_11
0.628
EC_08
0.526
EC_12
0.447
EC_03
2 (0.832)
0.829
EC_02
0.772
EC_01
0.737
EC_04
0.596
, Variable names and associations are presented in Appendix A.
a
122
Chapter 6
Factor plot in rotated factor space
1.0
EC_03
EC_02
EC_01
EC_04
Factor 2
0.5
EC_12
EC_10
EC_11
EC_13
EC_08
0.0
EC_09
–0.5
–1.0
–1.0
–0.5
0.0
Factor 1
0.5
1.0
FIGURE 6.8: Environmental complexity factor plot diagram when using Agile.
requirement is arguably not an issue for Agile projects as they
adapt and reconfigure where necessary to accommodate the
use of local content-based policies where the project is being
executed. Similarly, the same could apply for interference with
the existing site. Protest action for example does not influence
Agile projects as it is dealt with on an ad hoc basis and initiative
is taken to continue where possible and minimise productivity
loss. Weather conditions was continuously ranked in the bottom
five features in Chapter 5 and is confirmed here as a poorly
represented complexity feature. Experience in a country may not
effect Agile projects as the projects draw on their own experience
from various projects to accommodate for country differences.
The exploratory model for Agile projects is similar to the Overall
model as the latent factors remain stakeholder management as
well as strategic and tactical conditions (Figure 6.9).
123
Symbiosis between IS project success and complexity
Stakeholder management
Strategic and Tactical conditions
•
•
•
•
•
Remoteness of location
Internal strategic pressure
Stability of project environment
Level of competition
Environmental risks
Environmental
complexity
(Agile)
• Number of stakeholders
• Variety of stakeholder
perspectives
• Political influence
• Internal support
FIGURE 6.9: Exploratory model for environmental complexity (Agile).
TABLE 6.9: Environmental complexity exploratory factor analysis Patten Matrix (Waterfall).
Observed variablea
Factor
1 (0.799)
EC_01
0.971
EC_02
0.747
EC_11
0.575
EC_03
0.525
EC_09
a
2 (0.793)
0.787
EC_07
0.722
EC_08
0.667
EC_13
0.610
, Variable names and associations are presented in Appendix A.
aterfall exploratory factor analysis modelling
W
of environmental complexity
The Waterfall EFA model came in at a KMO of 0.720, which is
low but acceptable. Extraction values were sufficiently above
the 0.3 threshold. Total variance was 53% and met adequacy
criteria. Individual factor loadings were above 0.5 where
Factor 1 averaged 0.704 and Factor 2, 0.696 (Table 6.9). This
discrepancy was addressed via Cronbach alpha tests where
the results were 0.799 and 0.793 for Factor 1 and Factor 2.
respectively. The correlation matrix revealed a low, accepted
correlation of 0.303.
The groupings are further reiterated in Figure 6.10.
The exploratory model for Waterfall projects is presented in
Figure 6.11 and shows a different take on environmental complexity
124
Chapter 6
Factor plot in rotated factor space
1.0
EC_09
EC_07
EC_08
EC_13
0.5
Factor 2
EC_11
EC_03
0.0
EC_02
EC_01
–0.5
–1.0
–1.0
–0.5
0.0
0.5
1.0
Factor 1
FIGURE 6.10: Environmental complexity factor plot diagram (Waterfall).
Stakeholder management
Project site and location
•
•
•
•
Weather conditions
Remoteness of location
Experience in country
Environmental risks
Environmental
complexity
(Waterfall)
• Number of stakeholders
• Variety of stakeholder
perspectives
• Political influence
• Stability of project
environment
FIGURE 6.11: Exploratory model for environmental complexity (Waterfall).
Stakeholder continues to manifest for Waterfall projects,
which arguably confirms its importance regardless of project
methodology. Waterfall projects include complexity related to
project environment stability and implies that Waterfall projects
are affected more significantly when the environment is unstable.
This could be attributed to the rigid, structured nature of the
125
Symbiosis between IS project success and complexity
Waterfall method where a systematic approach is adopted and
complied with from the outset. Project site and location is the
second latent factor identified which differs significantly from the
Overall and Agile views. Interestingly, Waterfall projects place more
emphasis on weather conditions, location remoteness, experience
in country and environmental risks. The remaining complexity
features were omitted. Environmental risks in the context of
Waterfall projects arguably pertain to site and location risks more
than anything else. Waterfall projects thrive on extensive upfront
planning which aims to negate future issues. This could be why
physical environmental aspects plan such an important role as
they are often underestimated or not completely understood.
The following section covers the remaining IS project
complexity constructs and their EFA analysis.
echnical complexity, dynamics and
T
uncertainty
Technical complexity, dynamics and uncertainty were mapped
within the process and project management success scope.
This formed the basis for the next EFA analysis as these three
constructs were analysed together to determine complexities
which are associated with the first two IS project success levels.
verall exploratory factor analysis
O
modelling of technical complexity,
dynamics and uncertainty
Similar to previous modelling practice, the same validity and
reliability measures were adopted. The KMO is 0.933 while all
extraction values are above 0.3. The five factors presented in Table
6.10 provide a total variance of 56% which is acceptable. Factor
loadings meet the acceptance criteria thus Cronbach’s alpha is
used to determine further reliability. The results are 0.901, 0.883,
0.848, 0.835 and 0.812 for Factor 1 to Factor 5 respectively. All
results are sufficiently above the acceptance level of 0.7 and thus
126
Chapter 6
TABLE 6.10: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix.
Observed
variable*
U_05
Factor
1 (0.901)
2 (0.883)
4 (0.835)
5 (0.812)
0.869
U_06
0.791
U_04
0.788
U_01
0.738
U_10
0.651
U_08
0.637
U_07
0.629
U_02
0.613
U_09
0.547
U_03
0.516
D_02
1.067
D_04
0.772
D_03
0.731
D_01
0.547
D_05
0.473
D_06
0.459
TC_07
3 (0.848)
0.948
TC_08
0.911
TC_06
0.576
TC_12
0.529
TC_05
0.391
TC_09
0.326
TC_03
0.870
TC_04
0.780
TC_02
0.542
TC_11
0.969
TC_10
0.667
, Variable names and associations are presented in Appendix A.
a
confirm the identified factors. Discriminant validity is achieved as
the factor correlation matrix reveals no correlations above 0.7.
As discussed previously, a factor plot diagram cannot be used
where more than three factors exist as the diagram is no longer
decipherable and provides no extra analysis value.
As per Figure 6.12, the EFA results revealed five factors, (1)
technology experience, (2) project goals, (3) project scope and
tasks, (4) dynamics and (5) uncertainty.
127
Symbiosis between IS project success and complexity
Technology experience
Project goals
• Newness of
technology
• Number of goals
• Experience with
technology
• Clarity of goals
Change management
• Change process
• Number of changes
• Scope of changes
• Frequency of changes
• Impact of changes
• Change over time
• Goal alignment
Technical,
Dynamics
and Uncertainty
complexity
Project scope and tasks
• Scale of scope
• Quality requirements
• Number of tasks
• Variety of tasks
• Conflicting norms and
standards
• Technical risks
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Uncertainty of goals and
objectives
• Technological maturity
and novelty
• Undisclosed participants
• Competency
• Incomplete information
FIGURE 6.12: Exploratory model for technical complexity, dynamics and uncertainty of
information system projects.
IS projects experience complexities regarding technology
usage as experience and adoption are the two features to be
constantly monitored. Given that IS projects thrive on technology
usage, whether as a project tool or for project implementation,
technology plays a pivotal role as experience is necessary for
effective usage. Furthermore, experience should be facilitated
through continuous development of project team members to
ensure they use appropriate technology for any given IS project.
The latent factor of project goals was apparent and signified the
importance of effective goal management. The number of goals
together with goal clarity and alignment are three prerequisites
required for any project, regardless of the methodology
employed. Complexities associated with these three features are
arguably the key reasons why IS projects perform poorly and
128
Chapter 6
do not deliver planned benefits. IS project managers and their
teams become so obsessed with delivering within time and cost
that key fundamentals like goal delivery are negated. Moreover,
project goals relate directly to the next factor of project scope
and tasks. Project tasks are based on the project scope, which
in turn is directly influenced by the set goals. The scale of the
scope determines the number and variety of tasks required
to execute the project. Conflicting norms and standards do,
however, hinder tasks and activities as various stakeholders
abide by different policies and procedures especially with regard
to their requirements. This is arguably evident by the inclusion of
technical risk in the project scope and tasks factor as risks arise
when transitioning from scoping activities to actual project task
execution.
The fourth factor perfectly maps the six features of dynamics
to change management as argued in the theoretical mappings
presented in Chapter 3. Change management is paramount to IS
projects as the intangible nature of these projects often results in
multiple changes as required particularly during implementation.
Change practices therefore have to be sound and promote
effective change regardless of what is required. Furthermore,
not all changes are positive as previously mentioned, thus these
changes must be mitigated and addressed through a robust set
of practices. The following question can thus be posed: What
change practices should be in place for IS projects to maintain
their momentum and experience minimal disruption? Future
research should address this contentious question. The final
factor of uncertainty also fully encapsulates the theoretical
mappings presented in Chapter 3 and confirms the role of
uncertainty in IS projects. Rather than focusing on what is
known, IS projects should be cognisant of what is unknown so
that when the uncertainty arises a more proactive mindset is
instilled for addressing uncertainty. Awareness does not imply
that a plan exists for any uncertainty incident, it implies that the
overall impact is recognised and will not be a ‘shock’ for parties
involved.
129
Symbiosis between IS project success and complexity
gile exploratory factor analysis modelling
A
of technical complexity, dynamics and
uncertainty
The Agile EFA has a KMO of 0.858 and all extraction values are
above 0.3. Total variance explained equalled 58%, which is well
within the threshold criterion. Only Factor 1 has factor loading
lower than 0.5 but Cronbach’s alpha was performed regardless
as part of the reliability check. Factor 1 to Factor 5 have Cronbach
alpha’s of 0.892, 0.856, 0.786, 0.800 and 0.782 respectively.
Factor loading validity and reliability is therefore confirmed.
The factor correlation matrix (Table 6.11) also confirmed
discriminant validity as no correlation above 0.7 exists.
TABLE 6.11: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix (Agile).
Observed
variablea
Factor
1 (0.892)
TC_07
0.991
TC_12
0.769
TC_08
0.754
TC_06
0.685
TC_01
0.599
TC_05
0.594
TC_09
0.434
2 (0.856)
U_05
0.804
U_04
0.778
U_01
0.737
U_10
0.594
U_02
0.573
U_07
0.532
U_03
0.521
U_08
0.515
3 (0.786)
D_02
1.054
D_04
0.583
4 (0.800)
TC_11
1.014
TC_10
0.556
5 (0.782)
TC_04
1.033
TC_03
0.534
, Variable names and associations are presented in Appendix A.
a
130
Chapter 6
The five factors are identified as per Figure 6.13:
••
•
•
•
•
Factor
Factor
Factor
Factor
Factor
1: Project scope and tasks.
2: Uncertainty.
3: Change management.
4: Technology experience.
5: Project goals.
Although the factors are similar to the overall view of IS
projects, their composition is somewhat different.
Agile projects seem to have the added complexity of multiple
inputs and outputs. IS projects use and produce various inputs and
outputs throughout until final delivery. Agile projects arguably have
more inputs and outputs as the iterative philosophy leads to multiple
instances of these events. Furthermore, managing multiple inputs
and outputs can become a cumbersome process and escalate to a
point where the Agile mindset is its own worst enemy. Uncertainty
is the second factor which also has a different composition as goal
and objective as well as competency uncertainty are omitted.
Goal and objective uncertainty is possibly less of a ‘bugbear’ as
Agile embraces changes through flexible adaptive practices. More
interestingly is the exclusion of competency uncertainty which
contends that competency deficiencies could hamper a project’s
Project scope and tasks
• Number and diversity of
inputs and/or outputs
• Scale of scope
• Quality requirements
• Number of tasks
• Variety of tasks
• Conflicting norms and
standards
• Technical risks
Technology experience
• Newness of technology
• Experience with technology
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Technological maturity
and novelty
• Undisclosed participants
• Incomplete information
Technical,
Dynamics
and Uncertainty
complexity
(Agile)
Change management
• Number of changes
• Scope of changes
Project goals
• Goal alignment
• Clarity of goals
FIGURE 6.13: Exploratory model for technical complexity, dynamics and uncertainty (Agile).
131
Symbiosis between IS project success and complexity
progress. Agile projects also embrace competency deficiencies by
identifying these as they occur and addresses them while continuing
with the project. Furthermore, the flexibility promoted by Agile
allows resources reallocation especially for skill set acquisition.
Change management is only represented by the number and scope
of changes for Agile projects. The omission of other features implies
Agile projects are only concerned with the number and scope of
changes. Logically this makes sense given the iterative approach
adopted. An argument could be made that an overwhelming number
of changes and/or extensive change scopes could derail change
management practices. Addressing these two complexities would
indirectly address the omitted features of change management.
Technology experience remains stable as the two features are the
same as the Overall view. Project goals, on the other hand, have also
changed relatively as only goal alignment and clarity are considered
complexities for Agile projects. The number of goals is no longer
an issue as the Agile method promotes incremental development
where multiple goals are addressed efficiently. However, there
has to be clear alignment between goals to ensure Agile practices
deliver the correct project and business benefits.
aterfall exploratory factor analysis modelling
W
of technical complexity, dynamics and
uncertainty
The EFA process for Waterfall projects has an acceptable KMO of
0.876 and extraction values above the 0.3 threshold (Table 6.12).
Total variance explained is an excellent 62%. The factor loadings
required reliability confirmation using Cronbach’s alpha. Factor 1
to Factor 5 have alphas of 0.884, 0.888, 0.827, 0.747 and 0.863
respectively. Discriminant validity is accepted as no correlations
above 0.7 exist in the factor correlation matrix.
The five factors are once again similar as presented in Figure 6.14:
•• Factor 1: Uncertainty.
• Factor 2: Change management.
• Factor 3: Technology experience.
132
Chapter 6
TABLE 6.12: Technical complexity, dynamics and uncertainty exploratory factor analysis
Pattern Matrix (Waterfall).
Observed
variablea
U_04
Factor
1 (0.884)
2 (0.888)
3 (0.827)
4 (0.747)
5 (0.863)
0.813
U_06
0.809
U_05
0.804
U_01
0.674
U_08
0.625
U_10
0.606
U_03
0.595
U_02
0.575
TC_05
0.300
D_02
1.015
D_03
0.821
D_04
0.732
D_01
0.552
D_06
0.475
U_09
0.394
TC_11
0.898
TC_10
0.809
TC_12
0.595
TC_08
0.996
TC_07
0.485
TC_03
0.723
TC_04
0.664
, Variable names and associations are presented in Appendix A.
a
• Factor 4: Project scope and tasks.
• Factor 5: Project goals.
The composition has once again changed for Waterfall projects.
The uncertainty factor now includes uncertainty of goals and
objectives but omits competency and technological maturity
and novelty. This implies competency is not a complexity feature
and that technological maturity and novelty do not influence
Waterfall projects. Interestingly, scale of scope is included
which is commonly associated with project scope complexities.
This grouping implies that scale of scope has inherent
uncertainties regardless of project requirement size. Change
management excludes the impact of changes but encapsulates
133
Symbiosis between IS project success and complexity
Uncertainty
• Uncertainties in scope
• Uncertainties in cost
• Uncertainties in time
• Uncertainty in methods
• Task uncertainty
• Uncertainty of goals and
objectives
• Undisclosed participants
• Incomplete information
• Scale of scope
Project scope and tasks
• Number of tasks
• Variety of tasks
Change management
Technology experience
• Change process
• Number of changes
• Scope of changes
• Frequency of changes
• Change over time
• Competency
• Newness of technology
• Experience with
technology
• Technical risks
Technical,
Dynamics
and Uncertainty
complexity
(Waterfall)
Project goals
• Goal alignment
• Clarity of goals
FIGURE 6.14: Exploratory model for technical complexity, dynamics and uncertainty
(Waterfall).
the remaining five features based on the theoretical mappings.
The surprising inclusion of competency in change management
begs the question of whether adequate competencies exist for
addressing any change request in Waterfall projects. It could be
that competencies required to implement changes are inadequate
and lacking thus resulting in deferred delivery date. Technology
experience expands to include technical risks, which is arguably
a logical inclusion given that technology inherently has risks
associated with it regardless of experience or newness. Waterfall
projects are only concerned with the number of tasks and variety
of task complexities. These low level complexities pertain to the
planning phase of project management as the Waterfall method
places emphasis on extensive details. Any planning discrepancies
which arise during subsequent phases result in derailing the
project as tasks have to be reallocated and realigned on an ad
hoc basis. This inadvertently delays other aspects of an IS project.
Project goals is the fifth and final factor for Waterfall projects.
Similar to Agile projects, goal alignment and clarity are the two
pillars supporting project goal complexity. Given that Waterfall
projects emphasise upfront planning, any volatility with either
feature results in adverse effects on all project activities.
134
Chapter 6
Conclusion
The gathered data indicated that, in the information systems
project industry, we are dealing with various levels of project
success. How they operate in practice may differ slightly in detail.
Regardless of which method or approach is followed, IS project
managers are aware of process success, strategic success,
project management success and, most vitally, deliverable or
product success. It can be surmised that this is the focus of IS
project management when it is viewed holistically.
Remarkably very few differences are observed between Agile
and Waterfall projects. In most respects they are very similar.
The following differences are observed:
1. The overall correlations between the factors in Waterfall
projects are stronger than in those of Agile projects. This
could indicate that the structured and more formalised
approach of Waterfall projects have greater effects on
subsequent levels of projects success.
2. Objectives and goals seem to be important to Waterfall
projects in the process success factor, while in Agile projects
these considerations are important in the deliverable success
factor. This may point to a difference in focus between the
two methods.
3. The aspect of governance seems to play a role with Waterfall
projects and not at all with Agile projects. This may once again
be a symptom with regard to the underlying philosophy of
each. What could be at issue here is the fact that the
respondents indicated their own perceptions and as such
improperly utilise governance in projects.
What holds for all three confirmed models is the fact that there
does seem to be medium to strong interrelationships between
all these factors. As these factors can be mapped to Bannerman
(2008) levels, this dataset indicates that the outcome of lower levels
could have an impact on higher levels. Therefore it is important
to successfully complete project processes in order to facilitate
project deliverable success as well as ultimate strategic success.
135
Symbiosis between IS project success and complexity
The EFA analysis of the various constructs clearly and
interestingly showed that, although each environment has the
same number of latent factors, the composition of factors is often
different. Arguing that project complexity is uniform regardless
of type is clearly rejected, as these results show that within the
IS project landscape there are variations when adopting the
prevalent approaches of Systems Development Life Cycle and
Agile. IS project complexity is clearly not uniform or consistent as
different complexities are evident depending on methodology.
The exploratory nature of the complexity results suggests further
investigation to validate the above claims as more variation could
occur upon further analysis. The EFA models presented act as
preliminary results and form the foundation of further studies.
136
Chapter 7
Simple, complicated,
complex and chaos
The conclusion that one can make at the end of this book is that
IS project success and IS project complexity is not about absolute
numbers but more about a mindset. This mindset should be
focused on two aspects: The first aspect is that IS project success
is measured on a continuum and the second aspect is that IS
project complexity needs to be appreciated for what it is, that is
complex.
The framework of Bannerman (2008) is used to create this
mindset of IS project success as a continuum. Five levels exist
within this framework, and an IS project can be successful
at any one of these levels. The preference is that the project
should be successful at all five levels but this is not possible
in real life. Each level addresses a different aspect of success.
More importantly, the framework forces all the stakeholders
to take ownership for IS project success. IS project success is
not the responsibility of just the project manager but it is the
How to cite: Marnewick, C., Erasmus, W. & Joseph, N., 2017, ‘Simple, complicated,
complex and chaos’, in The symbiosis between information system project complexity
and information system project success, pp. 137–140, AOSIS, Cape Town. https://doi.
org/10.4102/aosis.2017.itpsc45.07
137
Simple, complicated, complex and chaos
responsibility of all the stakeholders. Specific stakeholders will
have different inputs, insights and influences at the different
levels, but at the end of the day it is everyone’s responsibility to
ensure IS project success.
The results depicted in Chapter 4 highlight that the success
rates have improved. This improvement is directly related to the
fact that success is measured on a continuum. When the results
are interrogated a little further, it is evident that success at a
business and strategic level is still at 62% and 59% respectively.
This creates an opportunity for organisational leaders to improve
the success rates and reap more benefits and value from the
investment in IT. The results also indicate that Agile projects
are more successful than Waterfall projects. This can result in
a product that is delivered by an Agile project being released
quicker to the market, thereby creating faster business and
strategic success than Waterfall projects. It might be worthwhile
for organisational leaders to invest in Agile as a method to deliver
IS projects quicker. This said, the emphasis should still be on
delivering these types of projects successfully at all five levels.
The modelling of the success levels reduced the five levels
to four levels. The last two levels (business and strategic) are
merged into one level, that is strategic success. IS project success
can then ultimately be measured as per Figure 7.1.
Although the framework of Bannerman indicates that there
is not necessarily a relationship between the different levels,
that is one level does not necessarily affect the outcome of the
next level, the results of SEM indicate that there are positive
correlations between the different levels. This implies that the
outcome of lower levels influences the outcome of higher levels.
Process
succes
Project
management
success
Deliverable
success
FIGURE 7.1: Information system project success levels.
138
Strategic
success
Chapter 7
IS project complexity itself is complex. Five constructs of
complexity were identified simplifying the view of complexity.
But beyond this simplified view, there are still 75 complexity
features that need to be taken into consideration. The problem is
that these 75 complexity features can appear in any combination
within an IS project. This opens the door for an IS project to
change from complex to chaos within the blink of an eye. The
analysis of the top five features in every construct make one
realise that there is actually no complexity feature that is more
important than another or that one construct is more important
than another construct. The results do suggest that technical
and organisational complexity are the two main constructs that
contribute to the complexity of IS projects.
The modelling of complexity did not yield the desired
results and only a suggestion of a possible model is provided.
The modelling suggests that environmental complexity can be
divided into stakeholder complexity and strategic complexity.
Organisational complexity is intricate and should be dealt with
in its entirety. The remaining three complexity constructs can
be divided into five new constructs. This implies that the IS
complexity can be viewed as eight new constructs instead of the
original five constructs. Whether this makes IS complexity less
complex, remains to be seen.
The symbiotic relationship between IS project success and
IS project complexity cannot be negated. This study could not
provide a definite answer to the problem at hand. Figure 7.2
provides insight into this symbiotic relationship.
Complexity plays a significant role during the lower levels
of IS project success as all eight constructs have an impact on
process and project management success. When it comes to
the deliverable and strategic success, then only three constructs
play a role.
What should organisational leaders and specifically IS project
managers do in the face of complexity? The impression is created
139
Simple, complicated, complex and chaos
Organisational complexity + Stakeholder complexity + Strategic/Tactical complexity
Process success
Project
management
success
Deliverable
success
Strategic success
Technology experience complexity
Project goal complexity
Project scope complexity
Change management complexity
Uncertainty
FIGURE 7.2: Symbiotic IS project success and complexity model.
that when IS project managers can manage the complexity
surrounding IS projects, then there is a better chance that these
projects will be delivered successfully.
Snowden and Boone (2007:69) state that ‘wise executives
tailor their approach to fit the complexity of the circumstances
they face.’ This is also applicable to IS project managers that
need to understand what they should do. The first step is to
identify the level of complexity within the IS project. Four levels
of complexity exist, namely simple, complicated, complex and
chaotic. IS project managers should manage simple, complicated
and complex projects in such a way that they do not become
chaotic. The line between complex and chaotic is very thin.
In conclusion, IS project managers cannot rely on the normal
competencies as promoted by the various project management
competency frameworks. They need to have additional
competencies to deal with complexity as the IS domain will become
more and more complex in the near future. This new understanding
of complexity will allow IS project managers to address complexity
and understand the impact it has on the success of a project.
Knowledge and wisdom of IS project complexity will increase
the success of IS projects and ultimately the value that IT provides
to the organisation.
140
Appendix
1. Project success variables
Construct
Feature
Process success
Chosen
PS_01
Alignment
PS_02
Deliverable success
Business success
Strategic success
Variable Name
Integrated
PS_03
Implemented
PS_04
Specifications Met
DS_01
Requirements Met
DS_02
User Expectations
DS_03
User Acceptance
DS_04
Product Used
DS_05
User Satisfied
DS_06
Benefits Realised
DS_07
Goals
BS_01
Business Plan
BS_02
Governance
BS_03
Benefits Realisation
BS_04
Unintended Benefits
BS_05
Unintended Impacts
BS_06
Market Impact
SS_05
Industry Impact
SS_05
Competitive Impact
SS_05
Investor Impact
SS_05
Regulatory Impact
SS_05
141
Appendix
2. Project complexity variables
Construct
Element
Feature
Organisational
complexity
Vertical differentiation
Organisational structure
Horisontal differentiation Organisational units
Size
Resources
Project team
Trust
142
Variable
Name
OC_01
OC_02
Task structure
OC_03
Project duration
OC_04
Variety of methods and tools
OC_05
Capital expenditure
OC_06
Work hours
OC_07
Project team
OC_08
Site area
OC_09
Number of locations
OC_10
Project drive
OC_11
Resource and skills availability
OC_12
Experience with involved parties
OC_13
Health, safety, security and
environment (HSSE) awareness
OC_14
Interfaces between different
disciplines
OC_15
Number of financial resources
OC_16
Contract types
OC_17
Number of different nationalities
OC_18
Number of different languages
OC_19
Cooperation with joint-venture
partner
OC_20
Overlapping office hours
OC_21
Trust in project team
OC_22
Trust in contractor
OC_23
Risk
Organisational risks
OC_24
Interdependencies
Environmental dependencies
OC_25
Resource sharing
OC_26
Schedule dependencies
OC_27
Interconnectivity and feedback
loops in task and project networks
OC_28
Dependencies between actors
OC_29
Information systems dependencies
OC_30
Objective dependencies
OC_31
Process interdependencies
OC_32
Stakeholder interrelations
OC_33
Team cooperation and
communication
OC_34
Appendix
2. Project complexity variables
(continues...)
Construct
Element
Feature
Technical
complexity
Differentiation
Number and diversity of inputs
and/or outputs
Goals
Number of goals
TC_02
Goal alignment
TC_03
Clarity of goals
TC_04
Scope
Tasks
Experience
Environmental
complexity
Location
Market conditions
Uncertainty
Risk
Triple constraint
Activity
Goals
Technology
Stakeholders
Dynamics
Information
Change management
TC_01
Scale of scope
TC_05
Quality requirements
TC_06
Number of tasks
TC_07
Variety of tasks
TC_08
Conflicting norms and standards
TC_09
Newness of technology
TC_10
Experience with technology
Risk
Stakeholders
Variable
Name
Technical risks
Number of stakeholders
Variety of stakeholder perspectives
Political influence
Internal support
Required local content
Interference with existing site
Weather conditions
Remoteness of location
Experience in country
Internal strategic pressure
Stability of project environment
Level of competition
Environmental risks
Uncertainties in scope
Uncertainties in cost
Uncertainties in time
Uncertainty in methods
Task uncertainty
Uncertainty of goals and objectives
Technological maturity and novelty
Undisclosed participants
Competency
Incomplete information
Change process
Number of changes
Scope of changes
Frequency of changes
Impact of changes
Change over time
TC_11
TC_12
EC_01
EC_02
EC_03
EC_04
EC_05
EC_06
EC_07
EC_08
EC_09
EC_10
EC_11
EC_12
EC_13
U_01
U_02
U_03
U_04
U_05
U_06
U_07
U_08
U_09
U_10
D_01
D_02
D_03
D_04
D_05
D_06
143
References
Chapter 1
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences, Hawaii, 04–07 January.
Boehm, B., 2006, ‘A view of 20th and 21st century software engineering’, Paper
presented at the 28th International Conference on Software Engineering
Proceedings, New York, 20–28 May.
Cooke-Davies, T., 2016, The strategic impact of projects – Identify benefits to
drive business results, Newtown, PA, viewed 09 February 2017, from http://
www.pmi.org/learning/thought-leadership/pulse/identify-benefits-businessresults.
Curley, M., Kenneally, J. & Carcary, M., 2016, IT Capability Maturity Framework™
(IT-CMF™), 2nd edn., Van Haren Publishing, Zaltbommel.
Denscombe, M., 2010, The good research guide: For small-scale social research
Projects, McGraw-Hill Education, New York.
Dorfman, M. & Thayer, R.H., 2000, Software requirements engineering, 2nd edn.,
IEEE Computer Society Press, Los Alamitos, CA.
Harris, M.D.S., Herron, D. & Iwanicki, S., 2008, The business value of IT, Taylor &
Francis, Boca Raton, FL.
IT Governance Institute, 2012, CobiT 5, ITGI, Rolling Meadows, IL.
Labuschagne, L. & Marnewick, C., 2009, The prosperus report 2008: IT Project
Management Maturity versus Project Success in South Africa, Project
Management South Africa, Johannesburg.
Leffingwell, D., 2011, Agile software requirements lean requirements practices for
teams, programs, and the enterprise, Addison-Wesley, Boston, MA.
Lovelock, J.-D., Hale, K., Hahn, W.L., Atwal, R., Graham, C. & Gupta, N., 2017,
Forecast alert: IT spending, worldwide, 4Q16 update, Stamford, CT, viewed
11 April 2017, from https://www.gartner.com/doc/3567217/forecast-alert-itspending-worldwide.
Marnewick, C. (ed.), 2013, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C. & Labuschagne, L., 2010, ‘Linking project benefits to strategic
objectives: An exploratory investigation’, Paper presented at the 6th
Biennial National Conference and Exhibition, Birchwood Conference Centre,
Johannesburg, 06–08 September.
144
References
Marnewick, C. & Labuschagne, L., 2011, ‘An investigation into the governance of
information technology projects in South Africa’, International Journal of Project
Management 29(6), 661–670. https://doi.org/10.1016/j.ijproman.2010.07.004
Martinsuo, M., Gemünden, H.G. & Huemann, M., 2012, ‘Toward strategic value from
projects’, International Journal of Project Management 30(6), 637–638. https://
doi.org/10.1016/j.ijproman.2012.03.006
Royce, W.W., 1970, ‘Managing the development of large software systems:
Concepts and techniques’, Paper presented at the 1970 WESCON Technical
Papers volume 14, Western Electronic Show and Convention, Los Angeles, CA,
25–28 August.
Sekaran, U., 2003, Research methods for business: A skill building approach, John
Wiley & Sons, Hoboken, NJ.
Sommerville, I., 2001, Software engineering, 6th edn., Addison-Wesley, Harlow.
Sonnekus, R. & Labuschagne, L., 2003, The prosperus report 2003, RAU Standard
Bank Academy for Information Technology, Johannesburg.
The Standish Group, 2014, Chaos Manifesto 2014, The Standish Group International,
Boston, MA.
Thomas, R.M., 2003, Blending qualitative and quantitative research methods in
theses and dissertations, Sage, Thousand Oaks, CA.
Chapter 2
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences,Hawaii, 04–07th January.
Barclay, C., 2015, ‘A Dialogue on the Diversity in the Constituents of Project
Success’, in Strategic project management: Contemporary issues and strategies
for developing economies, pp. 13–30, CRC Press, Barclay.
Bourne, L., 2011, Project failure: Cobb’s paradox, viewed 12 October 2016, from
https://pmhut.com/project-failure-cobbs-paradox.
Budzier, A. & Flyvbjerg, B., 2015, Why do projects fail?, Social Sciences Research
Network, New York.
Cooke-Davies, T., 2002, ‘The “real” success factors on projects’, International
Journal of Project Management 20(3), 185–190. https://doi.org/10.1016/S02637863(01)00067-9
Coombs, C.R., 2015, ‘When planned IS/IT project benefits are not realized: A study of
inhibitors and facilitators to benefits realization’, International Journal of Project
Management 33(2), 363–379. https://doi.org/10.1016/j.ijproman.2014.06.012
Davis, K., 2014, ‘Different stakeholder groups and their perceptions of project
success’, International Journal of Project Management 32(2), 189–201. https://
doi.org/10.1016/j.ijproman.2013.02.006
145
References
Erasmus, L.J., Marnewick, C. & Joseph, N., 2014, ‘The idle state of ICT projects in
South Africa’, Journal of African Business Management 15(3), 184–196.
Gerow, J.E., Thatcher, J.B. & Grover, V., 2015, ‘Six types of IT-business strategic
alignment: An investigation of the constructs and their measurement’,
European Journal of Information Systems 24(5), 465–491.
Jenner, S., 2016, Transforming government and public services: Realising benefits
through project portfolio management, CRC Press, Boca Raton, FL.
Johnson, J., 2014, The CHAOS Manifesto, The Standish Group, Boston, MA.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Kaiser, M.G., El Arbi, F. & Ahlemann, F., 2015, ‘Successful project portfolio
management beyond project selection techniques: Understanding the role
of structural alignment’, International Journal of Project Management 33(1),
126–139. https://doi.org/10.1016/j.ijproman.2014.03.002
Lovelock, J.-D., Hale, K., Hahn, W.L., Atwal, R., Graham, C. & Gupta, N., 2017,
Forecast alert: IT spending, worldwide, 4Q16 update, Stamford, CT, viewed,
11 April 2017, from https://www.gartner.com/doc/3567217/forecast-alert-itspending-worldwide.
Marnewick, C. (ed.), 2013a, Propsperus report, The African edition: Project
management maturity vs. project outcomes in Africa, Project Management
South Africa, Johannesburg.
Marnewick, C. (ed.), 2013b, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C., 2016, ‘Benefits of information system projects: The tale of two
countries’, International Journal of Project Management 34(4), 748–760.
https://doi.org/10.1016/j.ijproman.2015.03.016
Marnewick, C. & Erasmus, W., 2014, ‘Improving the competence of project managers:
Taking an Information Technology project audit’, Paper presented at the PMI
Research and Education Conference 2014, Portland, OR, 27–29 July.
Marnewick, C., Erasmus, W. & Joseph, N., 2016a, Information technology
Project managers’ compentencies: An analysis of performance and personal
competencies, viewed 09 March 2017, from http://www.books.aosis.co.za/
index.php/ob/catalog/book/30
Marnewick, C., Erasmus, W. & Joseph, N., 2016b, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Mir, F.A. & Pinnington, A.H., 2014, ‘Exploring the value of project management:
Linking project management performance and project success’, International
Journal of Project Management 32(2), 202–217. https://doi.org/10.1016/j.
ijproman.2013.05.012
Monteiro de Carvalho, M., 2013, ‘An investigation of the role of communication
in IT projects’, International Journal of Operations & Production Management
34(1), 36–64. https://doi.org/10.1108/IJOPM-11-2011-0439
146
References
Ngoma, M. & Erasmus, W., 2016, ‘Maturity of IT governance in the South African
public sector’, Paper presented at the International Association for the
Management of Information Technology 2017, Orlando, FL, May.
Project Management Institute, 2013, A guide to the project management body of
knowledge (PMBOK Guide), 5th edn., Project Management Institute, Newtown
Square, PA.
Rosemann, M. & Vom Brocke, J., 2015, ‘The six core elements of business process
management’, in J. vom Brocke & M. Rosemann (eds.) Handbook of business
process management, 1, pp. 105–122, Springer, Heidelberg.
Schwalbe, K., 2016, Information technology project management, 8th edn.,
Cengage Learning, Boston, MA.
Serra, C.E.M. & Kunc, M., 2015, ‘Benefits realisation management and its influence
on project success and on the execution of business strategies’, International
Journal of Project Management 33(1), 53–66. https://doi.org/10.1016/j.
ijproman.2014.03.011
Turk, D., France, R. & Rumpe, B., 2014, ‘Limitations of agile software processes’,
arXiv preprint arXiv:1409.6600.
Whyte, J., Lindkvist, C. & Jaradat, S., 2016, ‘Passing the baton? Handing over
digital data from the project to operations’, Engineering Project Organization
Journal 6(1), 2–14. https://doi.org/10.1080/21573727.2015.1115396
Chapter 3
Ahern, T., Leavy, B. & Byrne, P.J., 2014, ‘Complex project management as complex
problem solving: A distributed knowledge management perspective’,
International Journal of Project Management 32(8), 1371–1381. https://doi.
org/10.1016/j.ijproman.2013.06.007
Ahmed, A., 2012, Software project management: A process-driven approach,
Taylor & Francis, London, England.
Asher, H., 2013, Theory-building and data analysis in the social sciences, University
of Tennessee Press, Knoxville, TN.
Baccarini, D., 1996, ‘The concept of project complexity – A review’, International
Journal of Project Management 14(4), 201–204. https://doi.org/10.1016/02637863(95)00093-3
Badampudi, D., Wohlin, C. & Petersen, K., 2015, ‘Experiences from using snowballing
and database searches in systematic literature studies’, Paper presented
at the Proceedings of the 19th International Conference on Evaluation and
Assessment in Software Engineering, Nanjing, China, 27–29 April.
Bakhshi, J., Ireland, V. & Gorod, A., 2016, ‘Clarifying the project complexity construct:
Past, present and future’, International Journal of Project Management 34(7),
1199–1213. https://doi.org/10.1016/j.ijproman.2016.06.002
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. https://doi.org/10.1016/0263-7863(95)00064-X
147
References
Bosch-Rekveldt, M., Jongkind, Y., Mooi, H., Bakker, H. & Verbraeck, A., 2011,
‘Grasping project complexity in large engineering projects: The TOE (Technical,
Organizational and Environmental) framework’, International Journal of Project
Management 29(6), 728–739. https://doi.org/10.1016/j.ijproman.2010.07.008
Brown, C.J., 2008, ‘A comprehensive organisational model for the effective
management of project management’, South African Journal of Business
Management 39(3), 1–10.
Chan, F.K.Y. & Thong, J.Y.L., 2009, ‘Acceptance of agile methodologies: A critical
review and conceptual framework’, Decision Support Systems 46(4), 803–814.
https://doi.org/10.1016/j.dss.2008.11.009
Cooke-Davies, T., 2002, ‘The “real” success factors on projects’, International
Journal of Project Management 20(3), 185–190. https://doi.org/10.1016/S02637863(01)00067-9
Cooke-Davies, T., Cicmil, S., Crawford, L. & Richardson, K., 2007, ‘We’re not in Kansas
anymore, Toto: Mapping the strange landscape of complexity theory, and its
relationship to project mangement’, Project Management Journal 38(2), 50–61.
Derbyshire, J., 2016, ‘The implications, challenges and benefits of a complexityorientated futures studies’, Futures 77, 45–55. https://doi.org/10.1016/j.
futures.2016.02.001
Deutsch, M.S., 1991, ‘An exploratory analysis relating the software project
management process to project success’, IEEE Transactions on Engineering
Management 38(4), 365–375. https://doi.org/10.1109/17.97444
Dhingra, S. & Sampson, T., 2016, Life after BREXIT: What are the UK’s options
outside the European Union?, London School of Economics and Political
Science, London.
Dube, S. & Marnewick, C., 2016, ‘A conceptual model to improve performance in
virtual teams’, SA Journal of Information Management 18(1), 1–10.
Dunović, I.B., Radujković, M. & Škreb, K.A., 2014, ‘Towards a new model of
complexity – The case of large infrastructure projects’, Procedia – Social and
Behavioral Sciences 119, 730–738. https://doi.org/10.1016/j.sbspro.2014.03.082
Flick, U., 2014, An introduction to qualitative research, Sage, London.
Floricel, S., Michela, J.L. & Piperca, S., 2016, ‘Complexity, uncertainty-reduction
strategies, and project performance’, International Journal of Project
Management 34(7), 1360–1383. https://doi.org/10.1016/j.ijproman.2015.11.007
Frank, M., Sadeh, A. & Ashkenasi, S., 2011, ‘The relationship among systems engineers’
capacity for engineering systems thinking, project types, and project success’,
Project Management Journal 42(5), 31–41. https://doi.org/10.1002/pmj.20252
Gällstedt, M., 2003, ‘Working conditions in projects: Perceptions of stress and
motivation among project team members and project managers’, International
Journal of Project Management 21(6), 449–455. https://doi.org/10.1016/s02637863(02)00098-4
Geraldi, J., Maylor, H. & Williams, T., 2011, ‘Now, let’s make it really complex
(complicated): A systematic review of the complexities of projects’,
International Journal of Operations & Production Management 31(9), 966–990.
https://doi.org/10.1108/01443571111165848
148
References
Geraldi, J.G., 2008, ‘Patterns of complexity: The thermometer of complexity’,
Project Perspectives XXIX, 4–9.
Geraldi, J.G. & Adlbrecht, G., 2007, ‘On faith, fact, and interaction in projects’,
Project Management Journal 38(1), 32–43.
Green, G.C., 2004, ‘The impact of cognitive complexity on project leadership
performance’, Information and Software Technology 46(3), 165–172. https://
doi.org/10.1016/S0950-5849(03)00125-3
Hass, K.B., 2009, Managing complex projects: A new model, Management
Concepts, Vienna, VA.
Hastie, S. & Wojewoda, S., 2015, Standish Group 2015 Chaos Report – Q&A with
Jennifer Lynch, viewed 06 January 2016, from http://www.infoq.com/articles/
standish-chaos-2015.
Heaslip, R.J., 2015, Managing organizational complexity: How to optimize the
governance of programs and projects to improve decision making, Project
Management Institute, Newtown, PA.
Hobday, M., 2000, ‘The project-based organisation: An ideal form for managing
complex products and systems?’, Research Policy 29(7–8), 871–893. https://
doi.org/10.1016/S0048-7333(00)00110-4
Ika, L.A., 2009, ‘Project success as a topic in project management journals’,
Project Management Journal 40(4), 6–19, https://doi.org/10.1002/pmj.20137
Jalali, S. & Wohlin, C., 2012, ‘Systematic literature studies: Database searches
vs. backward snowballing’, Paper presented at the Proceedings of the
ACM-IEEE International Symposium on Empirical Software Engineering and
Measurement, Lund, Sweden, 19–20 September.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Joseph, N. & Marnewick, C., 2014, ‘Structured equation modeling for determining
ICT project success factors’, paper presented at the 2014 PMI Research and
Education Conference, Portland, OR, 27–29 July.
Killen, C.P. & Kjaer, C., 2012, ‘Understanding project interdependencies: The
role of visual representation, culture and process’, International Journal of
Project Management 30(5), 554–566. https://doi.org/10.1016/j.ijproman.2012.
01.018
Kim, J. & Wilemon, D., 2003, ‘Sources and assessment of complexity in NPD
projects’, R&D Management 33(1), 15–30. https://doi.org/10.1111/14679310.00278
Kim, J. & Wilemon, D., 2009, ‘An empirical investigation of complexity and its
management in new product development’, Technology Analysis & Strategic
Management 21(4), 547–564. https://doi.org/10.1080/09537320902819296
Lu, Y., Luo, L., Wang, H., Le, Y. & Shi, Q., 2015, ‘Measurement model of project
complexity for large-scale projects from task and organization perspective’,
International Journal of Project Management 33(3), 610–622. https://doi.
org/10.1016/j.ijproman.2014.12.005
149
References
Marnewick, A., 2013, ‘A socio-technical view of the requirements engineering
process’, DIng thesis, University of Johannesburg, Johannesburg.
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Martens, M.L. & Carvalho, M.M., 2017, ‘Key factors of sustainability in project
management context: A survey exploring the project managers’ perspective’,
International Journal of Project Management 35(6), 1084–1102. https://doi.
org/10.1016/j.ijproman.2016.04.004
Maylor, H., Vidgen, R. & Carver, S., 2008, ‘Managerial complexity in project-based
operations: A grounded model and its implications for practice’, Project
Management Journal 39(Suppl 1), S15–S26. https://doi.org/10.1002/pmj.20057
Milis, K. & Mercken, R., 2002, ‘Success factors regarding the implementation of
ICT investment projects’, International Journal of Production Economics 80(1),
105–117. https://doi.org/10.1016/S0925-5273(02)00246-3
Muller, R., Geraldi, J.G. & Turner, J.R., 2012, ‘Relationships between leadership
and success in different types of project complexities’, IEEE Transactions on
Engineering Management 59(1), 77–90.
Nguyen, A.T., Nguyen, L.D., Le-Hoai, L. & Dang, C.N., 2015, ‘Quantifying the
complexity of transportation projects using the fuzzy analytic hierarchy
process’, International Journal of Project Management 33(6), 1364–1376.
https://doi.org/10.1016/j.ijproman.2015.02.007
Padalkar, M. & Gopinath, S., 2016, ‘Are complexity and uncertainty distinct
concepts in project management? A taxonomical examination from literature’,
International Journal of Project Management 34(4), 688–700. https://doi.
org/10.1016/j.ijproman.2016.02.009
Pade, C., Mallinson, B. & Sewry, D., 2008, ‘An elaboration of critical success
factors for rural ICT project sustainability in developing countries: Exploring
the DWESA case’, Journal of Information Technology Case and Application
Research 10(4), 32–55. https://doi.org/10.1080/15228053.2008.10856146
Pinto, J.K. & Slevin, D.P., 1987, ‘Critical factors in successful project implementation’,
IEEE Transactions on Engineering Management EM-34(1), 22–27. https://doi.
org/10.1109/tem.1987.6498856
Project Management Institute, 2013, A guide to the project management body of
knowledge: PMBOK® Guide, 5th edn., Project Management Institute, Newtown
Square, PA.
Remington, K. & Pollack, J., 2007, Tools for complex projects, Gower, Farnham,
England.
Schön, E.-M., Thomaschewski, J. & Escalona, M.J., 2017, ‘Agile requirements
engineering: A systematic literature review’, Computer Standards & Interfaces
49, 79–91. https://doi.org/10.1016/j.csi.2016.08.011
Schwalbe, K., 2013, Information technology project management, Cengage
Learning, Stamford, CT.
Senescu, R.R., Aranda-Mena, G. & Haymaker, J.R., 2013, ‘Relationships between
project complexity and communication’, Journal of Management in Engineering
29(2), 183–197. https://doi.org/10.1061/(ASCE)ME.1943-5479.0000121
150
References
Shenhar, A.J., Holzmann, V., Melamed, B. & Zhao, Y., 2016, ‘The challenge of
innovation in highly complex projects: What can we learn from Boeing’s
dreamliner experience?’, Project Management Journal 47(2), 62–78. https://
doi.org/10.1002/pmj.21579
Shenhar, A.J., Levy, O. & Dvir, D., 1997, ‘Mapping the dimensions of project success’,
Project Management Journal 28(2), 5–13.
Sohi, A.J., Hertogh, M., Bosch-Rekveldt, M. & Blom, R., 2016, ‘Does Lean & Agile
project management help coping with project complexity?’, Procedia – Social and
Behavioral Sciences 226, 252–259. https://doi.org/10.1016/j.sbspro.2016.06.186
Tatikonda, M.V. & Rosenthal, S.R., 2000, Technology novelty, project complexity,
and product development project execution success: A deeper look at
task uncertainty in product innovation’, IEEE Transactions on Engineering
Management 47(1), 74–87. https://doi.org/10.1109/17.820727
Thamhain, H., 2013, ‘Managing risks in complex projects’, Project Management
Journal 44(2), 20–35. https://doi.org/10.1002/pmj.21325
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. https://doi.org/10.1016/j.
ijproman.2008.01.001
Thomé, A.M.T., Scavarda, L.F., Scavarda, A. & Thomé, F.E.S.S., 2016, ‘Similarities
and contrasts of complexity, uncertainty, risks, and resilience in supply chains
and temporary multi-organization projects’, International Journal of Project
Management 34(7), 1328–1346. https://doi.org/10.1016/j.ijproman.2015.10.012
Vidal, L.A., Marle, F. & Bocquet, J.C., 2007, ‘Modelling project complexity’, Paper
presented at the Proceedings of the International Conference on Engineering
Design, Paris, 28–31 August 2007.
Vidal, L.A. & Marle, F., 2008, ‘Understanding project complexity: Implications
on project management’, Kybernetes 37(8), 1094–1110. https://doi.
org/10.1108/03684920810884928
Vidal, L.A., Marle, F. & Bocquet, J.-C., 2011, ‘Using a Delphi process and the
Analytic Hierarchy Process (AHP) to evaluate the complexity of projects’,
Expert Systems with Applications 38(5), 5388–5405. https://doi.org/10.1016/j.
eswa.2010.10.016
Whitney, K.M. & Daniels, C.B., 2013, ‘The root cause of failure in complex IT
projects: complexity itself’, Procedia Computer Science 20, 325–330. https://
doi.org/10.1016/j.procs.2013.09.280
Whyte, J., Stasis, A. & Lindkvist, C., 2016, ‘Managing change in the delivery of
complex projects: Configuration management, asset information and “big
data”’, International Journal of Project Management 34(2), 339–351. https://
doi.org/10.1016/j.ijproman.2015.02.006
Williams, T.M., 1999, ‘The need for new paradigms for complex projects’,
International Journal of Project Management 17(5), 269–273. https://doi.
org/10.1016/S0263-7863(98)00047-7
Xia, W. & Lee, G., 2004, ‘Grasping the complexity of IS development projects’,
Communications of the ACM 47(5), 68–74. https://doi.org/10.1145/986213.986215
151
References
Chapter 4
Aguilera, I., 2016, Delivering value: Focus on benefits during project execution,
Newtown, PA, viewed 09 March 2017, fromhttp://www.pmi.org/-/media/pmi/
documents/public/pdf/learning/thought-leadership/pulse/benefits-focusduring-project-execution.pdf
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 04–07 January.
Bannerman, P.L. & Thorogood, A., 2012, ‘Celebrating IT projects success: A multidomain analysis’, Paper presented at the 2012 45th Hawaii International
Conference on System Sciences, Hawaii, 04–07th January.
Bennington, P. & Baccarini, D., 2004, ‘Project benefits management in IT projects –
An Australian perspective’, Project Management Journal 35(2), 20–31.
Marnewick, C. (ed.), 2013, Prosperus report – The African edition, Project
Management South Africa, Johannesburg.
Marnewick, C., 2016, ‘Benefits of information system projects: The tale of two
countries’, International Journal of Project Management 34(4), 748–760.
https://doi.org/10.1016/j.ijproman.2015.03.016
Marnewick, C. & Labuschagne, L., 2012, ‘Factors that influence the outcome of
ICT projects’, Paper presented at the PMSA Conference 2012, Johannesburg,
17–19 September.
Project Management Institute, 2013, A guide to the project management body of
knowledge (PMBOK Guide), 5th edn., Project Management Institute, Newtown
Square, PA.
Schiesser, R., 2010, IT systems management, 2nd edn., RR Donnelley, Crawfordsville,
IN.
Chapter 5
Beck, K., Beedle, M., Bennekum, A.V., Cockburn, A., Cunningham, W., Fowler, M. et
al., 2001, Manifesto for Agile software development, viewed 20 April 2017, from
http://www.agilemanifesto.org/.
Fernandez, D.M., Wagner, S., Kalinowski, M., Schekelmann, A., Tuzcu, A., Conte,
T. et al., 2015, ‘Naming the pain in requirements engineering: Comparing
practices in Brazil and Germany’, IEEE Software 32(5), 16–23. https://doi.
org/10.1109/MS.2015.122
Joseph, N., & Marnewick, C., 2014, ‘Structured equation modeling for determining
ICT project success factors’, Paper presented at the 2014 PMI Research and
Education Conference, Portland, OR, 27–29 July.
Joseph, N. & Marnewick, C., (2017), ‘Investing in project management certification:
Do organisations get their money’s worth?’, Information Technology and
Management 1–24. https://doi.org/10.1007/s10799-017-0275-y
152
References
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology
project managers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town.
Tamai, T. & Kamata, M.I., 2009, ‘Impact of requirements quality on project success
or failure’, in K. Lyytinen, P. Loucopoulos, J. Mylopoulos & B. Robinson (eds.),
Design requirements engineering: A ten-year perspective, vol. 14, pp. 258–275,
Springer, Berlin.
Todorović, M.L., Petrović, D.Č., Mihić, M.M., Obradović, V.L. & Bushuyev, S.D., 2015,
‘Project success analysis framework: A knowledge-based approach in project
management’, International Journal of Project Management 33(4), 772–783.
https://doi.org/10.1016/j.ijproman.2014.10.009
Williams, T., 2016, ‘Identifying success factors in construction projects: A case
study’, Project Management Journal 47(1), 97–112. https://doi.org/10.1002/
pmj.21558
Chapter 6
Anglim, J., 2007, Structural equation modelling, vol. 2013, Cambridge Scholars
Publishing, Newcastle upon Tyne.
Badewi, A., 2016, ‘The impact of project management (PM) and benefits
management (BM) practices on project success: Towards developing a project
benefits governance framework’, International Journal of Project Management
34(4), 761–778. https://doi.org/10.1016/j.ijproman.2015.05.005
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper
presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
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. https://doi.
org/10.1016/j.jss.2007.08.020
Doloi, H., Iyer, K.C. & Sawhney, A., 2011, ‘Structural equation model for assessing
impacts of contractor’s performance on project success’, International
Journal of Project Management 29(6), 687–695. https://doi.org/10.1016/j.
ijproman.2010.05.007
Ferguson, E. & Cox, T., 1993, ‘Exploratory factor analysis: A users’ guide’,
International Journal of Selection and Assessment 1(2), 84–94. https://doi.
org/10.1111/j.1468-2389.1993.tb00092.x
Field, A., 2013, Discovering statistics using IBM SPSS statistics, 4th edn., Sage,
London.
Field, A.P., 2009, Discovering statistics using SPSS: (And sex and drugs and rock
‘n’ roll), Sage, London.
Gaskin, J., 2013, SEM Series Part 5a: Confirmatory Factor Analysis, vol. 2013,
viewed 5 August 2013, from http://www.youtube.com/watch?v=MCYmyzRZn
IY&list=PLnMJlbz3sefLdYnz7TysHKrMBby7igpV9&index=6
153
References
Gaskin, J., 2016, SEM Series (2016) 3. Exploratory Factor Analysis (EFA), vol.
2017, viewed 16 January 2017, from https://www.youtube.com/watch?v=
VBsuEBsO3U8
Hair, J.F., Black, W.C., Babin, B.J., Anderson, R.E. & Tatham, R.L., 2006, M
ultivariate
data analysis, 6th edn., Prentice-Hall International, Upper Saddle River, NJ.
Hoyle, R.H., 2011, Structural equation modeling for social and personality
psychology, Sage, Thousand Oaks, CA.
Joseph, N., Erasmus, W. & Marnewick, C., 2014, ‘The idle state of information and
communication technology project management’, Journal of African Business
15(3), 184–196. https://doi.org/10.1080/15228916.2014.956641
Kaiser, H., 1974, ‘An index of factorial simplicity’, Psychometrika 39(1), 31–36.
https://doi.org/10.1007/bf02291575
Kim, D.Y., Han, S.H., Kim, H. & Park, H., 2009, ‘Structuring the prediction model
of project performance for international construction projects: A comparative
analysis’, Expert Systems with Applications 36(2 pt 1), 1961–1971. https://doi.
org/10.1016/j.eswa.2007.12.048
Marnewick, C., Erasmus, W. & Joseph, N., 2016, Information technology project
m anagers’ competencies: An analysis of performance and personal
competencies, AOSIS, Cape Town. https://doi.org/10.4102/aosis.2016.itpmc07
Marsh, H.W. & Hocevar, D., 1985, ‘Application of confirmatory factor analysis to
the study of self-concept: First- and higher order factor models and their invariance across groups’, Psychological Bulletin 97(3), 562–582. https://doi.
org/10.1037/0033-2909.97.3.562
Marsh, H.W., Hau, K.-T. & Wen, Z., 2004, ‘In search of golden rules: Comment on
hypothesis-testing approaches to setting cutoff values for fit indexes and
dangers in overgeneralizing Hu and Bentler’s (1999) findings’, Structural
Equation Modeling: A Multidisciplinary Journal 11(3), 320–341. https://doi.
org/10.1207/s15328007sem1103_2
McKinney, V., Yoon, K. & Zahedi, F.M., 2002, ‘The measurement of web-customer
satisfaction: An expectation and disconfirmation approach’, Information
Systems Research 13(3), 296–315. https://doi.org/10.1287/isre.13.3.296.76
McQuitty, S. & Wolf, M., 2013, ‘Structural equation modeling: A practical introduction’,
Journal of African Business 14(1), 58–69. https://doi.org/10.1080/15228916.2013.
765325
Nunkoo, R. & Ramkissoon, H., 2012, ‘Structural equation modelling and regression
analysis in tourism research’, Current Issues in Tourism 15(8), 777–802. https://
doi.org/10.1080/13683500.2011.641947
Reio, T.G. & Shuck, B., 2015, ‘Exploratory factor analysis’, Advances in Developing
Human Resources 17(1), 12–25. https://doi.org/10.1177/1523422314559804
Reisinger, Y. & Mavondo, F., 2007, ‘Structural equation modeling’, Journal of Travel &
Tourism Marketing 21(4), 41–71. https://doi.org/10.1300/J073v21n04_05
Roh, T.H., Ahn, C.K. & Han, I., 2005, ‘The priority factor model for customer
relationship management system success’, Expert Systems with Applications
28(4), 641–654. https://doi.org/10.1016/j.eswa.2004.12.021
154
References
Stahl, D., 2008, Introduction to path analysis and structural equation modelling
with AMOS, Vol. 2013, viewed 13 August 2013, from http://www.kcl.ac.uk/iop/
depts/biostatistics/teaching/previouslecturenotes/amos/amosweek3.pdf
Tabachnick, B.G. & Fidell, L.S., 1996, Using multivariate statistics, HarperCollins
College Publishers, New York.
Ullman, J.B., 1996, ‘Structural equation modeling’, in B.G. Tabachnick & L.S. Fidell
(eds.), Using multivariate statistics, pp. 709–810, Harper Collins, New York.
Yatim, B., 2008, Statistical modelling (Special Topic: SEM), vol. 2013, viewed 28
August 2013, from http://staf.uum.edu.my/byatim/nota/Multivariate/Powerpoints/Statistical%20Modelling2
Chapter 7
Bannerman, P.L., 2008, ‘Defining project success: A multilevel framework’, Paper presented at the PMI Research Conference: Defining the Future of Project
Management, Warsaw, Poland, 13–16 July.
Snowden, D.J. & Boone, M.E., 2007, ‘A leader’s framework for decision making’,
Harvard Business Review 85(11), 68–76.
155
Index
A
ability 28, 104
accept 29–30, 72
acceptance 30, 54, 70, 73, 105, 122,
126, 141
access 46
accurate 28, 59, 72
achieve 20, 32, 36, 44, 52–54, 108, 116
achieved 15, 21–23, 29, 31–32, 73, 104,
107, 127
acquisition 132
action 21, 31, 123
administration 5
Africa 2–3, 6–7, 9, 144
African 2, 7–8, 18–19, 80, 97, 144
African Context 97
Agile 12–14, 16–17, 44, 62, 64–68,
70–80, 83–84, 86–87, 89–92,
94–95, 97–99, 104–105, 111,
114–119, 122–124, 126, 130–132,
134–136, 138, 144
agreement 47
analyse 16, 37, 41, 66, 84, 93,
97, 99
application 1, 5, 36, 44
approach 12–16, 20, 34–35, 37, 44,
80, 87, 104, 111, 115, 126, 132,
135–136, 140
attributes 45, 53, 102
auspices 31
authority 88
autonomy 14
average 6–7, 66, 68, 71–72,
75–77, 79, 119
awareness 47, 55, 97, 129, 142
B
barriers 48
baseline 27
behaviour 31, 116
156
benefits 3–4, 6, 23, 27, 29–31, 46–47,
53, 58, 73–75, 80, 104–105, 107,
129, 132, 138, 141, 144
benefits realisation 27, 29–31, 74,
105, 141
bias 15
bodies 20, 25, 47
boundaries 48
bracket 119
breakdown 45, 66
budget 25, 27, 57, 70, 95, 104
business 3–5, 16, 22–26, 29–30, 36,
38, 40–41, 45, 49, 51, 53, 56,
58–59, 71, 73–75, 77, 88–89,
101–102, 104–105, 107, 111, 132,
138, 141, 144
business case 23, 73
business plan 75, 105, 141
business success 24, 73–75, 77,
104–105, 107, 111, 141
C
calculated 71
capabilities 21
care 7
certification 28
certified 28
challenge 4, 33, 88
challenges 28, 34–36, 38, 88,
92, 98, 103
change 9, 11–13, 27, 29–31, 35, 38,
40–41, 44, 59–60, 78, 86,
90–93, 97–99, 103–104, 128–129,
131–134, 139–140, 143
change control 27
change management 29, 59–60, 90,
92, 103–104, 128–129, 131–134,
140, 143
change process 59–60, 91–93, 128,
134, 143
Index
channels 35, 51
characteristics 85, 90, 103
claim 136
clarity 53, 58, 111, 118, 128, 131–132,
134, 143
classified 18
Cobb’s paradox 19
cognisance 10, 41, 110
collaboration 36, 38, 40, 44–45,
49, 51, 58, 82
communication 2, 13, 28–29,
36, 38, 40, 44–45, 49–51,
58–59, 88, 142
comparative 110, 114, 118
competency 36, 59, 93–95, 128,
131–134, 140, 143
competition 23, 57, 89, 102,
120–121, 124, 143
complete 14, 53, 59, 87, 114, 135
complex 10–12, 16, 38–39, 42, 47,
52, 55, 58, 60, 83–85, 88–95,
97–99, 119, 137–140
complexities 34–36, 38, 41, 46, 53,
82, 87, 92, 96–97, 99, 102, 119,
126, 128, 132–134, 136
complexity 1, 5, 7, 14–18, 21, 33–62,
81–104, 106, 108, 110, 112, 114,
116, 118–128, 130–134, 136–137,
139–140, 142–143
complexity model 34, 37, 39, 41,
116, 140
compromise 51
computer science 5, 151
concept 9, 14, 21, 33–34, 41–42,
57, 79, 100–101, 104, 145
conceptual model 34, 148
concern 6, 10, 22–23, 28, 47, 58,
72–73, 103, 116
conflict 48, 53
constraints 22, 38, 68, 93–94, 103
construct 14, 16–17, 33, 60–61,
81–82, 84, 88, 90, 93–100,
103, 116, 118–119, 126, 136, 139,
141–143
construction 34, 47
Content 41–43, 56, 121–123, 143
content analysis 41–43
context 29, 34, 42, 57, 66, 70, 82, 97,
101, 126
contract 47, 142
contractor 40, 49, 142, 153
contracts 47
contractual 47
contrast 66, 78, 87, 151
contributes 1, 32, 38, 42, 56, 73, 86
control 2, 23, 27, 39
conversion 11
cooperation 48, 51, 59, 142
cost 4, 16, 22, 34, 39, 45, 53, 57–58,
68, 70, 77–78, 85, 91, 93–95,
103, 128–129, 131, 134, 143
course 28–29, 115
create 3, 6, 10, 26, 39, 46, 73, 101,
137–138
creating 49, 138
Creation 5, 31
creep 57
criteria 22, 33, 70–74, 104,
122, 124, 126
Cronbach alpha 107, 111, 115,
122, 124
cross 40, 47, 64, 100
cultural 36, 48
culture 28, 30, 48
customers 1, 20, 22, 29–30, 72
customisation 11–12, 64–65
cycle 13, 66, 136
D
daily 1, 51, 55
data 2, 6, 11, 35, 100–101, 104, 107,
110–111, 115, 135
dataset 118, 135
deal 19, 27, 39, 43, 56, 103, 140
death 21
decision 15, 17, 20, 35, 37, 41
deficiencies 30, 131–132
defined 13–14, 21, 32, 36, 60, 70, 85,
87, 98, 100
degrees 110, 114, 118
deliverable 1, 20, 22–25, 28–30, 32,
66, 70–73, 75, 77, 101–102,
104–105, 107–113, 115–117, 135,
138–141
157
Index
deliverable success 24, 72–73, 77,
101–102, 104–105, 107–108,
110–112, 115–116, 135, 140–141
deliverables 1, 16, 76, 83
delivery 10, 19–20, 23, 31, 53, 65, 70,
83, 94, 99, 114, 129, 131, 134
dependencies 38, 50–52, 82–84,
96–97, 142
derailing 134
design 6, 12–13, 30, 91, 94
developing 35
development 13–14, 34–35, 39, 41, 45,
64–65, 81, 83, 86–87, 94, 98,
104, 116, 128, 132, 136
DevOps 64–65
dialogue 145
differentiation 43–44, 52, 103, 142–143
dilemma 96
discipline 1, 5, 23, 47, 68, 79, 142
disconfirmation 154
diversity 52, 86, 103, 131, 143
division 3, 9
drive 46, 52, 83, 102, 142, 144
duration 11, 37, 44, 47, 82–83, 102, 142
dynamic 35, 40–41, 45, 52, 92
dynamics 16, 36, 42–43, 54, 59–60,
81, 90–92, 97–98, 101–103,
126–134, 143
E
Economic Growth 56
education 35–36, 144
effectively 29, 35, 37, 40, 44, 48, 52,
60, 90–92, 107, 120
element 39–40, 43–44, 46, 48–59,
101–102, 142–143
elements 16–17, 37–40, 42–44, 52,
57–58, 60, 100, 102–103
embrace 5, 64, 102, 131–132
emerge 14
employed 37, 81, 93, 95, 97, 110, 114,
118, 128
employees 36
enablers 19, 27, 30–32
enterprise 2, 6, 12, 40, 49
environment 38, 40–41, 47, 50, 52,
54, 56, 62, 76, 81, 83, 87–89, 94,
158
96–97, 99, 102, 121, 124–125, 136,
142–143
environmental 16, 35, 42–43, 50, 54,
56–57, 60, 81, 87–90, 96–98,
101–103, 119–126, 139, 142–143
environmental complexity 16,
35, 42–43, 54, 56–57, 60,
81, 87–90, 96–98, 101–102,
119–125, 139
envisaged 31
evidence 6, 70
exclusion 131
executives 88, 140
exhibit 15, 60
expenditure 45–47, 82, 102, 142
experience 46, 48–49, 54, 56, 82,
88, 93, 95–96, 102–103, 121–123,
125–129, 131–132, 134, 140,
142–143
exploit 56
exploration 101
exploratory factor analysis (EFA) 118
exploratory model 116, 118–121,
123–125, 128, 131, 134
F
factor 14, 56, 66, 83, 105–107, 111–112,
115–116, 118–135
factor loading 105–106, 115, 119–120,
122, 124, 126, 130, 132
factor plot 120–123, 125, 127
factors 14, 33, 35, 38–39, 105, 107–108,
111–112, 115–116, 120, 123, 126–127,
131–132, 135–136
failure 22, 25–26, 29, 31–32, 50, 53,
56, 58, 76, 104–105, 119
feature 16, 42–46, 48–53, 55–61, 70,
81–100, 102–103, 116, 118, 120,
122–123, 126, 128–129, 132–134,
139, 141–143
feedback 13, 28, 39, 50–51, 86, 91, 98,
142
first 5, 12, 15, 21, 40–43, 48, 52, 55–57,
59, 62, 65, 85–86, 90–91, 98,
126, 137, 140
flexible 86–87, 89, 94, 131
formation 101
Index
framework 4–5, 9, 14, 16, 20–21, 37,
137–138, 140, 144
Freedom 110, 114, 118
G
generation 36
global 19, 102
goal 31, 36, 40, 44, 46, 51–53,
55, 58, 74, 102–103, 111,
114, 120, 128–129, 131–132, 134,
140, 143
goals 20, 23, 37–39, 45–46, 51–53,
58–59, 75, 83, 90, 92, 96, 101,
103, 105, 111, 114–116, 127–129,
131–135, 141, 143
governance 3, 9–10, 26, 74–75, 111, 116,
135, 141, 144
government 2
grouping 27, 111, 120, 122, 124, 100
growth 2, 4, 35, 56
H
hard 49
hardware 1, 4, 10, 34
health 47, 96–97, 142
high 26, 37–38, 41, 60, 75, 91, 98
Holistic 94–95
hope 75
I
identification 42
impact 4–5, 16, 23, 27, 30–32, 37–38,
49, 54, 56, 60, 74–77, 80, 82,
88–89, 91–92, 98, 106–108,
111–112, 128–129, 133, 135, 139–141,
143–144
implementation 10–13, 21, 29, 35, 40,
45, 47, 60, 64–66, 68, 82, 98,
128–129
importance 35, 37, 45–46, 52–53,
82–84, 86–87, 89, 93–94, 98,
119, 125, 128
inclusion 40, 44, 98, 129, 134
incorrect 59
individual 21, 26, 29–30, 32, 39, 45,
59, 97, 99, 103, 124
influence 16, 32, 34, 37–38, 40–41,
44–45, 47, 51, 54–56, 58–60,
85, 88–90, 102, 104, 116, 120,
123–125, 133, 138, 143
information 1–3, 5–9, 11, 15, 17–19,
28, 30, 33–36, 38–40, 42, 44,
46, 48, 50–52, 54, 56, 58–60,
62, 64, 66, 68, 70, 72, 74, 76,
78–84, 86, 88, 90, 92–96, 98,
100–101, 103–104, 128, 131,
134–135, 137–138, 142–143
information technology 1–3, 5, 8–9,
30, 39, 78–79
infrastructure 5–6, 10–12, 41, 64–65
inhibitors 27–32
Innovation 36–37, 39
input 97, 103
inputs 25, 52–53, 86, 94, 131, 138, 143
intangible 4, 46, 129
integrate 13, 34, 54, 64
integrating 34
integration vii, 2, 5, 11–12, 23, 34–35,
38, 40, 46–47, 54, 64–66, 68
interaction 5, 28, 35, 47, 51, 88
interconnected 52–53
interdependencies 37, 45, 49–51,
53, 102, 142
interfaces 47, 142
interpretation 32
interrelationships 112, 135
interviews 70
intra-organisational complexity 36
investigation 15, 42, 81, 105, 136, 144
investment 1–5, 18, 20, 22, 75, 138
K
Kaiser-meyer-olkin (KMO) 119
knowledge 19, 27, 36, 40, 45, 49, 59,
94, 140
L
lack 18, 24, 39, 45, 50, 55, 90, 98
language 5, 41, 48, 96–98, 142
language 48, 97
languages 5, 41, 48, 96–98, 142
large 1, 10, 21, 38, 45, 52, 75–76,
88–89, 91
159
Index
latent constructs 118
leaders 2, 4, 6, 10, 16–18, 20, 25, 28,
73, 138–139
leadership 144
leads 52–53, 58, 131
lean 64–65, 144
legislation 11, 55
life 13, 66, 136–137
locations 45–46, 56, 142
lose 25
lot 2, 11
M
maintenance 2, 4, 9
management 1, 6, 14, 16, 18–21, 23–29,
31–39, 42, 44–46, 48–52, 54–55,
57, 59–60, 70, 79, 82, 85, 88–
90, 92–94, 96, 98–99, 101–104,
110, 120–121, 123–126, 128–129,
131–135, 138–140, 143–144
management processes 103
manifest 125
maturity 58, 94, 128, 131, 133, 143–144
media 152
medium 37, 107, 116, 135
meeting 70, 88
member 25, 27, 31, 40, 48, 52, 58,
97, 128
method 12–15, 37, 44–45, 58, 64–66,
68, 70, 73–76, 78–79, 81,
83–84, 86, 89, 91–92, 95–96, 98,
102–103, 106, 111–112, 114–115, 126,
128, 131–132, 134–135, 138, 142–143
methodologies 13–14, 18, 20, 31, 62,
64, 70, 72, 97, 104
methodology 13–15, 18, 20, 28, 31, 62,
64, 70, 72, 93, 95, 97, 104, 125,
128, 136
methodology 15, 28, 93, 95,
125, 128, 136
miscommunication 29
mission 37
mistakes 25
mode 114
model 12–13, 15–16, 34, 36–37, 39, 41,
66, 101, 104–107, 109–125, 128,
131, 134–136, 139–140
160
model fit measures 114
monetary 7
money 1–2, 8, 35, 45
N
nation 56
nationalities 48, 97–98, 142
need 3, 8, 11, 15, 20, 24–29, 32, 39, 46,
48, 102, 104, 108, 116, 139–140
needs 10–11, 26, 28–29, 35, 40, 54, 61,
75, 90, 104, 119, 137
negative 4, 57, 59, 88, 91
network 11
networks 50, 142
newness 34–36, 85–87, 96–99, 128,
131, 134, 143
novelty 36, 58, 128, 131, 133, 143
number 10–11, 38–39, 44–45, 51–53,
55, 60, 82, 85, 87–92, 97–98,
111, 119, 121, 124–125, 128–129,
131–132, 134, 136–137, 142–143
O
objectives 2, 21, 25–26, 58, 73, 105, 111,
114–116, 128, 133–135, 143–144
observed variable 100
office 4, 11, 24, 46, 48–49, 142
only 1, 10, 15, 19, 23, 26, 29–31, 36, 39,
42, 49, 64, 68, 71–72, 85–86,
90, 96, 111, 114, 116, 120, 130, 132,
134, 139
open 86, 139
operates 35, 50, 87
operational 5, 10, 24, 30, 44, 50, 55
operational level 24
operations 20, 29, 57, 82
opportunities 4
order 11, 19–20, 25–26, 28–30, 32, 86,
99, 111, 135
organisational benefit 22, 24, 27, 29,
47, 101–102
organisational complexity 16, 35–36,
39–40, 42–44, 46, 48–50,
52–53, 56, 60–61, 81–85, 96–99,
101–102, 118–119, 139–140
organisational culture 28, 30
organisational goals 90
Index
organisational leaders 2, 4, 6, 10,
16–18, 20, 25, 28, 73, 138–139
orientation 96, 101, 103
oriented 31
other 5, 11–12, 14, 35–37, 39–40,
43–47, 49–50, 52–54, 57–60,
64–65, 70, 78, 88, 96, 99,
105–106, 111, 119, 121, 132, 134
outcome 16, 19, 21, 23–27, 36, 60, 108,
112, 116, 135, 138
outcome influencers 27
overwhelming 85, 91, 132
ownership 137
P
pace 35–37
paid 44–45
paradigm 19, 49
paradox 19
parties 44, 46–50, 56, 58, 82, 102,
120, 129, 142
pattern 31, 40, 91, 106, 112, 115, 127,
130, 133
Pattern Matrix 106, 112, 115, 127,
130, 133
perspective 2–3, 7, 13, 21, 24–25, 29,
31–32, 40, 44, 55, 86–90, 94,
98, 101, 118–119, 121, 125, 143
phenomenon 41
philosophy 44, 131, 135
physical 45, 126
pivotal 83, 128
place 12, 21, 28, 31, 40, 44, 52, 58–59,
83, 99, 103, 126, 129, 134
policy iv, 35, 123, 129
political 37–38, 55–56, 88, 90, 120,
124–125, 143
political influence 55–56, 88, 90, 120,
124–125, 143
politics 55, 88, 90
poor 16, 30, 34, 57, 60, 83, 91, 94
population 15
portfolio management 21, 23–25, 31
position 23, 83, 89–90, 92, 94–95,
97–99
positive 55, 75, 78, 80, 91, 96, 129, 138
powerful 39
practice 12, 27–28, 90, 103–104, 116,
121, 126, 129, 131–132, 135, 144
prerequisites 128
pressure 28, 56–57, 88–90, 102,
120–121, 124, 143
prevent 19, 31
primary 15, 42, 56
proactive 129
probability 15, 31
problem 14–15, 54, 104, 139
process 4–6, 12–14, 16, 20, 22,
24–27, 29, 35, 37–38, 40–41,
51–52, 59–60, 65–68, 77–78, 89,
91–93, 101–104, 107–119, 126, 128,
131–132, 134–135, 138–143
process success 24–25, 66–67, 77–78,
104, 107–108, 110–112, 114–116,
135, 140–141
processes 4, 6, 13–14, 16, 20, 25–27,
35, 37–38, 40–41, 51–52, 60,
65–66, 68, 103–104, 107–108,
114, 135
produce 6, 22, 26, 37, 66, 94, 131
product success 22, 27–30, 32,
70, 72, 105, 135
professional 7, 18–19, 111
programme 3, 9, 21, 23–25, 29
programme management 23–24
progress 18, 83, 132
project 1, 3, 5–34, 36–60, 62, 64–66,
68, 70–118, 120–155
project complexity 1, 18, 33–34,
36–39, 41–47, 50–55, 57, 59–60,
62, 81–82, 84, 86–88, 90, 92–
101, 116, 118, 120, 126, 136–137,
139–140, 142–143
project duration 44, 47, 82–83,
102, 142
project management 1, 6, 16, 18–21,
23–29, 31–34, 36–37, 42, 44,
46, 51–52, 54, 57, 70, 89, 93,
96, 101–104, 110, 126, 134–135,
139–140, 144
project management success 16, 21,
24–25, 27, 32, 102–104, 110, 126,
135, 139
project method 44, 58
161
Index
project success 1, 6–8, 10, 14–28, 30,
32–33, 44, 62, 64–66, 68, 70,
72, 74–81, 90, 100–104, 106–118,
120, 122, 124, 126, 128, 130, 132,
134–141, 144
project success models 104, 116
project team 25, 28, 36–37, 39,
45–46, 48–49, 51, 54–55, 57–58,
72, 83, 96, 102, 128, 142
promax 106, 112, 115
promise 18
purpose v, 12, 14–15, 44, 107, 110–111
Q
questionnaire 15–16, 104, 116
quite 76
R
ranked 82–99, 123
ranking 82–99
rationale 1, 15, 72
reason 6, 15, 28, 31, 60, 76, 98, 128
relations 29, 48
relationship 15, 17, 35–36, 38, 51, 55,
107–108, 112, 116, 138–139
replacement 12
representation 44
requirements 12–14, 28–29, 35, 37–38,
49, 53, 57, 70–73, 85–88, 94,
105, 116, 128–129, 131, 141,
143–144
research 2, 6, 15, 19–20, 25, 27, 33–35,
41, 59, 68, 104–105, 119, 129, 144
residual 110, 114, 118
resource 12, 20, 26, 32, 35, 39, 46–47,
50–51, 56, 84, 96, 102, 132, 142
resources 20, 26, 32, 35, 39, 46–47,
50–51, 56, 84, 96, 102, 132, 142
respect 135
responsibilities 48
responsibility 5, 48, 50, 137–138
responsible 5, 19, 25, 31, 44
result 22–23, 29, 33, 38, 71, 105, 108,
111, 116, 119, 134, 138
results 4, 6–8, 10, 15–18, 30, 64, 66,
68, 71–76, 78, 80, 88, 105, 108,
110–111, 114–116, 118–119, 122,
162
124, 126–127, 129, 134, 136,
138–139, 144
reveal 119, 127
rigid 98, 111, 125
risk 27–28, 35, 37–38, 49, 54, 57,
85–87, 96–98, 102–103, 121,
124–126, 128–129, 131, 134,
142–143
risk management 27, 85
risks 28, 38, 54, 57, 85–87, 96–98,
102–103, 121, 124–126, 128–129,
131, 134, 142–143, 151
robust 46, 60, 103–104, 129
role 29, 31, 35, 38, 42, 48, 52–53,
55–56, 84, 102, 126, 128–129,
135, 139
root 110, 114, 118
S
safety 47, 96–97, 142
sample 15
scale 16, 21, 32, 37–38, 45, 52–53,
85–87, 96, 98, 105, 128–129, 131,
133–134, 143–144, 149
schedule 11, 27, 50, 57, 82–84, 96–97,
104, 142
science 5, 144
scope 22, 25, 27, 37, 53, 57, 60, 68,
70–71, 77–78, 85–88, 91–96,
98, 103–104, 126–129, 131–134,
140, 143
self 13–14
sending 11
senior 31, 39, 55, 88, 120
sense 3, 93, 111, 132
sequence 12, 15
service 28, 75, 79–80, 104
services 2–3, 18, 57
site 45, 56, 97, 102, 121–123, 125–126,
142–143
skills 14, 27, 35, 39, 46–47, 49, 51, 82,
84–86, 94, 96, 98, 102, 142
social 48–49, 102, 144
soft issues 19
sources 34, 42
South Africa 2–3, 6–7, 9, 144
space 4, 54, 121, 123, 125
Index
specifications 22, 28, 70–73, 85–87,
94, 105, 141
stability 53, 56–57, 88–89, 102, 121,
124–125, 143
staff 30, 39, 55
stage 12, 44
stages 59, 93
stakeholder perspective 87–90,
98, 143
stakeholders 8, 22, 24, 28, 37–38, 46,
48, 50–51, 53, 55, 58–59, 87–90,
96–97, 102–104, 121, 124–125,
129, 137–138, 143
standard 20, 46, 53–54, 59,
128–129, 131, 143
state 2, 140
statement 37
status 45, 50, 55, 102
stories 18
story 20
strategic alignment 9, 26,
31–32
strategic intent 21, 23, 31, 120
strategic level 24, 75, 138
strategic pressure 56–57, 88–90, 102,
120–121, 124, 143
strategic success 16, 22–27, 31–32, 73,
75–78, 101–102, 104, 106, 108,
110–111, 116, 135, 138–141
strategy 6, 9–10, 31–32, 36–39, 66
stress 37, 89, 148
structural equation modelling
(SEM) 107
structure 5, 11, 14, 24, 35, 37,
40–41, 43–45, 48, 58–59,
83–85, 102, 142
study 6, 14–15, 19, 68, 78, 105, 110,
118, 136, 139
subgroups 15
success 1, 5–8, 10, 13–33, 44, 62,
64–68, 70–81, 90, 93–94,
100–118, 120, 122, 124, 126,
128, 130, 132, 134–141, 144
success rates 5–8, 15, 17, 19, 68,
76, 78–80, 138
suffer 34, 54, 90
sustainable 47
symbiosis 1, 17–18, 33, 62, 81, 100–102,
104, 106, 108, 110, 112, 114, 116,
118, 120, 122, 124, 126, 128, 130,
132, 134, 136–137
system 1–2, 5–8, 11–12, 14, 18–19, 30–31,
33–34, 36, 38–40, 42, 44–46,
48, 50–52, 54, 56, 58, 60, 62,
64–66, 68, 70, 72, 74, 76, 78,
80–84, 86, 88, 90, 92, 94, 96,
98, 100–101, 104–105, 121, 128,
135–138, 142, 144
T
tactical level 24
tailor 140
tandem 51, 85
task 14, 20, 25, 34, 37, 40, 44–45,
47–50, 53–54, 58, 82–87, 96,
98–99, 103–104, 127–129, 131,
133–134, 142–143
team 14, 25, 27–28, 36–37, 39–40,
45–49, 51–52, 54–58, 72, 83,
95–97, 102, 128–129, 142, 144
technical complexity 16, 41–43, 52–54,
57–58, 60, 81, 84–87, 96–99,
101–103, 126–128, 130–134
technical processes 25–27, 65–66
techniques 20, 22, 36, 116
technological complexity 34, 52
technology 1–3, 5, 8–9, 14, 30, 34–37,
39–40, 52, 54, 58–59, 78–79,
85–87, 95–99, 103, 127–128,
131–132, 134, 140, 143
terms 14, 26, 41
time 1, 4–5, 11, 16, 19–20, 22–23, 25,
34–35, 37, 39–41, 44, 48–49,
52, 57–58, 60, 64, 66, 68, 70,
72, 77–78, 83–85, 87, 91–95,
99, 103, 128–129, 131, 134, 143
tool 21, 39, 44, 100, 103, 128
tools 20–22, 36–37, 41, 44, 142
total 2, 8–9, 22, 60–61, 81, 119,
122, 124, 126, 130, 132
track 32
traditionally 33, 39, 47, 55
trained 72
training 4, 21, 28, 30
163
Index
transfer 36
transform 26, 38
transformation 26, 30–31
translate 47, 49
translated 7
transparency 50
travel 46
trend 15
triple 20, 22, 27, 57, 68, 70, 80,
93–94, 103, 143
triple constraint 20, 22, 27, 57, 68,
70, 80, 93–94, 103, 143
trust 49, 59, 102, 142
truth 70
U
uncertainty 11–12, 16, 34, 37, 41–43,
57–60, 81, 93–95, 101, 103,
126–134, 140, 143
uncover 70
understanding 14, 34–35, 41, 45–50,
52, 54–55, 58, 62, 82, 84,
87–89, 94, 99, 118–119, 140
unintended benefits 74–75, 107, 141
unintended impacts 74–75, 111, 141
unknown 47, 107–109, 112–113, 117, 129
unpacks 16
unpredictable 35
upgrade 1–2, 4, 12, 64–65
V
valid 110–111, 115–116, 118
validate 119, 136
valuable 102, 116
164
value 2–8, 10, 20, 22, 28, 32, 89, 111,
116, 119, 127, 138, 140, 144
values 107, 119, 122, 124, 126
variable 100, 105–107, 111–112, 115–116,
120, 122, 124, 127, 130, 133,
141–143
variance 27, 119, 122, 124, 126,
130, 132
variations 12, 136
venture 38, 48, 142
view 15, 24, 27, 29, 41, 86, 89, 94–95,
97, 99, 101, 103, 111, 131–132,
139, 144
viewed 32, 55, 100, 135, 139, 144
views 41, 43, 55, 84, 86–87, 90, 92,
99, 101, 126
virtues 25
vision 53
visual 5
vital 44
vitally 135
W
Waterfall 12–14, 16–17, 62, 64–68,
70–79, 83–84, 86–87, 89–90,
92–93, 95, 98–99, 105, 111–116,
118–119, 124–126, 132–135, 138
weakness 35
win 25
wisdom 140
wise 140
working 11, 13–14, 48, 98
world 2–3, 100
written 18
