Eindhoven University of Technology

MASTER

Managing project complexity

developing tools for practice through design science research

Swinkels, E.

Award date:
2016

Link to publication

Disclaimer
This document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Student
theses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the document
as presented in the repository. The required complexity or quality of research of student theses may vary by program, and the required
minimum study period may vary in duration.

General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
• You may not further distribute the material or use it for any profit-making activity or commercial gain
 Eindhoven, August 2016

Managing Project Complexity:

Developing tools for practice
through design science research.

By Erwin Swinkels

Bachelor Mechanical Engineering (2012)

Student identity number: 0761980

In partial fulfilment of the requirements for the degree of

Master of Science
In Innovation Management

Supervisors:
Dr. ir. B. Walrave, TU/e, ITEM
Dr. A.A. Alblas, TU/e, ITEM
Ing. A. Haverkort, Company X
TUE. School of Industrial Engineering
Series Master Thesis Innovation Management

Subject headings: systems theory, complexity theory, uncertainty, ambiguity, project

management, complexity management, project development, project performance, case
study, design science research, theory building

ii
Abstract
Within the field of project management, researchers have continuously searched for improved
methods to successfully deliver challenging projects. As projects have become larger and more
elaborate, planning for the many potential uncertainties within a project has become increasingly
more difficult. By considering the relationships between risk, uncertainty and complexity, a set of
project management tools are proposed that provide a more comprehensive understanding of the
particular challenges of complex projects.

Complex projects face two major challenges. First of all, complexity induces unpredictable behavior in
the project. When parts of the project are uncertain, the overall uncertainty of the project multiplies
as different parts of the project interact. Secondly, complexity limits the ability of stakeholders to
foresee and manage the project. While project managers and team members utilize tools such as
project plans, schedules, work packages and task descriptions to break down the project into more
easily understandable parts, it is likely that at some point particular interactions between parts of the
project are ignored or simply not noticed. A project can become so large that it is effectively impossible
for a single project member to understand all the detailed interactions between the many parts of the
project. The combined challenge of project complexity is thus that the project itself is less predictable;
and that it is more difficult for stakeholders to understand the project in its entirety in order to manage
the project correctly.

Project complexity can be managed by either removing the sources of complexity or by reducing their
impact. However, the first response should be the active selection of complex projects. A second
response to manage the inherent project complexity is to consider the project staffing. Project
complexity stems from the collective behavior of the project system. It is therefore useful to consider
the effects of different project management approaches on the project system as a whole. The initial
phases of a project are typically dedicated to the exploration of the project scope and the development
of an appropriate project structure. Effectively, the project complexity is inherently designed into the
project as a result of the project’s definition. Due to the sensitivity of the project system to its initial
conditions, the most effective method to manipulate the project complexity is to consciously design
the project such that the initial project complexity is in line with the desired project complexity.

iii
Preface
Having spent the last year working on this master thesis project, it feels good to write this chapter and
finally finish up both my report and my masters study. To spare both you from reading more text, and
me from writing it, I figured I’d try to get to the point quickly. In hindsight the scope of the thesis might
have been a bit ambitious, but it was a great joy and challenge to dive down the rabbit hole that is the
study of complexity. I spent a considerable time studying various streams of literature, which over time
certainly took its toll on me. The continuous support of my supervisors, friends and family was always
a great source of both motivation and inspiration, and as such it appears more than appropriate to
take a moment to thank the many people that helped me.

Since the first meetings I had with my first supervisor, dr. Bob Walrave, I was given freedom were
desired and support were needed to conduct my master thesis project. I feel lucky for the many
discussion sessions we had together with my company supervisor, Andre Haverkort, which always
resulted in new insights and were a great source of motivation.

Additionally I would like to thank Madis Talmar for his involvement and help in the early phases of my
project, and for introducing me to Andre in the first place. I would also like to thank dr. Alex Albas, my
second supervisor, whose insights and critics were always a valuable source of feedback on my work.

I would furthermore like to thank my parents, my brother and my friends for their continuous support;
but also primarily their often much needed distractions to keep me sane. Finally, I would like to thank
my cats for not deleting my working during the many times they walked over my keyboard while I was
working.

Erwin Swinkels

Eindhoven, August 2016

iv
Management summary
Within the field of project management, researchers have continuously searched for improved methods to
successfully deliver challenging projects. As projects have become larger and more elaborate, planning for the
many potential uncertainties within a project has become increasingly more difficult. By considering the
relationships between risk, uncertainty and complexity the project team may be able to expose the
fundamental causes of potential problems earlier in the project lifecycle.

Complex projects face high levels of both uncertainty and ambiguity.

Complexity management considers how the different parts of a project interact and how these interactions
should be managed such that the project can embrace the opportunities resulting from the complexity while
limiting the risks. Complex projects face two major challenges;

1. Project Complexity induces unpredictable behavior in the project. The more complex a project is, the more
connections exist between the different elements. When one element is uncertain, it is likely that the
connected elements will also become more uncertain. As more elements interact, the behavior of the
project becomes less and less predictable.

2. Project Complexity induces ambiguity (a lack of clarity) which limits the ability of stakeholders to foresee
and manage the project. While project managers and team members utilize tools such as project
schedules, work packages and task descriptions to break down the project into more easily
understandable parts, it is likely that at some point particular interactions between parts of the project
are ignored or simply not noticed. A project can become so large that it is effectively impossible for a single
project member to understand all the detailed interactions between the many parts of the project.

The combined challenge of project complexity is thus that the project itself is less predictable; and that it is
more difficult for stakeholders to understand the project in its entirety in order to manage the project
correctly.

Managing project complexity requires more than a single strategy.

The initial phases of a project are typically dedicated to the exploration of the project scope and the
development of an appropriate project structure. A project’s complexity results from the project composition,
as such, the project complexity is inherently designed into the project as a result of the project’s definition.
The most effective method to manipulate the project complexity is to consciously design the project such that
the initial project complexity is in line with the desired project complexity. While simply put, the project
complexity can be managed by either removing the sources of complexity or by reducing their impact, several
strategies may be considered;

1. The active selection of complex projects. By estimating a project’s complexity before taking on a particular
project, the fit between the project and the organization can be considered. When a mismatch occurs, the
organization should deliberately decide to either proactively change the project’s composition, kill the
project or to continue as planned while consciously accepting the inherent risk of the project.

2. The selection of appropriately skilled project staff. When a project is particularly complex on one
dimension of project complexity, and the project manager lacks the appropriate skills and experiences to
manage the complexity of that dimension, it becomes more likely that the negative effects of that
dimension are underestimated and consequently poorly managed.

3. The selection of an appropriate project methodology. Project complexity stems from the collective
behavior of the project system. Since most management methodologies effect the project as a whole, the
choice of management method can have a considerable impact on a project’s complexity.
v
 Each project management methodology has its strengths and weaknesses.
Since project complexity stems from amongst others the interactions between the elements of the project,
the chosen project management methodology may heavily influence a project’s ability to manage the inherent
complexity. Drawing from the extensive research on the management of complex development projects by
Adler (1999), three general approaches to manage complex projects are described in the literature.

1. Managing complexity by removing interdependencies; The dominant approach discussed in both

literature and practice is an ‘approach based on planning.’ It is assumed (although potentially incorrectly)
that the overall project can best be managed by separating the aspects of uncertainty from the aspects of
complexity. Uncertainty is best managed by rigorous planning, while complexity is best managed by
breaking the project down into small and easily controllable parts. Specialized resources are best able to
execute tasks when the work is as independent from other influences as possible, the resulting subsystems
should only be integrated once they are considered stable.

2. Managing complexity by managing interdependencies; The second approach proposed by Adler (1999)
was developed in response to the increasing need to develop projects with shorter lead times. The
approach based on ‘integration-driven development’ has fundamentally different assumptions regarding
the management of project complexity. Complexity is managed by identifying the most troublesome
interfaces between tasks and allocating the most skilled resources to these boundaries. Uncertainty is
managed by configuring the product and project such that uncertainties are identified early and relevant
resources are allocated to monitor them. Control over the project is achieved by continuously integrating
the subsystems of the product and testing their functionality, thereby verifying the functionality of the
respective subsystems.

3. Managing complexity by embracing interdependencies; The third project management approach

described by Adler (1999) is based on what is described as ‘dynamic synchronization’. The approach
emphasizes speed and embraces flexibility and complexity. One of the core assumptions is that actors
perform best under complexity when they are able to see the whole picture. Responsibility should be
distributed across the project, providing the means to handle uncertainty in real-time to all actors.
Interdependencies should be encouraged and build as they provide control and distribute responsibility
for set targets. Projects are managed by providing as many actors as possible with the complete complexity
of the project.

Within the literature, several authors have argued that a planning based approach (1) is more appropriate to
handle very large projects in stable environments. By breaking down the product, an overview of the project
is maintained despite the scale of the project. By delaying integration however, the project becomes more
susceptible to changes in the project system, as faults are noticed much later, resulting in larger amounts of
rework ultimately delaying the project. The Integration driven development approach (2) is argued to be more
appropriate to handle projects where the lead-time and the time of delivery are sacred. The parallel
development and testing of the product allows for earlier integration and a more flexible response to project
changes. The project also required more autonomous and highly skilled project members, is more likely to
induce stress and burn-out and often requires more resources simultaneously. Finally, the approach based on
dynamic synchronization (3) requires the project team to constantly balance on the edge of chaos, as changes
in the project occur frequently and project members often have to respond to emerging events and
opportunities. As a result, the dynamic synchronization approach is most suitable for projects exposed to large
and continuous changes in requirements.

vi
 To manage project complexity, a thorough understanding of the project is required.
The majority of literature on project complexity utilizes systems theory to analyze projects. By analyzing the
project as a system, the concepts of systems theory can be adopted to explain the project’s behavior.
Particularly complex systems are best studied through the behavior of their subsystems. For the purposes of
this thesis, the project system has been separated into four subsystems. The Inter-organizational system and
the social system capture the communication between organizations, departments, work teams and project
members respectively. The system of scope and the product service system in turn describe the relationships
between the project’s goals, deliverables, requirements, work processes, components and modules.
Additionally, the project’s business environment and the socio-political system describe the behavior of
outside influences such as market forces, laws and regulations which impact the project system.

According to systems theory, the complexity of a system is dependent on the number of elements in the
system, the number of relationships between the elements in the system and the organization and behavior
of the relationships. To methodically describe the relationships and behavior of the elements in the previously
described subsystems; the size, variety and interdependencies within each subsystem were analyzed. The size
effectively captures the number of elements and relationships, while the variety and interdependencies within
the subsystem capture the nature of the relationships. Project complexity within this research has been
defined as: “the accumulated effect of the interactions between the many varied interrelated parts of a
project, which causes unpredictable behavior in the project and inhibits project member to form accurate and
reliable mental models to understand, foresee and manage the project system’s behavior, even when given
reasonably complete information about the project system.”

Different stakeholders may perceive the project differently and as a result may have different interpretations
of the project’s complexity. If project members are less familiar with the project, it becomes harder to correctly
estimate the project system complexity. The ‘perceived’ project complexity is a result of the real project
complexity which is observed through the past professional - and personal experiences of the reviewer. While
the ‘real’ project complexity induces uncertainty, ambiguity and results in emergent behavior, the under – or
overestimation of the perceived complexity may result in further ambiguity as the project is misrepresented.

As projects are executed over time, the project’s sub-systems may change drastically. Dynamic changes within
a project can be seen as changes to the sub-systems, which in turn effect the overall project complexity. When
analyzing project complexity, it is thus important to consider whether the project will change over time and
whether the currently chosen contingencies fit both the current – and expected project complexity.

A toolbox for complex projects

Project complexity can best be managed when the project organization ensures that the desired project
complexity is in line with the actual project complexity. A set of tools has been developed which provide both
researchers and managers with the means to determine the project complexity, reflect upon the causes – and
effects of complexity and help determine an appropriate management reactions. Utilizing these tools, project
managers are enabled to reflect upon their projects and consider the applicability of particular strategies to
manage the complexities of their respective projects.

This new toolbox integrates a large variety of insights from the literature on project complexity and as a result
provides a much more comprehensive analysis than previous frameworks. Each of these tools has been
developed with considerable support from the literature, while also recognizing the different needs of both
scholars and practitioners. Since each project is unique, it is difficult for the literature to suggest one particular
strategy over another. But with the tools and insights presented in this research, project managers are enabled
to critically reflect upon their projects and to determine the most suited methods for their projects.
vii
Table of Contents

Abstract ............................................................................................................................................................................................................. iii

Preface ............................................................................................................................................................................................................... iv
Management summary.......................................................................................................................................................................................v
Table of Contents ............................................................................................................................................................................................. viii
List of Figures ..................................................................................................................................................................................................... ix
List of Tables ...................................................................................................................................................................................................... ix

1. Introduction ............................................................................................................................................................................................ 1
1.1 Research background – Embracing practice ................................................................................................................................. 1
1.2 Research objective(s) – Developing a holistic view on the management of project complexity .................................................. 2
1.3 Research scope – Exploring project complexity in all its depth .................................................................................................... 3
1.4 Research deliverables – Developing a toolbox ............................................................................................................................. 5
2. Research design ...................................................................................................................................................................................... 6
2.1 Methodological foundation – borrowing from design science, action research and grounded theory ........................................ 6
2.2 Methodology – a series of investigative research cycles .............................................................................................................. 8
2.3 Methodological Cycle ................................................................................................................................................................. 10
2.4 Model Development Cycle ......................................................................................................................................................... 10
2.5 Instrument Development Cycle – Theoretical cycle ................................................................................................................... 11
2.6 Instrument Development Cycle – Practical cycle........................................................................................................................ 11
2.7 Project Profile Development Cycle ............................................................................................................................................. 12
2.8 Project Complexity Management Cycle...................................................................................................................................... 12
3. Towards a model of project complexity ................................................................................................................................................ 13
3.1 Defining project complexity through unpredictability and ambiguity ........................................................................................ 13
3.2 The paradox of perceived complexity ........................................................................................................................................ 15
3.3 Exploring the project system ...................................................................................................................................................... 16
3.4 Size, variety and interdependence – the antecedents of project complexity ............................................................................. 18
3.5 Uncertainty, ambiguity and emergence – the consequences of project complexity .................................................................. 19
3.6 Developing a theoretical & mathematical model ....................................................................................................................... 20
4. Quantifying project complexity - a dual perspective ............................................................................................................................. 25
4.1 A novel framework for research ................................................................................................................................................. 25
4.2 A novel framework for practice .................................................................................................................................................. 32
5. Managing project complexity – Exploring strategies & methods .......................................................................................................... 38
5.1 Project complexity management approaches – a general overview .......................................................................................... 39
5.2 Project complexity management approaches – strength and weaknesses ................................................................................ 45
5.3 Reframing popular project management methods. ................................................................................................................... 47
5.4 Managing project complexity in practice ................................................................................................................................... 50
5.5 Understanding complexity management ................................................................................................................................... 58
6. Conclusions, limitations and recommendations ................................................................................................................................... 61
6.1 Conclusions ................................................................................................................................................................................ 61
6.2 Research contributions .............................................................................................................................................................. 66
6.3 Limitations.................................................................................................................................................................................. 67
6.4 Directions for future research .................................................................................................................................................... 71

References ....................................................................................................................................................................................................... 74
Appendix A – Project subsystems .................................................................................................................................................................... 78
Appendix B – Antecedents of project complexity ............................................................................................................................................ 80

viii
List of Figures

Figure 1: Core knowledge development cycle. ....................................................................................... 8

Figure 2: Research cycles......................................................................................................................... 9
Figure 3: Formal model of Project Complexity. ..................................................................................... 22
Figure 4: Inter-organizational Complexity. ............................................................................................ 26
Figure 5: Social Complexity. .................................................................................................................. 27
Figure 6: Complexity of Scope. .............................................................................................................. 28
Figure 7: Product Service Complexity.................................................................................................... 29
Figure 8: Social-political Complexity. .................................................................................................... 30
Figure 9: Complexity of the Business Environment............................................................................... 31
Figure 10: Baseline project complexity framework............................................................................... 34
Figure 11: Overview of project complexity estimates........................................................................... 50
Figure 12: Dendrogram Complete linkage hierarchical agglomerative clustering algorithm ............... 54
Figure 13: Agglomeration Schedule Coefficients. ................................................................................. 55
Figure 14: Cluster centroids and memberships. ................................................................................... 56
Figure 15: Complexity Management ..................................................................................................... 59
Figure 16: Project complexity assessment framework. ........................................................................ 68
Figure 17: Model of Complexity ............................................................................................................ 69
Figure 18: Comparison of project complexity management approaches ............................................. 70
Figure 19: Dynamic Complexity Analysis – Probability Mass Functions................................................ 72
Figure 20: Dynamic Complexity Analysis – Histograms. ........................................................................ 73

List of Tables

Table 1: Pragmatic Project Complexity Assessment framework. .......................................................... 37

Table 2: Descriptive statistics of project complexity. ............................................................................ 51
Table 3: ANOVA analysis of integration-driven approach vs. planning-based approach...................... 51
Table 4: Multicollinearity cluster variables. .......................................................................................... 53
Table 5: ANOVA - Nr. Participants & Clusters. ...................................................................................... 57
Table 6: Post Hoc Tests - Nr. Participants & Clusters. ........................................................................... 57
Table 7: A structural comparison of the three approaches. ................................................................. 60
Table 8: Dimensions of project complexity in literature. ...................................................................... 79

ix
 1. Introduction
1.1 Research background – Embracing practice to improve relevance
Historically the social sciences have suffered from a ‘relevance gap.’ Published academic literature is
criticized for lack of practicality, an overemphasis on theory and overly complex research designs and
analyses. The emphasis on abstract theory and rigorous methods ensures rigor at the cost of practical
relevance. While time pressures may furthermore narrow the research scope and influence sample
size and data collection decisions, promoting convenience rather than appropriateness.

To close the relevance gap, authors such as Rynes & McNat (2001) and Mesny & Mailhot (2012) note
the importance of collaboration between researchers and practitioners. Similarly, Hackman (2003) and
Rousseau et al. (2008) advocate that scholars become more exposed to both practitioners and field
conditions, which would add additional depth to existing constructs and theories. To bridge the gap,
knowledge transfer between scholars and practitioners is crucial (Gladwell, 2000; Wenger, et al.,
2002). Additionally, the epistemology of the researcher also plays a role in the debate1. While the
relevance gap arose with positivistic epistemologies prevalent, the more recent emergence of critical
realism has changed the debate. Critical realism accepts that all methods have limits and instead
advocates the use triangulation across methods of data collection and analysis to generate knowledge
(Hackman, 2003, Rousseau et al., 2008, Bhaskar, 1998 and van de Ven, 2007).

Several barriers however may still remain and inhibit practitioners to access, interpret, or implement
research findings. Johns (1993) for example mentioned that researchers often fail to mention the
specific context of their research, making it more difficult for organizations to determine whether a
particular piece of research is relevant for their situation. Organizations rather benchmark themselves
against competitors to find new practices, since these practices are proven to work in their context.

A gap in the literature may often be used as inspiration for a new research angle. The risk here however
is that the resulting research may be highly academic and suffer from a lack of relevance. Thus for this
thesis the decision was made to first search for an organization interested in strategic management
research as a whole, and to then write a research proposition based on their particular challenges.

The case company in question can be described as a medium sized Knowledge and Innovation
Community with offices across Europe, although the main office is located in the Netherlands. The
organization’s primary aim is to ‘achieve a sustainable energy future for Europe’, which the company
aims to realize through education, collaborative innovation projects and business creation services.

The primary focus of this research are the collaborative innovation projects which the case
organization supports by accelerating start-ups and ventures with the organization’s vast network of
partners, resources and knowledge. The case organization partners with start-ups and ventures to
create consortia with additional complementary partners to develop and commercialize new product
service offerings through collaborative projects. Example would be the development of a new solution
to extract power from waves, or the development of a magnetic trust bearing which will enable the
storage of hydroelectric mechanical energy.

Before supporting the projects however, the case organization scans each project submitted in a
formal ‘call for innovation proposals’ process. During this process, potential projects are assessed on
a series of criteria to be accepted or rejected. Despite the organization’s thorough selection process,
it is possible that projects are selected which ultimately struggle to succeed. Additionally, there is

1
For the purpose of this thesis, the research took a critical realist perspective. See chapter 3.2 for a partial
discussion on the influence of the critical realist perspective on the study of project complexity.

1
another possibility that projects are rejected which would have been successful if accepted. In other
words, during the screening process, the case organization may make either a Type-I error (a false
positive) by supporting a difficult project, or a Type-II error (a false negative) by rejecting a project
which could have been successful. It is thus in the interest of the case organization to continuously
improve the project screening process to reduce both of these kinds of errors.

One of the tools the organization recently introduced to aid in the assessment of projects was a project
complexity assessment framework. The purpose of this framework was to assess the complexity of a
given project, based on the project plan, such that a project complexity profile could be generated.
This project complexity profile would provide insight into the challenges faced by the project and as
such ultimately aid the assessment of the project.

1.2 Research objective(s) – Developing a holistic view on the management of project complexity
While the project complexity assessment framework was based on the extensive experiences of a set
of project managers, several points of critic limit the potential usage of the framework. The framework
was primarily based on the experiences and opinions of project managers. A literature review was
effectively not performed. Instead, some aspects of literature were used when the project managers
were already familiar with them, but no additional searches were executed. As a result, the theoretical
foundation of the current framework is rather limited. While this may be less of an issue for
practitioners whom want a framework which is easily useable, the lack of theory also limits the
potential use of the framework.

The current framework provides an estimate of the project complexity based on a set of factors from
practice. It is however possible that some important aspects of project complexity were missed,
resulting in a false sense of confidence in the assessment. Additionally, the framework currently does
not provide an analysis of the fit between the project complexity, and the chosen methods to deal with
the complexity. It is likely that the literature could provide insight into the methods that project
managers could utilize to deal with project complexity.

A broad set of alternative project management tools and strategies are available. Risk management
may be considered as one of the earliest formal project management techniques. Risk management
aims to capture all the potential events that may negatively influence a project’s outcome or execution
and establishes either reactive or proactive strategies to manage these risks. For each event, the
likeliness of occurrence and impact on the project are considered to determine appropriate reactions.
Uncertainty management was introduced as an extension of risk management. By considering
different types of uncertainty’s such as variation, chaos, foreseen - and unforeseen uncertainty,
authors such as Pich et al. (2002) have proposed alternative management styles depending on the
uncertainty’s faced by the projects. Complexity management may now be considered as another
extension of risk management.

By considering the relations between risk, uncertainty and complexity, project managers may have a
more complete understanding of the particular challenges of a given project. While the knowledge of
risk – and uncertainty management are well developed and assimilated within the project
management profession, the knowledge of project complexity is less advanced and understood. The
development of a project complexity management assessment framework would thus be beneficial
for both the case company in particular, and for the profession of project management in general.
Based on this understanding, a problem description can now be established for the perspective of the
case organization: “The case organization requires a set of tools to measure and analyze the complexity
and respective complexity management methods of a project plan during the call for projects such that
the inherent project complexity and fit of management methods can be taken into account to

2
minimalize type I type II errors when determining whether to accept or reject to support a particular
project, and helps determine appropriate complexity management interventions and strategies.

To know how to manage project complexity, one must first be able to measure and understand project
complexity. As such it is expected that a set of tools must be developed, rather than a single solution.
However, the final goal of these tools is to improve the management of complex projects. As such, the
primary research question relates to the management of complexity: “How can project complexity be
managed?

Complexity has been studied in the context of project management for several decades, yet there still
exists a considerable lack of consensus on how complexity should be described or analyzed. Sinha et
al. (2001) for example notes that there not a single definition of complexity which is comprehensive
enough to capture all aspects of the concept. Furthermore, our understanding of complexity may be
heavily influenced by the frameworks we use to describe it. As Simon (1996, p109) considers: “there is
no conservation law that requires that the description be as cumbersome as the object being
described. How complex or simple a structure is depends critically upon the way in which we describe
it.” Finally, many sources may contribute to the complexity of a project which has made the analysis
of complexity in the context of project management a challenge in itself (Qureshi et al., 2015). As such,
a secondary theoretical problem description must be faced by the research: “Project complexity as a
concept is often used but also rarely understood, many different definitions and interpretations are
available resulting in difficulties when discussing the topic.”

Based on this problem description, a secondary research question must first explore the concept of
project complexity from a theoretical point of view to provide a theoretical foundation for the primary
research question, resulting in the following secondary research question: “What is project
complexity?”

1.3 Research scope – Exploring project complexity in all its depth

The research thus investigates two major issues, through a literature study and a philosophical
discussion, the role of complexity in projects is investigated. To assist in this discussion, a secondary
research question, “What is project complexity”, is first examined with the aid of four sub-questions.

Depending on the researcher’s epistemology, one might have different assumptions regarding the
ability to objectively measure a particular research objective. This subject will be explored through the
sub-question: “Can project complexity be objectively measured?” By considering the existence of both
real – and perceived complexity, the nuances of the concept of complexity may be explored while also
providing insight into the challenges regarding a reliable and valid measurement as a result of different
perspectives.

Project complexity has previously been defined as the property of a project which makes it difficult to
understand (Wozniak, 1993), and in terms of the factors that contribute to project complexity
(Baccarini, 1996). While both definitions are useful, both can also be criticized. By defining project
complexity as a property which limits project members’ understanding of the project, the concept
provides insight into the effects of project complexity, but is also by definition subjective and
depending on the observer’s perspective and knowledge. By defining project complexity in terms of
the factors contributing to complexity, the conceptualization of project complexity supports the
objective measurement of project complexity independent of individual perspectives. To be able to
define, understand and use the concept of project complexity, it is thus also important to explore both
the antecedents – and consequences of project complexity. The research will thus also explore the two
following questions: “What are the antecedents of project complexity?” and “What are the
consequences of project complexity?”

3
Having reviewed the concept of project complexity, the study will further consider how project
complexity can be measured and managed in response to the primary research objective: “How can
project complexity be managed?”

In order to analyze the fit between a project’s complexity, and the chosen project management
approach, a valid and reliable measurement of project complexity is required. A preliminary review of
the literature on project complexity found that several authors have attempted to provide assessment
frameworks for project complexity, e.g. Bosch-Rekveldt et al., 2011, Vidal et al., 2011 and Maylor et al.
2013. Many of the items listed in these articles are difficult to interpret, and only one study provided
some guidance on the actual use of the framework (Maylor et al. 2013). The research will explore the
sub-question: “How can project complexity be measured in scholarly research?”. By developing a
project complexity assessment framework specifically for the purpose of scholarly research, a
framework can be generated which is structured, grounded in literature, based on a clear theoretical
model, with unambiguous items and well defined response scales. By basing the assessment
framework on a clear theoretical model, any implicit assumptions are clarified while also improving
the validity of the survey. By defining a set of response scales the new framework will further improve
its reliability over previous tools.

For scholarly research, a broad and in-depth assessment framework is desirable to capture the many
aspects of project complexity. For the sake of practice however, such a framework might be less useful.
Since practitioners might be less familiar with abstract concepts and have less time to conduct an
analyses, a simpler assessment framework would be more beneficial. Practitioners however still
require a valid and reliable method to measure project complexity. By recognizing the differences
between researchers and practitioners, it becomes clear that a second assessment framework is
needed specifically developed for practice. The sub-question: “How can project complexity be
measured in practice?” attempts to solve this issue.

Having established a method to measure the project complexity, the research must next consider how
project complexity may be managed. Projects are often defined amongst other factors by their unique
nature (Atkinson, 1999). However, while projects are considered unique, many projects share similar
project management methods. As the project management profession has professionalized, many
different project management methods have been developed to help guide organizations towards
successful project execution. Project managers have been able to adopt best practices from other
projects and organizations based on the assumption that despite the unique nature of projects, groups
of projects may be similar enough for project managers to collectively share best-practices between
projects. The analysis of project complexity might be a useful method to extract project profiles which
can be compared in terms of project complexity. The study will review the project portfolio of the case
organization to answer the sub-question: “Are there different project Arche-types in terms of
complexity within the case-setting?”

Geraldi (2009) amongst others notes that project complexity is both partly inherent and partly self-
induced by project managers and companies. Geraldi advises that managers and organizations should
actively shape the project complexity throughout the project lifecycle. Inherent complexity is typically
the result of decisions out of the control of the project team and is instead controlled by the over-
arching organizations. Self-induced complexity is instead the result of the decisions of the project team
and project manager. Depending on the authority given to the project team, the inherent – and self-
induced complexities faced by different project teams and organizations may vary. It is however useful
to consider how both project teams and project organizations can shape projects, as such the following
sub-question will be investigated: “Are there different strategies to influence inherent and self-induced
project complexity?”

4
As mentioned, many different project management methods exist that project managers may utilize
in the execution of their projects. While there is often some inherent complexity in a project, a part of
the project complexity may also be caused by the project management method chosen by the project
manager. It is thus important for the project manager to consider the influence of a given management
method and as such the thesis will investigate this issue with the following research question: “What
are the effects of different project management methods on project complexity?”

Having studied both the Arche-types, complexity management strategies and project management
methods available to project teams, the question remains which strategies and management methods
should be used in which project contexts to provide a final answer to the research question. A final
sub-question will thus investigate the relation between project complexity and project management:
“Is there an ideal fit between project complexity and project management?”

1.4 Research deliverables – Developing a toolbox

The research project aims to develop four core research deliverables to support the two main research
questions. First a theoretical foundation must be established through a clear definition of project
complexity, supported by a project complexity model which explains the antecedents – and
consequences of project complexity. The model will further elaborate the differences between real –
and perceived complexity, and the relation between uncertainty, ambiguity and complexity.

Having established a conceptual groundwork, the thesis will provide a survey to measure project
complexity based on the theoretical model previously discussed. By explicitly supporting the
measurement survey with a theoretical model, the new survey provides a more structured method to
measure project complexity.

Recognizing the different needs of both researchers and practitioners, a second project complexity
survey was developed to provide a much simpler and faster tool for project managers. This second tool
is less dependent of abstract definitions and consists of less elements. As a result, the survey is both
faster and easier to use but also has less explanative power. By considering only the most influential
drivers of project complexity however, a balance was struck between ease of use and explanative
power.

Since the purpose of the study was to provide guidance on the assessment of project complexity, the
final deliverable is a framework that provides insight into several approaches to manage inherent –
and self-induced project complexity. And provides insight into which context these approaches are
most applicable by describing a set of project Arche-types in terms of complexity and in terms of core
project characteristics.

The four core research deliverables are supported by four additional deliverables that aid in the
presentation of the research. The master thesis report, presentation and poster help explain the
development of the research contributions in various levels of detail. For practitioners in particular, a
flyer will be created to help guide the usage of the measurement and management of project
complexity.

5
 2. Research design
Having established the research objectives, main research questions and subsequent sub-questions,
the following section will describe how the different research questions will be studied. Since the study
will investigate several distinct but also inter-dependent research questions, the research will adopt
different methods to study different topics.

2.1 Methodological foundation – borrowing from design science, action research and grounded
theory
Simon (1969) introduced the ‘design science’ perspective as an alternative for research in the social
sciences. Simon did not just propose a different methodology, but rather a different mode of research,
as he proposed to make a distinction between the natural sciences and the ‘sciences of the artificial’.
While the natural sciences develop knowledge regarding natural objects and includes fields such as
physics, chemistry and biology, the sciences of the artificial develop knowledge regarding man-made
objects. Examples of the sciences of the artificial would be medicine, engineering and law. Where the
natural sciences traditionally focus on explanation, the sciences of the artificial focus on improvement
and prescription.

Several more recent authors have argued that the management sciences should be considered more
as a ‘science of the artificial’ and less as a ‘natural science’. The term design science, inspired by Simon’s
sciences of the artificial, was adopted as a result (van Aken, 2007). Romme (2003) proposes to adopt
design as a third mode of research besides science and the humanities. Drawing from Simon (1996),
the author explains that design aims to improve rather than explain. Focused on prescription, a design
approach aims to change existing systems and situations into preferred states. Rather than asking
whether knowledge is valid or true, the emphasis is placed on the generation of knowledge which is
both actionable and open to validation. Recognizing that each situation is unique, design knowledge
attempts to provide general prescriptions for classes of problems through design propositions.
Research objects are man-made with potentially vaguely defined properties. The research output from
design research is ideally an integrated design of propositions for either a specific case or a class of
problems generated through an iterative process of abductive and deductive reasoning

Due to the dual research objectives of this study, the final methodology of the research borrows
research methods from several previously developed research methodologies. Two methodologies in
particular are often mentioned to align with many of the principles of DSR. Puraeo et al. (2008) for
example highlights the use of both action research – and grounded theory techniques by students of
DSR. Cole et al. (2005) and Papas et al. (2012) both reflect upon the interactions between AR and DSR,
while Gregory (2011) considers the complementary usage of DSR and grounded theory.

‘Grounded Theory’ as introduced by (Strauss & Glaser, 1967) may be one of the earliest attempts to
improve qualitative research methodologies. Grounded theory is a research methodology that
advocates that researchers enter the field without preconceptions to extract theory from for example
observation and interview sessions with a broad scope of practitioners focused on a practice-based
problem. Through intense collaboration and potentially coproduction, a grounded theory emerges
that may then be integrated into the broader theoretical body of knowledge. Grounded theory thus
enables the researcher to develop a theory which provides an explanation of the main problems faced
by practitioners within a certain topic.

Historically, grounded theory has been prevalent in the social sciences, although its techniques may
be applied in any research area with any type of data. Grounded theory offers guidance on data
collection (case selection, data gathering, etc.) and data analysis. Both qualitative and quantitative
data may be used, although interview data appears to be the norm. While grounded theory is

6
considered a methodology in itself, the resulting theory generated from this process is often also
referred to as a grounded theory. While grounded theory involves intense collaboration with
practitioners and often also includes knowledge transfers between practitioners and scholars, the
overall emphasis of the method remains on the generation of theory.

An alternative popular research methodology within the social sciences is ‘action research.’ First
described by Lewin (1946) and later in more detail in Lewin (1951), action research aims to solve
practical problems by generating empirical knowledge through the testing and evaluation of a set of
interventions. Lewin developed the methodology at the Research Centre for Group Dynamics at the
University of Michigan as a means to study social psychology within the field (c.f. Baskerville and
Woodharper 2016).

The most common characterization of action research however may be found in Susman and Evered
(1978). The authors note that before the research can begin, first a client-system infrastructure must
be established. As part of action research, researchers are actively changing the object of study. The
client-system infrastructure is essentially a set of agreements which provide authority to the
researchers and practitioners, or potentially place sanctions and limitations on the actions the
participants may take. The agreement further limits the scope of the research and defines the
responsibilities of both the researchers and the practitioners. Based on the client-system
infrastructure, the research is initiated and execution through the iterative implementation of
diagnosing, action planning, action taking, evaluation and learning phases (c.f. Baskerville and
Woodharper 2016).

Action research involves intense collaboration with practitioners and includes knowledge transfers
between practitioners and scholars, often through workshops or interview sessions. The emphasis of
the methodology is placed on actively changing the research object through interventions. These
interventions may come from a theoretical framework, which is effectively tested or validated through
action research. Another possibility is that practitioner’s theories are used to form a first set of possible
interventions, which are tested such that a theory can be extracted from them.

The thesis’s primary research aim is to generate a set of artefacts which together can be used by
practitioners to make more informed decisions regarding the management of project complexity. With
the development of these artefacts in mind, design science research was identified as the most
appropriate research methodology. Several attempts have been made to describe methodologies for
design science research, consider examples such as Venable and Baskerville (2012), Peffers et al. (2007)
and Gacenga et al. (2012) in information systems research and Van Aken and Romme (2009) or Van
Burg et al. (2008) in the field of management. Since DSR is still in its early phases of development, these
authors often provide methodologies which share a number of features but also often diverge in their
details

Iivari (2015) described two strategies to conduct design science research. ‘Strategy 1’ assumes that the
researcher first constructs a general solution, and then implements and tests it in a case setting.
Research following ‘strategy 2’ however first constructs a solution for a particular case setting, and
then generalizes prescriptive knowledge from that experience. Rather than applying a single strategy,
a combination of both strategies might be more applicable considering the dual-objective of the
research.

This proposed dual strategy aligns with the research-design-development cycle as introduced by Van
Burg, Romme, Gilsing and Reymen (2008). The ‘Research-Design-Development Cycle’ provides
structure to the development of design principles and design solutions. The RDD Cycle accounts for
both the deliberate design of design principles and solutions from literature and the emergent design

7
from practice. Like previous frameworks, the RDD cycle describes how previous research findings may
be used to develop new design principles which may be translated into design solutions to influence
practice. The framework however also accounts for knowledge which may be derived from
experimentation within practice. By converting tacit knowledge from experienced practitioners, design
solutions from practice may be extracted which can be separated into design propositions. The tacit
knowledge of practitioners has thus been translated into practice-based design propositions which
may feed back into the literature.

2.2 Methodology – a series of investigative research cycles

The research project was initiated from a preliminary problem understanding developed from early
discussions between the researcher and the case organization. Since the problem understanding was
broad in the early stages of the research, a preliminary literature study was conducted on the different
methodologies within the management sciences available and suitable for the problem description.
Design science was noted as a potentially suitable mode of research early on in the process, and the
decision was made to organize the research based on iterative cycles. Through an iterative
methodological cycle, additional knowledge regarding research methods and methodologies was
collected to gain insight into the different possibilities to approach the problem description. By
collecting knowledge on research methods, reflecting upon these methods in regards to the problem
understanding and then discussing the possibilities with the problem owner, additional insight was
generated into both the problem, and the potential solutions. Each cycle resulted in an adjustment in
the overall research design until a first draft of the research design was generated describing the core
problem and the overall research approach.

The core methodology chosen for the research is a design science

based cyclical approach. However, since the research aims to
develop several deliverables, the research consisted of several
development cycles executed in series, where the output of each
cycle provides input for the data collection of the next cycle.

The core knowledge development cycle consists of some form of

data collection, followed by an individual reflection step that leads
to the development of a deliverable. The state of the deliverable
was then discussed in a bi-weekly feedback session with the
problem owner and the master thesis mentor. The feedback of this
phase fed back into the data collection and reflection steps thereby
continuing the cycle until the state of the deliverable was
satisfactory for the feedback panel. By focusing on the development
of actual deliverables and gathering feedback on a bi-weekly basis,
this iterative process ensured that new insights were generated on
a constant basis which could easily be implemented into the
research. Sometimes insight from the development of a deliverable
could even lead to changes in the previous deliverable. See figure 1 Figure 1: Core knowledge development
for a representation of this process. cycle.

Note that this cycle could work for any type of research. Within this research the knowledge
development cycle for example was initially used to investigate potential research methods, but was
later used for the development of a theoretical model based on literature research, the development
of a survey framework based on insights from practice and literature, and research into the project
portfolio of the case organization to generate project profiles or Arche-types through a cluster analysis
based on an analysis of project plan reports.

8
 Cycle
Methodological Cycle
Model Development Cycle
Instrument Development Cycle
Project Profiling Cycle
Project Complexity
Management Cycle
Figure 2: Research cycles
Chapter
2. Research design
3. Towards a model of project
complexity
4. Quantifying project
complexity
5. Managing project Complexity
5. Managing project Complexity
(Sub-)Research Question
n.a.
What is project Complexity?
How can project complexity be
assessed?
Are there different project
Arche-types in terms of project
complexity?
How can project complexity be
managed?
9
 2.3 Methodological Cycle
As discussed, the project was initiated by a ‘Methodological Cycle’ to investigate the research
methodologies relevant for the problem description. Through this cycle, insight was gained into both
the core issues faced by the case company, and into the methods available to answer the main – and
sub-research question(s). The core research activity within this cycle was the study of the literature on
research methodologies.

The literature was extensively explored through a keyword analysis targeting the abstracts and titles
of potential sources within the academic database ProQuest. From these search queries, an initial
review of the abstracts was used to generate a first set of potential sources. This subset was scanned
both in terms of applicability of content and in quality of content. Following Denyer et al. (2008), the
first criterion for the inclusion of an article was its ‘fit for purpose’ as described by Boas and Ashby
(2003). To judge the quality of an article, often either the number of citations or the journal ranking of
the journal in which the article was published are used. For the purpose of inclusion, a minimal of 10
citations or a journal ranking above 1.5 was used as the second criterion.

The articles in this refined list were categorized according to the primary aim of each paper, e.g. articles
on Design Science Research were labeled ‘DSR’, while articles on Action Research were labeled ‘AR’.
An in depth review of each article was then performed to determine both its potential use for the
purpose of the study, and as a means to generate additional sources through snowball sampling.

The primary purpose of the literature study was to generate an overview of the literature on common
research methodologies within the social sciences, to explore the similarities and differences between
these methodologies and to consider their compatibility.

2.4 Model Development Cycle

The research project has two core research questions, before being able to answer the main research
question, the question: “What is project complexity?” must first be answered. To explore this question,
a literature study was conducted on the topic of project complexity. By reflecting upon the literature,
a definition of project complexity was developed together with a theoretical model which explains the
antecedents – and consequences of project complexity. Feedback from the discussion panel was used
to incrementally improve the theoretical model which is described in chapter three.

Initially, the intended method of literature collection was the primary usage of meta-studies and
literature reviews on the topic of project complexity to generate a quick overview of the field. As the
study progressed however, only few of such articles could be found. As a result, the data collection
method was revised towards a broad search for relevant literature on the basis of keywords.

As such, the literature was extensively explored through a keyword analysis targeting the abstracts
and titles of potential sources within the academic database ProQuest. From these search queries, an
initial review of the abstracts was used to generate a first set of potential sources. This subset was
scanned both in terms of applicability of content and in quality of content. Following Denyer et al.
(2008), the first criterion for the inclusion of an article was its ‘fit for purpose’ as described by Boas
and Ashby (2003). To judge the quality of an article, often either the number of citations or the journal
ranking of the journal in which the article was published are used. For the purpose of inclusion, a
minimal of 10 citations or a journal ranking above 1.5 was used as the second criterion.

The articles in this refined list were categorized according to the primary aim of each paper, e.g. articles
with the aim of conceptualizing the notion of project complexity were labeled as ‘definition’, while
articles with the aim of creating a framework to analyze project complexity were labeled as ‘measure’.

10
An in depth review of each article was then performed to determine both its potential use for the
purpose of the study, and as a means to generate additional sources through snowball sampling.

The primary purpose of the literature study is to generate an overview of the literature on project
complexity, explore its major definitions, conceptualizations and theoretical models, and finally to
either adopt an existing measurement framework or generate a new framework from a synthesis of
the literature. As a final step in the literature study then, the coding and reduction processes as
developed by Strauss and Corbin (1990) and advocated for design science research by Burg et al. (2008)
were adopted.

2.5 Instrument Development Cycle – Theoretical cycle

Once the theoretical model was developed to a point that it provided an explanation to the many
aspects of project complexity, the third cycle was initiated to explore the sub-research question: “How
can project complexity be measured in scholarly research?”. The ‘Instrument Development Cycle’ first
developed an elaborate survey to measure the project complexity, drawing from the previously
developed theoretical model to frame the different aspects of project complexity. See chapter 4.1 for
this framework.

The previously executed literature review was utilized to select articles which included frameworks to
measure project complexity. Bosch-Rekveldt et al. (2011), Qureshi et al. (2015), Vidal et al. (2011a),
Nguyen et al. (2013), Maylor et al. (2013), He et al. (2015), Kim et al. (2003) and Crawford et al. (2007)
were selected to be included in this review.

The elements of these articles were first coded based on the project sub-systems they adhered to and
the antecedent which they fitted in. All elements were then clustered in a combination of project sub-
system and antecedent. These clusters were reviewed based on the similarities between elements and
the clarity of element descriptions. From the initial 274 elements included in the review only 5
elements could not be fitted in one of the project’s sub-systems. Additionally, 160 elements could be
directly attributed to one of the three categories of antecedents. 49 elements were not included in the
review as they related to either familiarity or ambiguity which are both not antecedents of project
complexity. Furthermore, 26 elements related to project dynamics and were indirectly included into
the final framework. Finally, 51 elements were omitted as they were described either too vaguely or
too narrowly to be included in the framework.

The final project complexity measurement framework includes 92 unique elements. 6 of these were
directly copied from the literature, while 32 elements were rephrased from elements found in the
literature. 36 elements were included to take into account the dynamic nature of project complexity.
The last 18 elements were not yet described within the literature, but were added to complement
existing elements of the project sub-systems and antecedents.

In parallel to the development of the survey framework, a subset of the projects within the case
organization were analyzed based on the project plan reports. By using the survey framework to assess
the complexity of a subset of the projects, additional insights were generated on the clarity of survey
items, and the completeness of the framework as a whole. See the ‘Project Profile Development Cycle’
for a clear overview of this process.

2.6 Instrument Development Cycle – Practical cycle

Once the survey framework for the research was developed to a point that it covered all necessary
elements of project complexity, the cycle was reinitiated to simplify the research framework into a
secondary framework fit for practice to investigate the sub-research question: “How can project
complexity be measured in practice?”

11
For the development of the secondary framework for practice, the ‘project complexity assessment’
tool previously developed by the case organization was used as a baseline. The assessment tool initially
included nine items, ordered in three categories and scored on a three point Likert-scale of simple,
medium and complex. Chapter 4.2 discusses this analysis framework in detail.

The previous literature review on project complexity included eighteen articles. Of these eighteen
articles, a subset of five articles were selected to supplement the baseline assessment tool. All eighteen
articles had previously been screened on their ‘fit-for-purpose’, e.g. providing insight into the analysis
of project complexity, and on their quality of content, e.g. written by – and published by a reputable
source. These five articles were furthermore selected based on a third criteria, ‘fit-for-practice’, to be
selected an article had to develop an assessment framework which was relatively easy to use and
interpret. The new pragmatic project complexity assessment framework is thus based on six sources,
one from practice, and five from research: Bosch-Rekveldt et al. (2011), Vidal et al. (2011), Maylor et
al. (2013), Nguyen et al. (2015) and He et al. (2015).

2.7 Project Profile Development Cycle

Having established a thorough method to measure the complexity of a project, the ‘Project Profile
Development Cycle’ used the project complexity survey framework to assess the project complexity of
all the projects within the case organization’s current project portfolio to investigate the sub-research
question: “Are there different project Arche-types in terms of project complexity?”. Chapter five
discusses the management of project complexity in general, and section 5.4 reflects upon the projects
of the case organization in particular.

In the early phases of the research, the analysis of these case projects was purely to test the survey
framework. Once the instrument was completed however, the complete set of projects was analyzed.
In total, 18 project plans were reviewed and assessed in terms of project complexity. Each project plan
was reviewed and relevant sections were coded. The coding process followed the survey item
numbers, such that all relevant information for each item could easily be retrieved. After reviewing
and coding each proposal, the relevant scores for the survey framework were estimated yielding final
project complexity estimates. These results were then used as input for a cluster analysis to explore
the existence of Arche-types within the dataset.

2.8 Project Complexity Management Cycle

The final phase of the research aims to investigate potential strategies and approaches to manage
project complexity in order to investigate the core research question: “How can project complexity be
managed?”. Chapter five elaborates on this subject. Drawing from both scholarly – and practitioners’
literature, a literature study was initiated to gather the knowledge regarding the management of
project complexity and answer the final research questions.

Drawing from the previous literature searches where the literature was extensively explored through
keyword analysis, the previous literature overviews were rescanned based on articles describing
project complexity management approaches and strategies. An in depth review of each article was
then performed to determine both its potential use for the purpose of the study, and as a means to
generate additional sources through snowball sampling.

During the literature search, Adler (1999) was found to contain an extensive overview of three
potential project complexity management strategies. This study was chosen to provide the basis of the
final framework on the management of project complexity, and its recommendations were verified by
the other sources.

12
 3. Towards a model of project complexity
Project complexity has been noted to be of influence on project management for decades, and has
even been included in definitions of project management such as Oisen (1972); “Project Management
is the application of a collection of tools and techniques (such as the CPM and matrix organization) to
direct the use of diverse resources towards the accomplishment of a unique, complex, one-time task
within time, cost and quality constraints. Each task requires a particular mix of these tools and
techniques structured to fit the task environment and life cycle (from conception to completion) of the
task.” c.f. Atkinson (1999, p337). While more recent conceptualizations of project management (such
as Turner et al. 2003) no longer consider projects as complex by definition, the effect of project
complexity continues to be explored.

Complexity has been studied in the context of project management for several decades, yet there still
exists a considerable lack of consensus on how complexity should be described or analyzed. Sinha et
al. (2001) for example notes that there not a single definition of complexity which is comprehensive
enough to capture all aspects of the concept. Furthermore, our understanding of complexity may be
heavily influenced by the frameworks we use to describe it. As Simon (1996, p109) considers: “there is
no conservation law that requires that the description be as cumbersome as the object being
described. How complex or simple a structure is depends critically upon the way in which we describe
it.” Finally, many sources may contribute to the complexity of a project which has made the analysis
of complexity in the context of project management a challenge in itself (Qureshi et al., 2015).

While many frameworks exist which often describe relatively similar elements of complexity, the
varying and often implicit theoretical models on which these frameworks are build pose a challenge to
the integration and comparisons of these models. Vidal et al. (2011) noted that a holistic measure of
project complexity was needed which was reliable, intuitive, independent of models and able to
highlight the sources of project complexity. From the review on project complexity assessments it
appears that several of such frameworks are available (e.g. Vidal et al. 2011a; Bosch-Rekveldt et al.,
2011; He et al., 2015).

While these frameworks do provide a general insight into the elements that contribute to project
complexity, they all lack explicit underlying theoretical models. As a result, the frameworks are less
useful for understanding why particular elements add to project complexity, and what the effects of
project complexity are on the overall project.

3.1 Defining project complexity through unpredictability and ambiguity

Defining project complexity has been a challenge for as long as the subject has been studied. Some of
the earliest sources note the differences in interpretation, as Baccarini (1996, p202) recounts: “the
meaning of complexity is open to wide and diverse interpretation.” Baccarini (1996) reflected on
Wozniak (1993) whom operationalized project complexity through nine difficulty factors. In other
words, a complex project is one which is difficult to understand and manage. As a result, a project is
as complex as the observer perceives it to be. The problem therein lies that as each observer has a
different knowledge base, the observed complexity of a project may vary considerably. While Baccarini
did not consider this statement to be invalid, he did argue that such a definition would not be able to
provide a basis for a reliable standard. Instead, Baccarini defined project complexity as: “consisting of
many varied interrelated parts” (Baccarini, 1996, p202).

Baccarini advocated the separation of the intrinsic complexity of the project system and our perception
of the project as a result of its complexity, and provided a basis to explain which factors contribute to
project complexity.

13
More recently, Vidal et al. (2013a, p258) defined project complexity as: “the property of a project
which makes it difficult to understand, foresee and keep under control its overall behavior, even when
given reasonably complete information about the project system. Its drivers are factors related to
project size, project variety, project interdependence and project context.” Vidal et al. recognized the
effect of project complexity on our perceptions of the project, and considered which factors add to the
complexity of a project, thereby bridging the gap between a Wozniak and Baccarini.

However, the definition of project complexity by Vidal et al. (2013) still does not clarify how the drivers
project size, project variety, project interdependence and project context limit the project’s teams
ability to understand and foresee the behavior of the project system. Vidal et al. do however highlight
an interesting point, as the authors draw from a previous definition of complexity by Edmonds (1999,
p72): “Complexity is that property of a model which makes it difficult to formulate its overall behavior
in a given language, even when given reasonably complete information about its atomic components
and their inter-relations.” By further exploring why some aspects of projects limit the project team’s
ability to understand and predict the behavior of the project system, the concept of project complexity
can be better defined.

People form mental models of themselves and their environment to understand, predict and explain
their interactions and help guide their decision making processes (Gentner and Stevens, 2014). In the
context of project management, this means that the project manager, project team and the project
stakeholders all create independent mental models of the same project. For all these individual actors,
the target system (the project) is the same. However, the mental models used by these individuals can
differ significantly as their mental models are shaped through individual interactions with the target
system based on their technical backgrounds, previous experiences and the social structure.

Beyond individual experiences, actors can use conceptual models in the form of project tools such as
the project planning, project schedules, PERT - and CPM analyses to improve their (shared) mental
models. Despite the aid of these conceptual models though, mental models are by definition
incomplete and people are often highly limited in their ability to use their mental models to predict
future effects of current decisions.

Within the context of project management in particular, the sheer size of the project may be a
significant barrier to an individual’s ability to form a complete mental model of the project. For
example, a project may be so large in scope, that it is impossible for one person to know in detail all
the goals, objectives and specifications and how they relate to the product design and sub-designs.

Additionally, as projects often require the integration of many different knowledge areas, through
globally dispersed work teams, the variety of educational backgrounds, work specializations and social
experiences together result in differences between the mental models of actors within the project.

Finally, the different elements of a project are typically highly dependent upon each other, for example
as the output of one work task is the input for another, or as project teams collaborate on work
packages. The networked dependencies between the many varied elements of a project may introduce
nonlinear behavior when parts of the project are uncertain. As a result, the project as a whole becomes
increasingly unpredictable (Adler, 1999). This issue is compounded as the project actors are no longer
able to ‘run’ their mental models to explain the project’s behavior.

Project complexity at its core thus encompasses two challenges. A complex project is a project which
as a result of the project’s size, variety and interdependencies is more likely to show non-linear and/or
emergent behavior, making the project as a whole unpredictable. Additionally, the scope of a project
prevents actors from forming complete mental models while the variability in the project results in

14
many different perspectives on the project. As a result, actors are no longer able to form accurate and
reliable mental models to help understand, foresee and manage the project system’s behavior. As
project members attempt to apply incomplete mental models on an already inherently unpredictable
project system, it becomes increasing difficult to accurately predict the causes – and effects of project
(management) decisions.

By considering the accumulated effects of the project system on the project team’s perception of the
project, a new definition can be proposed: “Project complexity is the accumulated effect of the
interactions between the many varied interrelated parts of a project, which causes unpredictable
behavior in the project and inhibits project member to form accurate and reliable mental models to
understand, foresee and manage the project system’s behavior, even when given reasonably complete
information about the project system.”

3.2 The paradox of perceived complexity

The study of project complexity suffers from a particularly interesting paradox. If a project is so
complex that it is not possible to create a comprehensive mental model of the project, and a
comprehensive understanding of the project is required to analyze the sources of the project’s
complexity, then it follows that the complexity of the project cannot be accurately or objectively
measured. At best, an approximation of the project complexity can be established. However, the
criteria to which such an approximation would have to adhere to in order to be considered valid or
reliable fundamentally relies upon the epistemology of the researcher.

Schlindwein et al. (2005) differentiates between descriptive – and perceived complexity. ‘Descriptive
complexity’ assumes the existence of an objective reality, independent from the observer. As a result,
complexity can be measured through the characteristics of the object or system. ‘Perceived
complexity’ on the other hand assumes that the observations made by the researcher are not
independent from the observer. Rather than measuring the actual complexity of an object, one
measures the perceived complexity by the observer.

Within the literature on project complexity, more recent authors such as Bosch-Rekveldt et al. (2011)
and Adler (1999) have recognized the inherent subjectively of the assessment of project complexity.
Vidal and Marle (2008) also explicitly recognize the inherent subjectivity of holistic measures and
attempt to bridge the gap between descriptive – and perceived complexity by providing a frame of
reference for the perception of project complexity.

When discussing the existence of a ‘real’ or ‘perceived’ complexity, it must be noted that the
ontological stance of the researcher is crucial. Within the context of design science research, many
authors have adopted a philosophy based on pragmatism, which considers the practical consequences
vital to determine both meaning and truth (Hevner, 2004). Alternatively, critical realism has been
adopted by some other authors (Calsson, 2006). Critical realism describes the existence of three
domains. The empirical domain consists of our experiences, while the actual domain consists of the
events and patterns an observer might experience. Underlying the actual domain are the structures
and mechanisms which generate the events and patterns which the observer experiences. Each
domain exists independently and out of phase of one another (Carlsson, 2006). The existence of both
a ‘real’ and ‘perceived’ complexity makes a lot of sense from the perspective of critical realism. ‘real’
complexity exists within the real domain and influences the project resulting in observable patterns
and events within the actual domain. In turn, different stakeholders perceive the complexity differently
on the empirical domain.

15
Based on the previous exploration and definition of project complexity, it can now be argued that
project complexity stems from ‘real world’ elements, but is also influenced by the individual’s
education, work experiences and social background. Different individuals may perceive the project
differently, and as a result may have different interpretations of the project’s complexity. Descriptive
or ‘real’ complexity thus exists, but any attempt to measure this real complexity is influenced by the
perspective of the observer. The ‘real’ project complexity is a product of the project size, project variety
and project interdependencies, while the ‘perceived’ project complexity is a result of the real project
complexity which is observed through the past professional - and personal experiences of the reviewer.

3.3 Exploring the project system

Baccarini (1996) first used concepts from systems theory to conceptualize project complexity. The
majority of studies since have also utilized systems theory to frame project complexity. To utilize the
insights from system’s theory, the project must first be described as a system. According to the field
of system analysis, a system is “an object, which, in a given environment, aims at reaching some
objectives by doing an activity while its internal structure evolves through time without losing its own
identity” (c.f. Vidal et al., 2013, p254; Le Moigne, 1990; Penalva, 1997). Turner et al. (2003, p7) defined
a project as: “a temporary organization to which resources are assigned to undertake a unique, novel
and transient endeavor managing the inherent uncertainty and need for integration in order to deliver
beneficial objectives of change.” When considering these two definitions, it is clear that a project can
indeed be analyzed through systems thinking. Systems are typically composed of multiple
interdependent sub-systems. In the case of the project system, Baccarini (1996) first proposed that the
project system can be described through an organizational - and a technological subsystem. Several
authors since have described additional sub-systems to highlight other aspects of new product
development.

A Review of the literature was conducted to generate an initial list of potential aspects of project
complexity to be included in the model. 18 distinct dimensions of project complexity were found during
this initial literature search. To limit the number of dimensions, the results from this first list were
clustered into groups of relatively similar subjects. See appendix A for an overview of the 18
dimensions found within the literature. Based on the dimensions of project complexity included within
these clusters, six sub-systems of the project system are now proposed. These sub-systems have been
defined, such that they are based on the most common conceptualizations of project complexity,
together provide a broad view of the project through the combined effect of six clearly distinct
perspectives of analysis, and can be defined in accordance to systems thinking.

When Baccarini (1996) first described project complexity, he considered both an organizational – and
technological system. Due to the self-referential tendencies within research, it is not surprising that
both topics have since been included in the majority of studies. As organizations are increasingly
working together in for example co-development projects, it does make sense to expand the
organizational system to also include project partners. Therefore, the organizational system has been
reframed into the inter-organizational system. The objects within the system are the relevant
departments of all project partners. The relationships between the departments relate to how work is
organized between – and within departments and how resources are shared.

As authors broadened the analysis of project complexity to include other aspects of the project
development process, the influence of social and cultural issues within the project was often
emphasized. He et al. (2015) for example describes both cultural – and informational complexity, while
Maylor et al. (2008) highlights the complexity of the project team itself. Following systems thinking,
bundling these ideas resulted in the notion of a social system. The social system consists of the project

16
manager(s), project members and the management team. The communication patterns within – and
between teams can be analyzed to consider the relationships within the social system.

When Baccarini first highlighted the technological system, the research effort was primarily focused
on engineering and construction projects. Due to the proliferation of projects as a means to organize
work, the notion of a purely technological system may be incomplete. Instead, a product service
system may be more appropriate to capture the broad set of potential deliverables that might be
developed in a project. The product service system consists of the processes, components and modules
that together produce or deliver parts of the desired functionalities of the product service offering.
The relationships between the processes and components of the product service system stem from
development interdependencies as components form modules to achieve functionality requirements.

While the product service system describes the development, production and delivery of the finished
product service offering, authors such as He et al. (2015) and Maylor et al. (2008) emphasized the
project scope as an important precursor of the technological complexity. The project scope captures
the definition of the product service offering during the early stages of the project. As such, the system
of scope can be described in terms of the project goals, deliverables and specifications. The
relationships between the goals, deliverables and specifications of the project provide insight into the
overall convergence of the project scope.

In systems theory, systems can be described as either open or closed. An open system can be
influenced by factors outside of the direct system borders, while a closed system is isolated from its
environment. Bosch-Rekveldt et al. (2011) amongst others popularized the addition of the project
environment/context as a third dimension of project complexity. Authors such as Kim et al. (2003) and
Maylor et al. (2008) furthermore highlighted the influences of the market and external stakeholders
respectively. Alternatively, Nguyen et al. (2015) and Maylor et al. (2013) amongst others explicitly
described the influence of socio-political actors. To capture the wide range of potential external
influences on the project system, the project context has been separated into both the Project’s
business environment, and the project’s social-political system.

The project’s business environment consists of all organizations that either directly or indirectly add
value to the product service offering, the market targeted by the product service offering and the
competition within this market. The relationships between the parties in the business environment
can be analyzed by considering how the different organizations add value to the final offering and how
dependent the organizations are upon each other.

The socio-political system includes any public or political stakeholders of the project, able to influence
the project either directly or indirectly. The dialogue between the public, the political powers and the
project together with the influence of (local) laws and regulation on the project can be considered as
manifestations of the relationships within the socio-political system.

By describing the project as open system composed of an organizational subsystem, a social

subsystem, a product service subsystem, and subsystem of scope, the elements and relationships of
the project system can be structurally defined. By further highlighting the influence of the system’s
environment through the business environment and the socio-political system, a comprehensive
description of the project system is achieved.

17
 3.4 Size, variety and interdependence – the antecedents of project complexity
Within this thesis, project complexity has been described as the accumulated effect of the interactions
between the many varied interrelated parts of a project. This concept will now be further explored to
create a theoretical model of project complexity. Baccarini (1996) first used concepts from systems
theory to conceptualize project complexity. In particular, Baccarini highlighted that complex systems
can be described in terms of differentiation and interconnectivity.

The majority of studies since have also utilized systems theory to frame project complexity. Adler
(1999) for example utilized the definition of system complexity by Flood & Carson (1993) to define the
complexity of the project system. Flood & Carson (1993) considered the complexity in a system as
dependent on the number of elements in a system, the number of relationships between the elements
in the system and the organization and behavior of the relationships. Adler (1999, p31) in turn used
this definition to characterize a project as complex if the project consists of “many reciprocal
interdependent sub-units or teams responsible for more than one customer's need acting in an
unpredictable context with many technical uncertainties.”

Qureshi et al. (2015) expanded this mode of description as the authors modeled the effects of project
variety, project size, interdependencies within the project and elements of context on project
complexity. The study found however that both size and elements of context did not have a direct
significant effect on project complexity.

Several authors have noted that as project size increases, so does project interdependence (Baccarini,
1996; Cicmil and Marshall, 2005; Corbett et al., 2002; Geraldi and Adlbrecht, 2007; Hagan et al., 2011,
c.f. Qureshi et al. 2015). Qureshi et al. (2015) confirmed this hypothesis and found that the effect of
project size on project complexity was mediated by interdependence. Project size was found to be
correlated with project variety. As the size/number of elements of a sub-system increases, the amount
of potential relations between its elements increases exponentially. Furthermore, as more elements
are included in a project, any variety between sets of elements is also increased exponentially. Project
complexity was previously defined in terms of both variety and interdependence. System size effects
system variety, and system interdependence. In turn, system variety and system interdependence
result in system complexity.

Maylor et al. (2008), Maylor et al. (2013), Remington et al. (2007), Geraldi (2009), Gidado (1996) and
Geraldi (2011) all highlighted the dynamic and temporal aspects of project complexity. As projects are
executed over time, the project sub-systems may change drastically. Project partners may be added
or removed, the product service offering may refocus on another market, the specifications may be
adjusted, the project team may change, new policies may be implemented and ecosystem partners
may switch to join competitors. As a result, any analysis of the project complexity must consider both
the current, and future project complexity. Previous authors considered the project dynamics as either
an antecedent of complexity or even as a type of complexity. This effectively implies that an expected
change in the future, results in an increased project complexity now.

Instead, it may make more sense to consider the dynamic changes within a project as changes in either
the sub-system size, variety or interdependence. For a dynamic analysis of system complexity, the sub-
system size, variety and interdependence should be estimated at t0 and some future tn. It is however
difficult to estimate the future state of the project system with absolute certainty. Although it is likely
that the future state of the project system is roughly similar to the current state of the project system
plus or minus some deviation. Therefore, any future sub-system driver can be defined as the state of
the current sub-system driver plus the change in state, e.g. 𝐷𝑠,𝑡𝑛 = 𝐷𝑠,𝑡0 + ∆𝐷𝑠 . Due to the uncertainty
of this change, this model can be expanded with an estimation of the likelihood that the state of the

18
driver will change. In theory, one could use a probability function to describe the likelihoods that
different changes will occur. In practice however, such a probability function would be very difficult to
attain. Alternatively, only a single probability can be estimated, either the state of the system driver
remains the same or the system driver changes. Two functions can now be established: 𝐷𝑠,𝑡𝑛 = 𝐷𝑠,𝑡0 +
∆𝐷𝑠 𝑓𝑜𝑟 𝑝 = 𝑝𝐷𝑠 and 𝐷𝑠,𝑡𝑛 = 𝐷𝑠,𝑡0 𝑓𝑜𝑟 𝑝 = 1 − 𝑝𝐷𝑠 . As the sub-system complexity is the result of the
interactions between the sub-system’s size, variety and interdependence, and each of these drivers
can now have either one of two values, each sub-system can now have 23 = 8 different complexity
estimates.

Gidado (1996), Bosch-Rekveldt et al. (2011), Maylor et al. (2013), Nguyen et al. (2015) and He et al.
(2015) furthermore highlighted factors of experience, familiarity and newness as additional factors
contributing to project complexity. ‘Real’ or descriptive project complexity was previously described
as a product of the project size, project variety, and project interdependencies. ‘Perceived’ complexity
on the other hand was noted to be the result of the real project complexity, observed through the past
professional – and personal experiences of the spectator. Considering these two definitions, it seems
more appropriate to consider the familiarity of the project team with the project system as one of the
factors that decreases the discrepancy between real – and perceived complexity. In other words, if the
project team is highly familiar with the project system, their perceived complexity of the project will
be closer to the real complexity, than if they were less familiar with the project system.

A review of the literature was conducted to generate an initial list of potential antecedents of system
complexity to be included in the model. 12 distinct antecedents were found during this initial literature
search. To limit the number of drivers however, the results from this first list were clustered into groups
of relatively similar subjects. This process resulted in five separate categories. Three of these categories
are argued to contain antecedents of complexity, one category describes the change of complexity
over time while the fifth category describes aspects which influence our perception of the sub-system
and its complexity.

3.5 Uncertainty, ambiguity and emergence – the consequences of project complexity

Within the literature, two opposing perspectives can be found on the relationships between
complexity and uncertainty (Vidal et al. 2013). Several authors consider uncertainty and/or risk to
contribute to complexity (Bosch-Rekveldt et al., 2011; He et al., 2015; Lu et al., 2015; Nguyen et al.,
2015; Kim et al., 2003; Gransverg et al., 2013; Maylor et al., 2008; Maylor et al., 2013; Remington et
al., 2007; Gidado, 1996; Geraldi, 2009 and 2011). Alternatively, authors such as Vidal et al. (2008,
2011a, 2011b, 2013) and Hellström (2007) consider uncertainty to be a consequence of complexity.

Bosch-Rekveldt et al. (2011) draws from Perminova et al. (2008) whom consider risk as a manifestation
of uncertainty. The number of risks and/or their probability and impact are assumed to contribute to
project complexity because when a project includes a high number of risks, dynamics and interactions
between these risks are to be expected, these dynamics and interactions then make a project more
difficult to manage and thus complex.

Vidal et al. (2008) similarly considers risks to be induced by uncertainty, but argues that these
uncertainties stem from the project’s complexity. When a project becomes increasingly complex, it
also becomes more difficult to evaluate the effects of decisions and actions as too many elements are
interacting. As a result, uncertainty is introduced into the project. Additionally, the networked
dependencies between the many varied elements of a project may introduce nonlinear or emergent
behavior when parts of the project are uncertain. As a result, the project as a whole becomes
increasingly unpredictable. Furthermore, any inherent uncertainty in any single element of the project

19
propagates through the interactions between the elements of the project system, resulting in
additional uncertainties within the project.

Ambiguity is defined by Martin and Meyerson (1988, p. 112) as: “(The) Lack of clarity regarding the
relevant variables and their functional relationships.” Schrader et al. (1993) further elaborated upon
uncertainty and ambiguity, describing ambiguity as a lack of clarity and uncertainty as a lack of
information. When a system is uncertain, the system components and their interdependencies are
known but their values are not. For example, it is known which tasks need to be performed in which
order, but it is not known how much time will be required to execute each task. The project can be
executed according to the plan but some slack is required to deal with the uncertain activity durations.

Two types of ambiguity are furthermore described; when actors suffer from level I ambiguity, the
system components are known but their interdependencies or values are not. When actors suffer from
level II ambiguity, neither the system components, the interdependencies or their values are known
completely. An example of level I ambiguities may be found when the project environment is analyzed.
While all actors may be known (e.g. customers, competitors, suppliers and retailers), the
interdependencies between the parties may be unknown as information regarding cooperation
agreements is limited. New development projects working on radical new technologies may often have
to deal with such high levels of ambiguity (level II ambiguity) that new tasks are added while the project
is still being executed. As a result, not all tasks are known at the start of the project, nor how different
tasks will relate to each other and how long they will take.

Project complexity was previously defined as the accumulated effect of the interactions between the
many varied interrelated parts of a project, which causes unpredictable behavior in the project and
inhibits project member to form accurate and reliable mental models to understand, foresee and
manage the project system’s behavior, even when given reasonably complete information about the
project system.

When the definitions of uncertainty and ambiguity are considered in the context of the previously
described definition of project complexity, it follows that project complexity can induce both type I
and type II ambiguity. The more complex a project is, the more likely that the project actors will
experience type II ambiguity. Additionally, the project interdependencies cause emergent behavior
and any inherent uncertainty in any sub-system of the project propagates through the interactions
between the elements of the project system, resulting in additional uncertainties within the project.
Project complexity thus induces both uncertainty, and ambiguity. Uncertainty, ambiguity and
emergent behavior in turn manifest in the form of risks and opportunities.

If project members are less familiar with the project, it becomes harder to correctly estimate the
project system complexity. While complexity inherently causes ambiguity, the complexity induced
ambiguity may furthermore be enhanced when one does not understand the full complexity of the
project. Thus the difference between the real – and perceived project complexity moderates the effect
of the real project complexity on complexity induced ambiguity. For example, when one is highly
familiar with the project system, the components may be known while the interdependencies and
values are not (level I ambiguity). A person less familiar with the same project may not be aware of all
the components and as a result experience level II ambiguity.

3.6 Developing a theoretical & mathematical model

The project system consists of four subsystems. The Inter-organizational system and the social system
capture the communication between organizations, departments, work teams and project members
respectively. The system of scope and the product service system in turn describe the relationships
between the project’s goals, deliverables, requirements, work processes, components and modules.

20
Finally, the project’s business environment and the socio-political system describe the behavior of
outside influences such as market forces, laws and regulations which impact the project system.

The ‘real’ system complexity of these six subsystems can be analyzed through the subsystem size,
variety and interdependencies. System size has a positive effect on system variety and system
interdependence. As the number of elements increases, the potential variety and interdependencies
between the elements both increase exponentially. System variety and system interdependence in
turn result in real system complexity. Different individuals may perceive the project differently, and as
a result may have different interpretations of the project’s complexity. If project members are less
familiar with the project, it becomes harder to correctly estimate the project system complexity. The
‘perceived’ project complexity is a result of the real project complexity which is observed through the
past professional - and personal experiences of the reviewer.

Project complexity can induce both type I and type II ambiguity. The more complex a project is, the
more likely that the project actors will experience type II ambiguity. Additionally, any inherent
uncertainty in any sub-system of the project propagates through the interactions between the
elements of the project system, resulting in additional uncertainties within the project. The networked
dependencies within a project may furthermore introduce nonlinear or emergent behavior.
Uncertainty, emergent behavior and ambiguity in turn manifest in the form of risks and opportunities
which ultimately influence the project’s performance.

While complexity inherently causes ambiguity, the complexity induced ambiguity may furthermore be
enhanced when one does not understand the full complexity of the project. Thus the difference
between the real – and perceived project complexity moderates the effect of the real project
complexity on complexity induced ambiguity

Finally, as projects are executed over time, the project’s sub-systems may change drastically. Project
partners may be added or removed, the product service offering may refocus on another market, the
specifications may be adjusted, the project team may change, new policies may be implemented and
ecosystem partners may switch to join competitors. As a result, any analysis of the project complexity
must consider both the current, and future project complexity. To consider the dynamic changes within
a project, it makes sense to consider the changes in the subsystems by analyzing the changes in either
the subsystem size, variety or interdependence.

For a dynamic analysis of system complexity, the sub-system size, variety and interdependence should
be estimated at t0 and some future tn. It is likely that the future state of the project system is roughly
similar to the current state of the project system plus or minus some deviation. Therefore, any future
sub-system driver can be defined as the state of the current sub-system driver plus the change in state.
Due to the uncertainty of this change, the analysis must include an estimation of the likelihood that
the state of the system will change. By considering the system’s dynamics as a binary probability
distribution, two possibilities can be considered: either the state of the system driver remains the same
or the system driver changes.

Having considered the many aspects that contribute to project complexity, a theoretical model has
been constructed to visually summarize the hypothesized relations. From a theoretical point of view,
project complexity can be seen as a latent construct, as a concept project complexity captures and
describes the collective behavior of the project system which generates uncertainty, ambiguity and
emergent behavior. Project complexity cannot be directly measured, but must instead be inferred
from the behavior of the project system which can be described through the behavior of its
subsystems. Through the size, variety and interdependencies of the subsystems, the complexity each
subsystem can be estimated to in turn determine the overall project complexity.

21
Figure 3: Formal model of Project Complexity.
22
Having established the theoretical model, a mathematical model can now be conceived based on the
hypothesized relations found in the literature. The theoretical model considered project complexity as
a result of the multiplicative effects of the six dimensions of project complexity. Therefore, the first
basic equation can be established as 𝑐𝑝 = ln ∏ 𝑐𝑠 with 𝑐𝑝 as the complexity of the project system and
𝑐𝑠 as the complexity of a given sub-system s. The natural logarithm is taken from the product of all
values for 𝑐𝑠 as a means to transform the otherwise exponential function into a relatively linear scale.
The second general equation determines the complexity of a given sub-system s with 𝑐𝑠 =
ln((𝑠𝑠 ∗ 𝑣𝑠 ) ∗ (𝑠𝑠 ∗ 𝑖𝑠 )). Within this equation; 𝑠𝑠 relates to the size of the sub-system s, 𝑣𝑠 relates to
the variability of the sub-system s and 𝑖𝑠 relates to the interdependence of the sub-system s. Chapter
5 noted that as the size of a sub-system increases, so do both variability and interdependence. As such,
the mathematical model multiplies the size with both the variability and interdependence. System
complexity then is the result of the product of system variability and system interdependence. A
mathematical transformation is applied to the system complexity equation in the form of a natural
logarithm to generate a system complexity estimate which is roughly linear, rather than exponential.

From these two basic equations, the mathematical model may be generated for the estimate of the
current project complexity. The theoretical model however also proposed to take into account the
dynamic effects of complexity. As the antecedents of project complexity evolve over time, so does the
resulting project complexity itself. Therefore, a second mathematical model can be generated that
estimates the project complexity at some time 𝑡𝑛 . For each antecedent, the current value, the
likelihood that the value will change and the expected size of change may be estimated. Then, the
value of the antecedent at time 𝑡𝑛 may be calculated based on the value of the antecedent at time 𝑡0 ,
resulting in equations 3 through 8. By inserting equations three through eight back into equations one
and two, a new set of equations can be generated to calculate the dynamic project complexity
estimate 𝑐𝑝,𝑡𝑛 , based on the dynamic sub-system complexity estimates 𝑐𝑠,𝑡𝑛 , resulting in equations 9
and 10.

As each antecedent of each sub-system can have one of either two values, e.g. the antecedent is stable,
or the antecedent changes, each antecedent thus has a binomial distribution. The system complexity
of a single project sub-system therefore has a joint probability distribution of three binomial
distributions, and has 23 = 8 potential different outcomes. Additionally, the project complexity
estimate then has 23∗6 = 262.144 potential different outcomes. Given the uncertainty of the project,
an exact value of the project complexity can no longer be calculated. Instead, the expected value can
be calculated which represents the average value given the inherent uncertainty of the project. The
expected value is generally calculated by multiplying the outcome of each possibility with the
probability that the possibility occurs. The sum of all these multiplications then provides the expected
value. Equation 11 provides the expected value of the complexity of a particular project sub-system s.
Equation 12 provides the expected value of the project complexity factor. Note that both of these
equations show an abbreviated section of the calculation as the large number of outcomes makes it
rather elaborate to manually write down these functions. Through the use of mathematical software
however, calculating the expected value of the project complexity is relatively easy.

23
𝑐𝑝 = ln ∏ 𝑐𝑠 (1) 𝑠𝑠,𝑡𝑛 = 𝑠𝑠,𝑡0 𝑓𝑜𝑟 𝑝 = 1 − 𝑝𝑠,𝑠 (3)

𝑐𝑠 = ln((𝑠𝑠 ∗ 𝑣𝑠 ) ∗ (𝑠𝑠 ∗ 𝑖𝑠 )) (2) 𝑠𝑠,𝑡𝑛 = 𝑠𝑠,𝑡0 + ∆𝑠𝑠 𝑓𝑜𝑟 𝑝 = 𝑝𝑠,𝑠 (4)

𝑣𝑠,𝑡𝑛 = 𝑣𝑠,𝑡0 𝑓𝑜𝑟 𝑝 = 1 − 𝑝𝑠,𝑣 (5)
𝑐𝑝,𝑡𝑛 = ln ∏ 𝑐𝑠,𝑡𝑛 (9) 𝑣𝑠,𝑡𝑛 = 𝑣𝑠,𝑡0 + ∆𝑣𝑠 𝑓𝑜𝑟 𝑝 = 𝑝𝑠,𝑣 (6)

𝑓𝑜𝑟 𝑎 𝑔𝑖𝑣𝑒𝑛 𝑠𝑒𝑡 𝑜𝑓 𝑝𝑠,𝑠 , 𝑝𝑠,𝑣 𝑎𝑛𝑑 𝑝𝑠,𝑖 :

𝑐𝑠,𝑡𝑛 = ln ((𝑠𝑠,𝑡𝑛 ∗ 𝑣𝑠,𝑡𝑛 ) ∗ (𝑠𝑠,𝑡𝑛 ∗ 𝑖𝑠,𝑡𝑛 )) (10) 𝑖𝑠,𝑡𝑛 = 𝑖𝑠,𝑡0 𝑓𝑜𝑟 𝑝 = 1 − 𝑝𝑠,𝑖 (7)
𝑖𝑠,𝑡𝑛 = 𝑖𝑠,𝑡0 + ∆𝑖𝑠 𝑓𝑜𝑟 𝑝 = 𝑝𝑠,𝑖 (8)

𝑐𝑠,𝑡𝑛 ,111 ∗ 𝑝𝑠,111 + ⋯ + 𝑐𝑠,𝑡𝑛 ,222 ∗ 𝑝𝑠,222 (11)

𝐸[𝑐𝑠,𝑡𝑛 ] =
1

ln ∏ 𝑐𝑠,𝑡𝑛 ,111 ∗ ∏ 𝑝𝑠,𝑡𝑛 ,111 + ⋯ + ln ∏ 𝑐𝑠,𝑡𝑛 ,222 ∗ ∏ 𝑝𝑠,𝑡𝑛 ,222 (12)

𝐸[𝑐𝑝,𝑡𝑛 ] =
1

24
 4. Quantifying project complexity - a dual perspective
4.1 A novel framework for research
The complexity of the project system can be approximated based on the respective complexities of
the six sub-systems. Chapter three proposed a theoretical – and mathematical model to calculate a
project complexity estimate based on estimates of each subsystem’s size, variety, interdependence
and dynamic changes. The size, variety, interdependence and dynamic changes of each subsystem
must in turn be estimated through a set of observable elements of the project’s subsystems. Given the
large number of elements included in the framework, the following section simply highlights the
overall logic behind the framework while Appendix B further elaborates on the method used to create
the framework through a number of examples.

Figure 4 shows the measurement framework of the inter-organizational complexity. The inter-
organizational system consists of the collaborating organizations and departments within the project.
Differences in organizational interests, invested resources and skills influence the power dynamics
between the parties and how interdependencies are managed. The relationships between the
departments/organizations relate to how work is organized between – and within departments and
how resources are shared.

Figure 5 shows the measurement framework of the social complexity of the project. The social system
consists of the project manager(s), project members and the management team. The communication
patterns within – and between teams can be analyzed to consider the relationships within the social
system together with the differences between the actors in terms of culture, disciplinary background
and geographical dispersion.

Figure 6 shows the framework of the complexity of the scope of the project. The project scope captures
the definition of the product service offering during the early stages of the project. As such, the system
of scope can be described in terms of the project goals and deliverables. The relationships and
differences between the goals and deliverables of the project provide insight into the overall
convergence of the project scope.

Figure 7 shows the framework of the product service complexity. The product service system consists
of the processes, components and modules that together produce or deliver parts of the desired
functionalities of the product service offering. The relationships between the processes and
components of the product service system stem from development interdependencies as components
form modules to achieve functionality requirements. The disciplinary composition of the project team
furthermore provides insight into the variety of different parts and modules of the product service
system.

Figure 8 shows the framework of the socio-political complexity. The socio-political system includes any
public or political stakeholders of the project, able to influence the project either directly or indirectly.
The dialogue between the public, the political powers and the project together with the influence of
(local) laws and regulation on the project can be considered as manifestations of the relationships
within the socio-political system.

Figure 9 shows the framework of the complexity of the business environment. The project’s business
environment consists of all organizations that either directly or indirectly add value to the product
service offering, the market targeted by the product service offering and the competition within this
market. The relationships, variety and interdependencies between the parties in the business
environment can be analyzed by considering how the different organizations add value to the final
offering and how dependent the organizations are upon each other.

25
Code Inter-organizational Complexity - Size 1 2 3 4 5 Rating Source(s)
IOCS1 Number of companies / projects sharing their 1 Organization 4 - 5 Organizations 8+ Organizations Bosch-Rekveldt et al. (2011), He et al. (2015), Qureshi et al.
resources (2015) and Vidal et al. (2011)
IOCS2 What is the planned duration of the project? < 1 Year 2 Years > 4 Years Bosch-Rekveldt et al. (2011) and Vidal et al. (2011)
IOCS3 What is the estimated budget of the project? < 1 Mil € 3 Mil € > 5 Mil € Maylor et al. (2013), Bosch-Rekveldt et al. (2011), Vidal et
al. (2011), Qureshi et al. (2015) and Nguyen et al. (2015)
IOCSD1 What is the likelihood that the Inter-organizational Highly unlikely Somewhat likely Highly likely Swinkels (2016)
size will change in the foreseeable future?

IOCSD2 How large would this change in Inter-organizational Negatively significant Insignificant Positively significant Swinkels (2016)
size be?

Code Inter-organizational Complexity - Variety 1 2 3 4 5 Rating Source(s)

IOCV1 Variety of departmental/organizational interests Highly similar Somewhat similar Highly dissimilar Vidal et. al. (2011) and Qureshi et al. (2015)
IOCV2 Variety of departmental/organizational financial Highly similar Somewhat similar Highly dissimilar Crawford et al. (2007)
impact
IOCV3 Variety of departmental/organizational size Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
IOCV4 Variety of invested financial resources Highly similar Somewhat similar Highly dissimilar Vidal et. al. (2011) and Qureshi et al. (2015)
IOCV5 Variety of departmental/organizational skills Highly similar Somewhat similar Highly dissimilar Vidal et. al. (2011) and Qureshi et al. (2015)
needed
IOCV6 Variety of organizational interdependencies Highly similar Somewhat similar Highly dissimilar Vidal et. al. (2011) and Qureshi et al. (2015)
IOCVD1 What is the likelihood that the Inter-organizational Highly unlikely Somewhat likely Highly likely Swinkels (2016)
variety will change in the foreseeable future?

IOCVD2 How large would this change in Inter-organizational Negatively significant Insignificant Positively significant Swinkels (2016)
variety be?

Code Inter-organizational Complexity - Interdependence 1 2 3 4 5 Rating Source(s)

IOCI1 Resource dependence on other projects/operations Highly Independent Highly Dependent Highly Swinkels (2016)
(e.g. Human -, financial or other resources) Interdependent

IOCI2 interdependence between Highly Independent Highly Dependent Highly Maylor et al. (2013), Vidal et al. (2011), Qureshi et al. (2015)
departments/organizations Interdependent and He et al. (2015)
IOCI3 interdependence between tasks Highly Independent Highly Dependent Highly Bosch-Rekveldt et al. (2011) and He et al. (2015)
Interdependent
IOCID1 What is the likelihood that the Inter-organizational Highly unlikely Somewhat likely Highly likely Swinkels (2016)
interdependence will change in the foreseeable
future?
IOCID2 How large would this change in Inter-organizational Negatively significant Insignificant Positively significant Swinkels (2016)
interdependence be?

Figure 4: Inter-organizational Complexity.

26
Code Complexity of the Social System - Size 1 2 3 4 5 Rating Source(s)
SCS1 How many (independent) teams need to be 1 Team 4 - 5 Teams > 8 Teams Vidal et. al. (2011), Qureshi et al. (2015) and Kim et al.
coordinated? (2003)
SCS2 What is the average team size of the teams to 1 Member 5 Members 10 + Members Bosch-Rekveldt et al. (2011) and Vidal et. al. (2011)
coordinate?
SCSD1 What is the likelihood that the size of the social Highly unlikely Somewhat likely Highly likely Swinkels (2016)
system will change in the foreseeable future?
SCSD2 How large would this change of size in the social Negatively significant Insignificant Positively significant Swinkels (2016)
system be?

Code Complexity of the Social System - Variety 1 2 3 4 5 Rating Source(s)

SCV1 What is the disciplinary variety of the team(s)? Monodisciplinary Interdisciplinary Multidisciplinary Maylor et al. (2013), Vidal et al. (2011), Crawford (2007) and
team(s) team(s) team(s) He et al. (2015)
SCV2 Is there cultural disparity between key Highly similar Somewhat similar Highly dissimilar Maylor et al. (2013), Vidal et al. (2011), Kim et al. (2003)
organizational actors? and He et al. (2015)
SCV3 How many different nationalities are involved in 1 Nationality 3 - 4 Nationalities 6 + Nationalities Bosch-Rekveldt et al. (2011) and He et al. (2015)
the project team(s)?
SCV4 How many different languages are used in the 1 Language 2 Languages 3+ Languages Bosch-Rekveldt et al. (2011)
project for work or work related communication?
SCV5 How large is the geographical distances between 0 km (Co-located in a 0 km (Co-located in a 100 - 200 km (Within 200 - 4000 km (Within 4000 + km (Within Bosch-Rekveldt et al. (2011), Qureshi et al. (2015), Vidal et
key organizational actors? shared office space) shared office building travel distance by car) short travel distance long travel distance al. (2011) and Kim et al. (2003)
by car/plane) by plane)

SCV6 How many overlapping office hours does the project 8 Hours 5 Hours 2 Hours 0 Hours (With normal 0 Hours (With Bosch-Rekveldt et al. (2011) and Maylor et al. (2013)
have because of different time zones involved? office hours) extended office
hours)
SCVD1 What is the likelihood that the variety of the social Highly unlikely Somewhat likely Highly likely Swinkels (2016)
system will change in the foreseeable future?
SCVD2 How large would this change in variety of the social Negatively significant Insignificant Positively significant Swinkels (2016)
system be?

Code Complexity of the Social System - Interdependence 1 2 3 4 5 Rating Source(s)

SCI1 Interdependence between teams Highly Independent Highly Dependent Highly Swinkels (2016)
Interdependent
SCI2 Interdependence within teams Highly Independent Highly Dependent Highly Swinkels (2016)
Interdependent
SCID1 What is the likelihood that the interdependence of Highly unlikely Somewhat likely Highly likely Swinkels (2016)
the social system will change in the foreseeable
future?
SCID2 How large would this change in the Negatively significant Insignificant Positively significant Swinkels (2016)
interdependence of the social system be?

Figure 5: Social Complexity.

27
Code Complexity of scope - Size 1 2 3 4 5 Rating Source(s)
CSS1 Number of Goals? 1 Goal 3 - 4 goals 6 + Goals Bosch-Rekveldt et al. (2011)
CSS2 Number of Deliverables? 1 Deliverable 3 Deliverables 5 + Deliverables Bosch-Rekveldt et al. (2011) and Vidal et al. (2011)
CSSD1 What is the likelihood that the size of the project Highly unlikely Somewhat likely Highly likely Swinkels (2016)
scope will change in the foreseeable future?
CSSD2 How large would this change in size of the project Negatively significant Insignificant Positively significant Swinkels (2016)
scope be?

Code Complexity of scope - Variety 1 2 3 4 5 Rating Source(s)

CSV1 Is there variety between the goals? Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
CSV2 Are the project goals aligned towards a similar Highly aligned Somewhat aligned Misaligned Bosch-Rekveldt et al. (2011)
purpose?
CSV3 Is there variety between the deliverables? Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
CSV4 Are the project deliverables aligned towards a Highly aligned Somewhat aligned Misaligned Swinkels (2016)
similar purpose?
CSV5 is there variety in the strategic importance of the Highly similar Somewhat similar Highly dissimilar Maylor et al. (2013)
project scope for the various actors within the
project?
CSV6 Variety in design standards and country specific Highly similar Somewhat similar Highly dissimilar Bosch-Rekveldt et al. (2011)
norms
CSVD1 What is the likelihood that the variety of the project Highly unlikely Somewhat likely Highly likely Swinkels (2016)
scope will change in the foreseeable future?

CSVD2 How large would this change in variety of the Negatively significant Insignificant Positively significant Swinkels (2016)
project scope be?

Code Complexity of scope - Interdependence 1 2 3 4 5 Rating Source(s)

CSI1 Are the goals dependent upon each other? Highly Independent Highly Dependent Highly Vidal et. al. (2011) and Qureshi et al. (2015)
Interdependent
CSI2 Are the deliverables dependent upon each other? Highly Independent Highly Dependent Highly Swinkels (2016)
Interdependent
CSID1 What is the likelihood that the interdependence of Highly unlikely Somewhat likely Highly likely Swinkels (2016)
the project scope will change in the foreseeable
future?
CSID2 How large would this change in interdependence of Negatively significant Insignificant Positively significant Swinkels (2016)
the project scope be?

Figure 6: Complexity of Scope.

28
Code Product Service System Complexity - Size 1 2 3 4 5 Rating Source(s)
PSCS1 In how many modules can the design of the > 3 Modules 6 - 7 Modules > 10 modules Swinkels (2016)
product/service system be divided?
PSCSD1 What is the likelihood that the size of the Highly unlikely Somewhat likely Highly likely Swinkels (2016)
technological system will change in the foreseeable
future?
PSCSD2 How large would this change in the size of the Negatively significant Insignificant Positively significant Swinkels (2016)
technological system be?

Code Product Service System Complexity - Variety 1 2 3 4 5 Rating Source(s)

PSCV1 How many technical disciplines are required on Mono-disiplinary multi-disciplinary multi-disciplinary Swinkels (2016)
average for one module? (e.g. electrical -, work work (3 disciplines) work (5+ disciplines)
mechanical -, ICT engineering)
PSCVD1 What is the likelihood that the variety within the Highly unlikely Somewhat likely Highly likely Swinkels (2016)
technological system will change in the foreseeable
future?
PSCVD2 How large would this change in the variety of the Negatively significant Insignificant Positively significant Swinkels (2016)
technological system be?

Product Service System Complexity -

Code Interdependence 1 2 3 4 5 Rating Source(s)
PSCI1 How (inter)dependent are the designs of the Highly Independent Highly Dependent Highly Swinkels (2016)
product/service modules? Interdependent
PSCID1 What is the likelihood that the interdependence Highly unlikely Somewhat likely Highly likely Swinkels (2016)
within the technological system will change in the
foreseeable future?
PSCID2 How large would this change in the Negatively significant Insignificant Positively significant Swinkels (2016)
interdependence of the technological system be?

Figure 7: Product Service Complexity.

29
Code Socio-political system - Size 1 2 3 4 5 Rating Source(s)
SPCS1 Signigifance of the public agenda on the project Insignificant Somehwat significant Highly significant Vidal et. al. (2011)

SPCS2 Impact of local laws and regulations No impact Some impact High impact Bosch-Rekveldt et al. (2011), Crawford et al. (2007), Vidal
et al. (2011) and Nguyen et al. (2015)
SPCS3 Necessity of new laws and regulations No new laws and Some adjustments in Complete new set of Vidal et. al. (2011), Qureshi et al. (2015) and He et al. (2015)
regulations required laws and regulations laws and regulations
required required
SPCSD1 What is the likelihood that the size of the socio- Highly unlikely Somewhat likely Highly likely Swinkels (2016)
political system will change in the foreseeable
future?
SPCSD2 How large would this change of size in the socio- Negatively significant Insignificant Positively significant Swinkels (2016)
political system be?

Code Socio-political system - Variety 1 2 3 4 5 Rating Source(s)

SPCV1 Variety in public opinion Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
SPCV2 Variety in local laws and regulations Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
SPCV3 Variety in implementation of new laws and Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
regulations
SPCV4 Variety of local law making processes Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
SPCVD1 What is the likelihood that the variety of the socio- Highly unlikely Somewhat likely Highly likely Swinkels (2016)
political system will change in the foreseeable
future?
SPCVD2 How large would this change in variety of the socio- Negatively significant Insignificant Positively significant Swinkels (2016)
political system be?

Code Socio-political system - Interdependence 1 2 3 4 5 Rating Source(s)

SPCI1 Interdependence between lawmakers and the Highly Independent Highly Dependent Highly Swinkels (2016)
project Interdependent
SPCI2 Interdependence between public stakeholders and Highly Independent Highly Dependent Highly Swinkels (2016)
the project Interdependent
SPCI3 Interdependence between lawmakers and public Highly Independent Highly Dependent Highly Swinkels (2016)
stakeholders Interdependent
SPCID1 What is the likelihood that the interdependence of Highly unlikely Somewhat likely Highly likely Swinkels (2016)
the socio-political system will change in the
foreseeable future?
SPCID2 How large would this change in the Negatively significant Insignificant Positively significant Swinkels (2016)
interdependence of the socio-political system be?

Figure 8: Social-political Complexity.

30
Code Business Environment - Size 1 2 3 4 5 Rating Source(s)
BECS1 How many organizations in the value chain None 3 - 4 Organizations 7+ Organizations Swinkels (2016)
predominantly add value through the
manfucaturing or assembly of components and
systems?
BECS2 None 3 - 4 Organizations 7+ Organizations Swinkels (2016)
How many organizations in the value chain
predominantly add value through the marketing or
sales of the product/service to the end-customer?
BECS3 How many organizations in the value chain None 3 - 4 Organizations 7+ Organizations Swinkels (2016)
predominantly add value through complementary
products/services?
BECS4 How many distinct market segments are targeted in 1 Target market 3 Target markets 5+ Target markets Swinkels (2016)
the marketing strategy (e.g. different user-
profiles)?
BECS5 How many distinct countries are targeted in the 1 Country 4 - 6 Countries 9+ Countries Swinkels (2016)
marketing strategy?
BECS6 How many competing products/services are Monopoly Oligopoly Pure competition Bosch-Rekveldt et al. (2011), Qureshi et al. (2015) and Vidal
targeting the same market spaces? et al. (2011)
BECSD1 What is the likelihood that the size of the Highly unlikely Somewhat likely Highly likely Swinkels (2016)
ecosystem will change in the foreseeable future?
BECSD2 How large would this change of size in the Negatively significant Insignificant Positively significant Swinkels (2016)
ecosystem be?

Code Business Environment - Variety 1 2 3 4 5 Rating Source(s)

BECV1 Variety in strategic importance of the project for the Highly similar Somewhat similar Highly dissimilar Crawford et al. (2007)
ecosystem members
BECV2 Are different ecosystem members involved in Highly similar Somewhat similar Highly dissimilar Swinkels (2016)
different target markets?
BECV3 Are different ecosystem members involved in Highly similar Somewhat similar Highly dissimilar Bosch-Rekveldt et al. (2011)
different target countries?
BECVD1 What is the likelihood that the variety of the Highly unlikely Somewhat likely Highly likely Swinkels (2016)
ecosystem will change in the foreseeable future?
BECVD2 How large would this change in variety of the Negatively significant Insignificant Positively significant Swinkels (2016)
ecosystem be?

Code Business Environment - Interdependence 1 2 3 4 5 Rating Source(s)

BECI1 Interdependence between ecosystem members Highly Independent Highly Dependent Highly Bosch-Rekveldt et al. (2011), Qureshi et al. (2015) and Vidal
Interdependent et al. (2011)
BECI2 Variety in Interdependence between ecosystem Equal dependence Somewhat skewed Highly skewed Swinkels (2016)
members dependence dependence
BECID1 What is the likelihood that the interdependence of Highly unlikely Somewhat likely Highly likely Swinkels (2016)
the ecosystem will change in the foreseeable
future?
BECID2 How large would this change in the Negatively significant Insignificant Positively significant Swinkels (2016)
interdependence of the ecosystem be?

Figure 9: Complexity of the Business Environment

31
 4.2 A novel framework for practice
In the literature study previously conducted, eighteen articles were selected from scholarly literature
on the topic of the measurement of project complexity. A review and synthesis of these articles
resulted in a theoretical model of project complexity supported by a project complexity assessment
framework. The model helps explains both the antecedents – and consequences of project complexity,
while the framework provides extensive guidance on the assessment of project complexity. While
these two deliverables add to the knowledge base of project complexity within the literature, feedback
from practice indicates that there is a desire for a highly simplified assessment framework to aid in the
pragmatic analysis of project complexity in the ‘field.’

While this study has taken considerable steps towards providing clear and unambiguous survey items,
experience from the research shows that many survey items still require a high degree of
interpretation from the researcher to analyze any particular project. Since essentially any aspect of a
project can add to the complexity of a particular sub-dimension of project complexity, any project
complexity assessment tool that attempts to capture the full extent of project complexity requires a
high number of specialized items to cover the many aspects of a project. This provides two challenges
to the assessment of project complexity. First of all, simply many items are needed to properly analyze
project complexity. However, each item may require one or several (often abstract) definitions to
understand both the question and the answer categories. Thus secondly, the analysis of project
complexity requires researchers and practitioners to all have a shared understanding of many
definitions on the subject of project complexity for the analysis to be reliable/reproducible.

The current project complexity assessment framework has many items and requires a high familiarity
with the project management and project complexity literature to interpret the questions, which
makes the assessment framework less useful for field use. From this perspective then, the feedback
from practice makes sense. Since the analysis of project complexity is useful for both practitioners and
researchers however, both groups still require valid and reliable tools for the assessment of project
complexity.

While it would enable the exchange of knowledge between practice and literature to have a single
standard for such tools, the different usage cases of the two groups makes for a compelling argument
to develop two analysis frameworks. The researchers could conduct broad and in depth analyses of
project complexity to generate understanding of the many different factors that add to complexity,
and to consider which factors add to complexity the most. While practitioners could utilize a simplified
project complexity assessment framework which captures these most important factors of project
complexity, requires less understanding of abstract or theoretical definitions and is generally more
easy to use. The practitioners can then reflect on the best ways to manage the challenges created by
these most influential factors of project complexity after which this knowledge can be fed back in both
the management and scholarly literature.

Drawing from practice - a baseline framework

So far this study has considered the project complexity frameworks that have been developed by
researchers. Since this framework is intended for practical use however, it makes sense to broaden the
scope of the research to also consider project complexity frameworks from practice. One such
framework is proposed by Darnall and Preston (2010) whom developed the ‘Darnall-Preston
Complexity Index’ to measure project complexity. Alternatively, the case company itself also
developed a project complexity framework based on the collective insights from a set of experienced
project managers.

32
Since the new framework is intended to be used in the case setting in the future, the case
organization’s own project complexity framework is used as a baseline. By utilizing the current
assessment as a platform to improve, the new framework will remain familiar with its intended users,
thereby increasing the likelihood that it will be adopted across the organization.

Before any improvements can be suggested, the baseline framework must first be reviewed to
consider whether the current structure of the framework and its elements are appropriate. Within the
previous sections of the thesis, size, variability and interdependence were identified as driving factors
of project complexity. Additionally, changes or dynamics in the project were recognized as another
important factor to include the analysis. Finally, the familiarity of the project team with the project
was noted as a crucial factor in reducing the perceptual challenges that may further inhibit the project
team’s ability to understand and manage the project.

The baseline framework considers the content of the project, the stakeholder complexity and the
teamwork within the project, utilizing nine items, in three categories to estimate a project’s
complexity. See Figure 10 for the base-line project complexity framework. Items 1 and 2 relate to the
project’s product service offering and scope respectively and item 3 considers the socio-political
environment of the project. Items 4 through 7 all capture organizational aspects of the project, while
items 8 and 9 capture social aspects. Notably, no items on interdependencies within the project are
included into the base-line framework. While items 1 and 9 relate to topics of familiarity and item 2
relates to the dynamics of the scope.

A large number of authors have highlighted technological newness/familiarity/experience in some

form or another as an aspect of project complexity (Bosch-Rekveldt et al. 2011, Maylor et al. 2013,
Nguyen et al. 2015 and He et al. 2015). Despite that the baseline model was developed independently
from the literature, there is considerable support for the inclusion of item one: ‘Newness of
technology, products and markets’ in the model. In fact, most of the items included in the baseline
model can be supported by the literature.

Item two: ‘Stability of the overall project definition’ for example can be supported by Bosch-rekveldt
et al. (2011) and He et al. (2015) which both also included uncertainties of the scope and goals in their
respective frameworks. Extensive mention is made of the influence of politics, policies, laws and
regulations on the overall project complexity within the literature (Bosch-Rekveldt et al., 2011; Nguyen
et al., 2015). There is thus ample academic support for item three: ‘Magnitude of Legal, social and
environmental implications from performing the project.’ Financial aspects in terms of size of
investment and variety of financial resources were included in the frameworks proposed by both Vidal
et al. (2011) and Bosch et al. (2011), providing academic support for item four: ‘Overall expected
financial impact on project stakeholders.’ Similarly, item five: ‘Strategic importance of the project to
the involved organizations’ can be supported by both Bosch-Rekveldt et al. (2011) and Vidal et al.
(2011) whom both consider the variety of stakeholder interests. Unlike item six: ‘Stakeholder cohesion
regarding the characteristics of the type of business/activity (size, functional role, public/private)’
which was the only item in the baseline framework which could not be verified in the literature. Item
seven: ‘Number of interfaces between partners and departments within partner’s organization (like
legal, marketing, R&D)’ can be supported by Bosch-Rekveldt et al. (2011) and Vidal et al. (2011). Vidal
et al. (2011) considered the cultural variety within a project as one of the key aspects of organizational
project complexity. He et al. (2015) considers the effects of culture so important on the overall project
complexity that cultural complexity was considered a separate dimension of project complexity. There
is thus considerable support for item eight: ‘Cultural variety of the team members.’ Both Bosch-
rekveldt et al. (2011) and He et al. (2015) both include notions of experience with parties and
organizational member, providing support for item nine: ‘Collaboration complexity’.

33
PROJECT NAME:
Name of assessor:

Your note/output (please choose Your comments (please put additional

Element Simple Medium Complex
the most relevant type element) comments if you have any)

New product with new technology in

Newness of technology, products and markets
Stability of overall project definition (success
criteria, scope, requirements, methodology(ies),
limitations and flexibility)
Magnitude of Legal, social and environmental
implications from performing the project
Overall expected financial impact on project
stakeholders
New product in familiar market
Stable project definition; will not
change in foreseeable future.
Project execution and implications
within existing legislation and public
opinion or expectation
No financial impact on project
stakeholders
New product in unfamiliar market
Project definition might still change in Project requires further defining in
minor areas in foreseeable future.
Project execution and implications
challenge the existing legislation and
public opinion or expectation
For all partners it has a similar
proportional financial impact
unfamiliar market
foreseeable future.
Project execution and implications
outside the existing legislation and
public opinion or expectation
Varying distribution of financial impact
per partner (not over time but per
partner)

Strategic importance of the project to the involved No strategic importance to involved For all partners similar strategic Different strategic importance per
organizations partners importance partner (not over time but per partner)

Stakeholder cohesion regarding the characteristics

of the type of business/activity (size, functional
role, public/private)
Number of interfaces between partners and
departments within partners organization (like
legal, marketing, R&D)
Cultural variety of the team members (ref.
Trompenaars chart, see last slide)
Collaboration complexity
Project complexity:
Overall project complexity: Medium
Only similar stakeholder profiles
3 Interfaces
All in same quadrant
All partners have worked together
before in a project (not necessarily all
in the same project)
0 0
Limited differences of stakeholders
profiles
4-7 Interfaces
1 in other quadrant
Two key partners have worked
together before in project(s)
Different stakeholder profiles
More than 7 Interfaces
In more than 2 different quadrants
All partners are new to each other, they
have never worked together before in a
project
0

Content of project Simple: max 1 score complex, max 4 score medium

Stakeholder complexity (impact) Medium: all situations between simple and complex
Teamwork in project Complex: at least 3 elements score complex, at least 2 score medium (or higher)

Figure 10: Baseline project complexity framework.

34
Integrating practice and literature - a new pragmatic framework
Having developed the extensive framework for research, and having reviewed the base-line
framework, a new framework for practice can now be proposed which is quick to use (limited number
of items), clear/easy to use (unambiguous questions and scales) and useful to interpret (frames the
items in broader categories of project complexity).

Arguably the largest change to the original framework is the (re)categorization of the items. Where
the base-line framework considered the content of the project, the stakeholder complexity and the
teamwork of the project, the new framework considers the project definition, project organization and
project environment. These three categories represent the technological -, organizational - and
environmental complexity faced by the project as advocated by Bosch-Rekveldt et al. (2011), but are
reframed to enable the ease of interpretation. While authors such as He et al. (2015) and Nguyen et
al. (2015) advocate a larger number of dimensions of project complexity, the number of categories
was limited to three for the sake of the simplicity of the analysis framework.

The new pragmatic project complexity assessment framework includes four items on the complexity
of the project definition, ten items on the complexity of the project organization and a final three items
on the project environment. All nine original items have been included in the new framework, although
two items have been rephrased slightly.

PD1: ‘Stability of the overall project definition’ was copied directly from the case setting and can be
supported by Bosch-rekveldt et al. (2011) and He et al. (2015) which both also included uncertainties
in the scope and goals. PO4: ‘Overall expected financial impact on project stakeholders’ was included
in the original base-line assessment framework. Financial aspects in terms of size of investment and
variety of financial resources were included in the frameworks proposed by both Vidal et al. (2011)
and Bosch et al. (2011), thus supporting the inclusion of the original base-line item. PO5: ‘Strategic
importance of the project to the involved organizations’ was included in the original base-line
framework, and can be supported by both Bosch-Rekveldt et al. (2011) and Vidal et al. (2011) whom
both consider the variety of stakeholder interests. PO7: ‘Number of interfaces between partners and
departments within partner’s organization (like legal, marketing, R&D)’ was included both in the base-
line framework and in the frameworks proposed by Bosch-Rekveldt et al. (2011) and Vidal et al. (2011).
PE3: ‘Magnitude of Legal and social implications from performing the project’ is adopted directly from
the base-line framework, although extensive mention is made of the influence of politics, policies, laws
and regulations on the overall project complexity within literature such as Bosch-Rekveldt et al. (2011)
and Nguyen et al. (2015).

In terms of project dynamics, the base-line framework already included one item, e.g. ‘Stability of
overall project definition’, which captures the dynamics of the project definition. To limit the number
of items on project dynamics, the framework included one item on dynamics per dimension of project
complexity. Two items were thus added to capture the dynamics of the project organization: ‘Stability
of project organization (project manager, project members, dedication of resources, contracts and
organization of work)’ and the project environment: ‘Stability of the project environment (legal and
social).’

In terms of project familiarity, the base-line framework already included two items, e.g. ‘Newness of
technology, market and product’, and ‘Collaboration complexity.’ The item ‘Newness of technology,
market and product’ was split into ‘Familiarity with the project definition’ and ‘Familiarity with the
project definition’ to provide more concise answer categories. The item ‘Collaboration complexity’ was
rephrased into ‘Familiarity with the project organization’ while the answer categories were retained.
As the previous three items dealt with the familiarity of the project team with the project definition

35
and project organization, a fourth item was added to capture the familiarity of the project team with
the project environment: ‘Familiarity with the project environment (legal and social).’

Of the nine items suggested from practice, eight were directly supported by the literature. ‘Stakeholder
cohesion’ was not specifically mentioned within the reviewed literature, but does align with the
concepts of stakeholder variety discussed in the model presented in chapter three, and was thus also
retained. Four items were furthermore added based on their extensive use within the literature, and
general ease of use for analysis. Within the category of project definition, the item: ‘Is the scope clear
and aligned with the end-user needs?’ was added to capture the complexities which can result from a
vague or poorly aligned project scope. Academic support was high as several authors highlighted
different aspects of this item (Bosch-Rekveldt et al., 2011, Maylor et al., 2013 and Nguyen et al. 2015).

Within the category of the project organization, three additional items were added. The item ‘Number
of companies / projects sharing their resources’ was described by Vidal et al. (2011) as one of the most
important aspects to influence project complexity, and was furthermore included by Bosch-rekveldt et
al. 2011 and He et al. (2015). Since the item is objectively measurable and easy to answer, the inclusion
of the question furthermore fits with the previously set criteria. Team cooperation and communication
is considered as one of the core aspects of project complexity by Vidal et al. (2011). Aspects of
interdependence between organizations, departments, stakeholders and teams are furthermore
considered in both He et al. (2015) and Nguyen et al. (2015). Given this overwhelming emphasis on the
collaborative relation between organizations or teams, the item ‘The work will be carried out by
independent teams’ was included into the framework.

The cultural variety of the team members was highlighted by both Vidal et al. (2011) and He et al.
(2015). Vidal et al. (2011) considered the cultural variety within a project as one of the key aspects of
organizational project complexity. He et al. (2015) considers the effects of culture so important on the
overall project complexity that cultural complexity was considered a separate dimension of project
complexity. While the base-line framework already included an item on culture, Vidal et al. (2011),
Maylor et al. (2013) and Bosch-Rekveldt et al. (2011) further highlighted geographical and temporal
variety between key project participants as one of the core aspects of project complexity. As such, the
item: ‘The work will be carried out in a single country/timezone/location’ was added.

Since the assessment framework has a limited number of elements, the overall score of each
dimension of project complexity can be calculated by averaging the scores of each respective element.
For example, a complexity estimate of the project definition can be calculated by averaging PD1, PD2,
PD3 and PD4. The complexity of the whole project can in turn be calculated by taking the natural
logarithm of the product of the complexity estimates of each dimension.

Table 1 shows the finished pragmatic project complexity assessment framework. The new framework
is based on a more coherent structural analysis of the project and it’s most important aspects, is based
on the combined insights of both practitioners and researchers and has been developed with ease of
use in mind. As a result, this framework should be familiar to - and simple to use for users of the base-
line framework, while extending the potential insights that an analysis of project complexity can
provide. The new framework furthermore is based on a more elaborate review of the project
complexity literature, thereby enhancing the legitimacy of the tool. The majority of factors that add to
project complexity are organizational in nature. This observation is in line with the comments of Vidal
et al. (2011b, p721) which posited that 16 of the 18 most influential drivers of project complexity found
in their study are organizational in nature. The new assessment tool focuses primarily on organizational
factors, while supplementing the analysis with factors on the project definition and environment.

36
Table 1: Pragmatic Project Complexity Assessment framework.
Scale Score
Project definition 1 2 3
PD1 Stability of the overall project definition Stable project definition; Project definition might still Project definition requires
(success criteria, scope, requirements, will not change in change in minor areas in further defining in
methodology(ies), limitations and flexibility) foreseeable future. foreseeable future. foreseeable future.

PD2 Familiarity with the project definition Familiar product with New product with familiar New product with new
(Newness of technology and product) familiar technology, technology, innovation technology, radical
incremental innovation. through combination of innovation.
technologies.

PD3 Familiarity with the project definition (Market Familiar market with Unfamiliar market with Unfamiliar market with
and business model) familiar business model. familiar business model. unfamiliar business model.

PD4 Is the scope clear and aligned with the end-
user needs?
The end-user needs are
clear, the project scope is
highly aligned with the end-
user needs and is clear to all
project participants.
The end-user needs are not
entirely understood yet, the
scope is still broad to allow
for multiple interpretations
of the end-user needs.
No clear end-user needs can
be known as the project will
develop an entirely new
type of product or serivce.

Scale Score
Project organization 1 2 3
PO1 Stability of project organization (project Stable project organization Project organization might Project organization
manager, project members, dedication of will not change in still change in minor areas requires further defining in
resources, contracts, organization of work) foreseeable future. in foreseeable future. foreseeable future.
PO2 Familiarity with the project organization All partners have worked Two key partners have All partners are new to each
(Collaboration complexity) together before in a project worked together before in other, they have never
(not necessarily all in the project(s) worked together before in a
same project) project
PO3 Number of companies / projects sharing their 1 - 3 Organizations 4 - 6 Organizations 7 + Organizations
resources
PO4 Overall expected financial impact on project No financial impact on For all partners it has a Varying distribution of
stakeholders project stakeholders similar proportional financial impact per partner
financial impact (not over time but per
partner)
PO5 Strategic importance of the project to the No strategic importance to For all partners similar Different strategic
involved organizations involved partners strategic importance importance per partner (not
over time but per partner)

PO6 Stakeholder cohesion regarding the Only similar stakeholder Limited differences of Different stakeholder
characteristics of the type of business/activity profiles stakeholders profiles profiles
(size, functional role, public/private)

PO7 Number of interfaces between partners and 3 Interfaces 4-7 Interfaces More than 7 Interfaces
departments within partners organization
(like legal, marketing, R&D)

PO8 Cultural variety of the team members (ref. All in same quadrant 1 in other quadrant In more than 2 different
Trompenaars chart, see last slide) quadrants
PO9 The work will be carried out by independent The work in carried out by a The work is carried out by The work is carried out by
teams single project team. several project teams several project teams
independently of each working closely together,
other, with semiannual with weekly or monthly
coordination meetings coordination meetings

PO10The work will be carried out in a single 1 - 2 Nationalities, 8 3 - 4 Nationalities, 6 5 or more Nationalities, 4
country/timezone/location overlapping office hours overlapping office hours or less overlapping office
and all partners located and all partners located hours and all partners
within 200 km of each within 200 to 1000 km of located within 1000 km or
other each other more of each other
Scale Score
Project Environment 1 2 3
PE1 Stability of the project environment (legal and Stable project environment Project environment might Project environment will
social) will not change in still change in minor areas experience considerable
foreseeable future. in foreseeable future. changes in the foreseeable
future.
PE2 Familiarity with the project environment Familiar laws and familiar Familiar laws and unfamiliar Unfamiliar laws and
(legal and social) public stakeholders public stakeholders unfamiliar public
stakeholders
PE3 Magnitude of Legal and social implications Project execution and Project execution and Project execution and
from performing the project implications within existing implications challenge the implications outside the
legislation and public existing legislation and existing legislation and
opinion or expectation public opinion or public opinion or
expectation expectation

37
 5. Managing project complexity – Exploring strategies & methods
During a project’s lifecycle, there is typically one document which determines the majority of the
project’s structure. The ‘project plan’ provides a comprehensive overview of the project, specifying
the overall aim, budget, scope and arrangement of the project. Work packages, task schedules,
budgets, requirements and specifications are described in detail and together form a basis of the
project’s organization.

Projects have previously been described as open systems following systems thinking. Within systems
theory, the importance of the initial state of a system is often emphasized. Depending on the initial
conditions a system may behave drastically different, as small changes proliferate through the system.
Within the context of project management, the initial conditions of the project system are effectively
determined by the project plan.

When managing project complexity, it is thus important to realize that the project complexity is to a
large degree inherently designed into the project as a result of the project definition. Due to the
sensitivity of the project system to its initial conditions, the most effective method to manipulate the
project complexity is to consciously design the project such that the initial project complexity is in line
with the desired project complexity. Alternatively, as the project team realizes that a project is
becoming too complex over the course of the project’s development, they may decide to change the
project complexity by redefining the project system.

The principal aim of the thesis is to explore how complex projects can and/or should be managed.
Maylor et al. (2013) notes that while project complexity can be managed by either removing the
sources of complexity or by reducing their impact, the first response should be the active selection of
complex projects. By estimating a project’s complexity before taking on a particular project, the fit
between the project and the organization can be considered. When a project includes particular
complexities which the organization has not faced before, the decision can be made to acquire the
necessary competences from outside of the organization, train the project team or to even kill the
project.

Project staffing is proposed as a secondary response to manage the complexity of a project. It is

particularly important that the skills of the project manager align with the complexities faced by the
project, as the project manager is tasked with maintaining an overview of the project. When a project
is particularly complex on one dimension of project complexity, and the project manager lacks the
appropriate skills and experiences to manage the complexity of that dimension, it becomes more likely
that the negative effects of that dimension are underestimated and consequently poorly managed.

Maylor et al. (2013) considers the overall project management methodology or approach used by the
project in relation to the project’s complexity as the third and final method to manage project
complexities. The authors propose that particular project management approaches may be better
suited to manage projects experiencing particular complexities. Maylor et al. (2013) hypothesize that
more formal processes may be more appropriate to manage structural complexities, while more
flexible management approaches may be more suitable to deal with dynamic complexities.

Maylor et al. (2013) considers the project’s composition, and the chosen project management
methodology as the driving factors that will determine how the project team will be able to deal with
the project’s complexity. By considering these aspects during the project definition phase of the
project, the projects management team will set the conditions for future success.

38
 5.1 Project complexity management approaches – a general overview
Project complexity stems from the collective behavior of the project system. To influence a project’s
complexity, a system wide change is most effective. It is therefore more useful to consider the effects
of different project management approaches on the project system, rather than the effects of
individual methods on the project’s subsystems.

Maylor et al. (2013) considered the impact of project management methodologies and hypothesized
that more formal processes may be more appropriate to manage structural complexities, while more
flexible management approaches may be more suitable to deal with dynamic complexities. The study
however did not attempt to further elaborate on these claims. Maylor et al. (2008) previously
recognized the dissatisfaction of traditional command-and-control project management strategies in
complex projects, and noted the increasing popularity of agile project management approaches as a
response to the increasing need for more adaptive processes in highly dynamic environments.

Hussein et al. (2014) identified two alternative approaches to deal with project complexity. The first
approach emphasizes the importance of early planning and early alignment of tasks and
responsibilities. The approach furthermore recommends the creation of robust work packages and the
minimization of the number of tasks. The second approach relies less on a preplanned process, instead
the plan is created as the project unfolds, relying upon the competences of the project manager and
the project team to make decisions based on the current state of the project.

Pich et al. (2002) identified three project management strategies. ‘Instructionism’ advocates the
avoidance of uncertainty through extensive planning, buffers, risk lists and contingency plans.
Alternatively, the project may utilize a ‘learning’-strategy. Rather than utilizing a comprehensive plan,
the project manager has an overall vision of the project’s goals. Detailed plans only exist for the next
tasks, while the project team continuously scans for new events. Flexibility and lateral coordination
are furthermore emphasized. Finally, the ‘selectionism’-strategy prescribes the parallel execution of
multiple trial projects. Several solutions to the same problem are simultaneously developed, the
intermediate results of the projects are shared to encourage learning while the performance of the
solutions is evaluated and compared based on a set of hurdles. Based on these results, the best
solution is further developed while the other solutions are abandoned, although all contributions of
all projects are considered as valuable.

Maylor et al. (2013), Maylor et al. (2008), Hussein et al. (2014) and Pich et al. (2002) all attempted to
distinguish the effectivity of different project management approaches in relation to their ability to
successfully manage complex projects. While the articles provide some guidance on the practical effect
of different project management approaches on project complexity, the proposed approaches are
described so concisely that it is difficult to directly use their insights in a practical setting.

Adler (1999) provides comprehensive descriptions of three alternative approaches to manage complex
product development projects. The study is the amalgamation of a PhD research spanning roughly five
years. As a result, Adler was able to reflect upon the dominant literature much more thoroughly, and
was able to set up an elaborate research project to study the project management methods used in
practice. Due to the breadth of scope and depth of analysis, the insights generated by Adler (1999) will
be used as the principle source to describe alternative project complexity management approaches.
The following section will summarize the core insights of Adler (1999), emphasizing the practicalities
of each approach. By redescribing the work of Adler (1999), the contributions of this section to the
literature may not be novel, but rather practical by providing a comprehensive yet concise summary
of a vast research subject which took Adler over 500 pages to describe.

39
Adler (1999) combined aspects of clinical organization research, action science, abduction and
intervention research to develop an alternative research methodology. Adler coined his research
methodology ‘table tennis research’ after the close collaboration between the researcher(s) and
practitioner(s) involved in the project. Table tennis research can be characterized through five core
characteristics; Inspired from clinical organization research and action science methods, the researcher
strives to integrate him or herself into the practitioner’s traditional domain. In turn, the practitioners
strives to integrate themselves into the research domain. As a result, researchers gain more insight
into the challenges faced by practitioners, while practitioners are able to absorb more knowledge from
the literature. From practice, ‘red hot’ issues are selected to be studied in real time, ensuring the
practical relevance of the research. Table tennis research furthermore strives for ‘transdisciplinarity‘
to capture as many different perspectives, thereby increasing the understanding of the research topic.
Finally, a multitude of data collection methods were utilized to gather data and to triangulate research
findings, although the core mode of data collection was the use of workshops.

Adler conducted an extensive literature review, drawing from three distinct schools of thought to
comprehend the management of complex development projects in its entirety. The Project
Management School of thought originally comes from and builds upon the accumulated experiences
and knowledge of project managers from the field. The literature is planning-oriented and projects are
organized based on the tasks which are to be executed. Work tasks and activities are structured
according to Work Breakdown Structures, while tools such as Gantt charts, PERT and CPM are used to
monitor the project’s progress. All projects go through a similar life cycle, starting with a goal setting
phase, followed by planning, execution and conclusion phases. Goals are locked in as early as possible
to avoid uncertainty and changes in the project system.

The school of Organizational Theory can be divided into five different sub-fields. Each field advocates
different principles to divide and coordinate the work. As a result of these different perspectives, the
school of organizational theory provides a spectrum of alternative recommendations, where the
‘bureaucracy school’ advocates standardization and clarity of responsibility, while the ‘Human
relations and Organizational Development School’ argues that project participants require large
degrees of freedom in order to successfully deal with complex challenges. ‘cognitive theory’ advocates
the creation of shared mental models amongst the project participants. ‘Institutional theory’ promotes
the use of institutions and rules to provide support and clarity for project members. ‘Contingency
theory’ finally notes that the right solution is dependent upon the environment in which it will be used.

The School of Management of Technology explores multiple strategies to deal with complex projects,
drawing from different basic assumptions of rationalistic -, bounded – and emergent rationality. A
rationalistic approach emphasizes planning and is proposed to perform better within stable markets
and technologies. On the opposite of the spectrum, the emergent approach utilizes flexible informal
structures combined with early and frequent integration of tasks and activities. The emergent
approach is suggested as appropriate when uncertainties are high and requirements change frequently
and/or are unpredictable.

A considerable overlap exists between the three schools of thought. By further exploring these
overlapping aspects, two alternative views on the management of complex product development
projects can be considered.

The ‘planning-and design-intensive perspective’ is based upon the assumption that complex product
development projects can be broken down into predictable processes. Activities can occur
independently of each other and are coordinated through formal control methods such as project
schedules and budgets.

40
The ‘organic/dynamic perspective’ alternatively assumes that emerging components in complex
projects significantly limit the usefulness of rigorous project plans. As a result, project plans should be
abandoned and the project manager should focus on nurturing the conditions which allows the project
team to manage unexpected situations in real time.

The planning-and design-intensive perspective stems from the linear planning models of the project
management school, supplemented by bureaucratic models of the school of organization theory and
the rationalistic and bounded rationality approaches described by the school of management
technology. The planning and design-intensive approach has dominated the traditional literature in
the past with dominant literature and practices in the area of complex product development processes
emphasizing that complex projects are best managed by breaking down the project into individual,
and independent parts. Uncertainty should be separated from complex parts, and managed by
rigorous planning and control. Components should be developed independently and integration
should only occur once the components are considered stable.

Despite the popularity of the planning-and design-intensive approach, managing complex product
development projects by breaking down the project into independently manageable parts may cause
numerous problems during the development process. Linear project management approaches have
been criticized widely as they appear to struggle to deal with more dynamic environments, while
examples of high-performing organizations in highly dynamic, global environments can be found which
consistently meet or even exceed targets while utilizing alternative perspectives. Within practice, new
approaches continue to be explored, often advocating flexibility and early integration over separation
and planning.

Adler (1999) aims to explore which successful new approaches have been developed in practice and
studies how these new approaches manage complex product development projects differently. By
comparing the new approaches with the dominant planning based project management approach, the
respective strengths and weaknesses of each approach can be considered. When a project manager
would have to adopt a project management approach in the future, these aspects can be taken into
account to improve the fit between the chosen management method and the project.

To study the project management approaches used in practice, Adler (1999) studied ten research
projects in seven different organizational settings within the telecommunications divisions of Ericsson.
Data was collected for over two years in longitudinal case studies in six of the seven organizational
settings. The seventh organizational setting was shut down, preventing further follow-up. The ‘table
tennis’ mode of research utilized by Adler advocated the verification of research results through
triangulation of data. Many different methods of data collection were utilized to study the case
projects. 243 structured and unstructured open interviews were held with a variety of actors within
the projects. The actual work processes of nearly 50 people in two organizational settings were
analyzed on an in-depth level through activity and process maps, providing insight into the logic behind
the development work in each setting. Communicograms were additionally used to measure the
communication - and coordination patterns amongst the project teams. 87 people participated in
these analyses by filling out a series of general questionnaires and open ended questions. These
questionnaires were used to build and count the communication networks which provided insight into
the use of both formal and informal communication methods in different projects. During the five-year
research period the researcher kept close contact with the case settings, for two years the researcher
spent half of his time working within these research settings. During this period a diary was kept of the
researcher’s observations and a continuous dialogue was maintained with key representatives of each
case. 218 questionnaires were used to collect data on topics such as project control methods, climate
variables, key activities and competences. The questionnaires were furthermore used to validate the

41
identified patterns and phenomena which followed from the other data collection methods. During
the research process, the documentation of each project was systematically collected and analyzed to
further develop an understanding of each organizational setting and the logic utilized by the project
members. Documentation such as annual reports, balance sheets and project performance reviews
were utilized to verify the success of projects together with the previously mentioned interviews.

Workshops were used as the primary method of data collection within the study presented by Adler
(1999). 64 workshops were held in total, with over 1000 representatives participating over the course
of five years. On average ten to fifteen participants contributed to each workshop, although in some
cases as many as 200 project members participated in a single workshop. Preliminary research results
were used as input to the workshops, discussions were used to uncover new angles of interpretation,
refine the results, propose new research designs and validate the findings. The workshops were the
primary means to connect the researcher(s) and practitioner(s) and to exchange insights on the
research topic, thereby creating the conditions for Adler’s table tennis mode of research. Workshops
were hosted by the researcher, whom acted as a chairman to lead the discussion sessions. Employees
from all levels of the organization were invited to contribute to the workshops to ensure a wide variety
of perspectives The workshops provided a setting to discuss the most common and impactful
challenges faced by the practitioners, which were used as input to the research process. Preliminary
research results were constantly open to critic, and workshops often resulted in new perspectives and
changes to the research process.

Three different project complexity management approaches were found within the ten development
projects examined by the research. While different organizational settings utilized different
approaches, no project consciously utilized one approach over the others. Rather, the approaches had
naturally evolved over time to manage the particular challenges presented by the different research
settings. Although many of the beliefs and methods utilized to support the overall project management
approaches were explicitly recognized. None of the approaches presented were fully and constantly
applied in any of the organizational settings. The proposed approaches are ideal modes of project
management, in practice project managers may borrow concepts from multiple approaches to craft a
project specific methodology.

The literature overview previously noted the dominant emphasis on planning-based approaches to
manage project complexity within the academic literature. Adler’s review of the development projects
within Ericson reflected this view. Five out of the seven organizational settings studied within the
research utilized a planning based approach. The other two organizational settings utilized more
innovative methodologies. The approach utilized by the Japanese Systems group was coined
Integration-driven development, while the Japanese subsystems group utilized an emergent approach
based on dynamic synchronization.

The approach based on planning

As mentioned, the dominant approach in both literature and practice is the approach based on
planning. The approach effectively attempts to deductively optimize the project before its execution,
as an optimal way of executing the project tasks is proposed before the project starts based on the
information that is known of the project system. This project management methodology is based on
four fundamental assumptions related to how complexity can best be managed/controlled. (1) It is
assumed that the overall project can best be managed by separating the aspects of uncertainty from
the aspects of complexity. (2) Uncertainty is best managed by rigorous planning, (3) while complexity
is best managed by breaking the project down into small and easily controllable parts. (4) Specialized
resources are best able to execute tasks when the work is as independent from other influences as
possible, the resulting subsystems should only be integrated once they are considered stable.

42
As a rule of thumb, the product service offering is configured by breaking down the product
specifications into subsystem specifications. Depending on the overall scope of the project, the
subsystem specifications may be broken down further into sub-subsystem specifications. This process
may be repeated until subsystems are created which are relatively easy to manage. Independent
specialized sub-project teams are tasked with particular work tasks which define how a particular
subsystem must be developed to deliver on the required specifications. At every decision point or
milestone in the project, a detailed plan is created to specify which activities will be performed until
the next milestone. This actions within this plan will be used to control the project, as deviations from
the plan are minimized to ensure progress. Since decisions are made only periodically, the temporary
lack of clarity when no decision on a particular topic is enforced from the top-down, does provide
actors the freedom to pursue their own goals until a formal decision is reached. As tasks are organized
independently from each other, many tasks may be executed in parallel. Coordination between
parallel tasks is predominantly performed during formal decision points and is otherwise often non-
existing, as other development activities are considered black boxes. Once the development work on
a particular system is finished, and the performance of the subsystem is considered as stable or clean
from faults it will be integrated into the rest of the project.

As development tasks are considered as black boxes, the flow of lateral communication is mainly within
the subunits tasked with the execution of particular activities. A larger emphasis is placed on
hierarchical communication towards the project’s management. Formal progress reports and project
meetings are primarily used as tools for communication and progress control. The project’s
management in turn handles the integration and interdependencies of the project.

Integration is often performed late in the project, as the subsystems are only integrated once they
show stable performance. Designers hand over their individual solutions to the test engineers once
they are convinced that they have developed an optimal solution. The test engineers in turn check if
the subsystem performs within the context of the overall system. Failure during the test phase would
result in rework and often results in considerable delays in the project as the testing process is one of
the last phases in the project.

The approach based on integration driven development

The second approach found within Ericsson was developed in response to the increasing need to
develop projects with shorter lead times. As a project manager recalls: “To radically shorten lead-
times, it is a must that we start integration and verification of system functionality much earlier than
we ever have done before. This will require tight cooperation between the different parts of the
project" (Adler, 1999, p. 291). The approach based on integration-driven development has
fundamentally different assumptions regarding the management of project complexity. (1) Complexity
is best managed by identifying the interfaces between tasks which are the most troublesome, and
allocating the most skilled resources to these boundaries. (2) Uncertainty is best managed by
configuring the product and project such that uncertainties are identified early and relevant resources
are allocated to monitor them. (3) Control over the project is achieved by continuously integrating the
subsystems of the product and testing their functionality, thereby verifying the functionality of the
respective subsystems.

The product and project are configured to allow subsystems to integrate early. Through iterative
testing procedures the project as a whole incrementally develops towards a functional system, while
the majority of the management efforts are focused on troublesome boundaries between subsystems.
Activities such as system configuration, design, integration and verification which traditionally were

43
performed sequentially, are instead performed in parallel to improve both the lead time of the project
and the available time for each activity. By integrating and testing functionality early on in the project,
faults can be spotted more easily and can thus also be fixed earlier, reducing the impact of rework on
the project’s lead time. As more emphases is placed on the integration of the different parts of the
project, project members have to become more aware of the overall project mission and their work in
the context of the systems functionality.

Coordination and communication are vital for the successful integration of the different parts of the
project. Both formal – and informal meetings are considered crucial for the project to be successful,
without intense communication the project would not be able to deliver its intended results. Not only
should different teams interact with one another, the customer should also be a close project partner
to ensure mutual agreement on functionalities is achieved. Teams are multidisciplinary and actors are
responsible for both their input and output, as a result team members proactively manage their work.
The emphasis on integration requires actors to broaden their scope and increase their knowledge of
the system, its components and the interdependencies. The management team primarily assists the
project’s members with tools to visualize the project complexity, thereby empowering the employees
and reducing the perceived complexity and uncertainty.

To enable project members to understand their role in the overall project, tools such as the product
anatomy, the integration and verification (I&V) plan and formal decision making boards are utilized.
The product anatomy and the I&V plan are used to visualize and monitor system progress to both the
project management, and the project team. The product anatomy shows groups of functions and their
respective dependencies. The map provides insight into how different functions relate to one another
and can show how particular functionalities should be integrated. The I&V plan further elaborates
upon the integration of the different functionalities by describing how and when particular functions
should be integrated, and what the status of the project currently is. While decision making is primarily
made from the bottom up, discussion forums can be utilized to gather key actors and the speed up the
decision making processes on a system wide level.

The approach based on dynamic synchronization

The third project management approach found in Ericsson is based on dynamic synchronization. The
approach based on dynamic synchronization emphasizes speed and embraces flexibility and
complexity. The approach assumes that (1) actors perform best under complexity when they are able
to see the whole picture. (2) Responsibility should be distributed across the project, providing the
means to handle uncertainty in real-time to all actors. (3) Interdependencies should be encouraged
and build as they provide control and distribute responsibility for set targets. (4) Projects are managed
by providing as many actors as possible with the complete complexity of the project.

Work is structured by actively creating reciprocal dependencies between work groups. As a rule, every
sub-system has at least two teams working on its development, while every team is also responsible
for at least two sub-systems. The product is broken down into parallel work packages which over time
are integrated and verified to construct the final product. The project is organized based on how
functionality is best realized, and the product is mirrors this configuration. The project operates
relatively independently from top management (e.g. the rest of the organization), the teams
responsible for particular parts are also responsible for the decisions regarding those parts. The project
group has continuous contact with the customer as specific project members are solely tasked with
proactively managing the customer’s wants and needs and integrating those requirements into the
project, even if that causes considerable changes or rework in late phases of the project.

44
Communication is crucial for project success, coordination efforts are made as often and early as
possible, utilizing both formal and informal mechanisms. Co-location is highly advised, as decisions are
often made informally around a desk, in the hallway or during water cooler conversations. As sub-
groups are responsible for different parts of the project, it is important that all project members
participate in the setting of goals while also analyzing the project context. To highlight the importance
of the interactions between the project’s members, one sub-project manager said: “To manage our
complex projects we have to interact, interact and interact with each other. That's the only way to
build a common picture and understanding of the collective achievements to be made." (Adler, 1999,
p363). The project management team has one aim; to improve the coordination between the different
teams within the project. Project coordination is considered as a crucial condition for project success
and project members spend much time on coordination and communication. To construct common
mental models, tools such as the product anatomy and I&V plan utilized in the approach based on
integration where also utilized within this approach. Customer contact and the participation in goal
setting were both also noted as important methods to provide context to the project member’s tasks.

Besides the importance of coordination and communication, system integration is perceived as a third
vital factor in project success. Key actors are dedicated to system integration to ensure that barriers
are removed and new interdependencies are built into the project. Integration is a collective effort as
all project members are forced to deal with other teams. Project members are empowered to stay in
control of different and often difficult situations through their thorough understanding of the project.

5.2 Project complexity management approaches – strength and weaknesses

Adler (1999) spent considerable time comparing the differences between the three previously
discussed approaches. In particular, Adler highlighted both the strengths and weaknesses of all three
approaches through both the functional and dysfunctional attributes of each approach. Additionally,
Adler separated the attributes that are generally known with those that are generally unknown.

Within the organizations where the approach based on planning is utilized, most functional attributes
are taken into consideration by the project management, while most of the dysfunctional attributes
are not actively reflected upon. As a result the project’s management team may have a false sense of
confidence as the negative effects of the chosen approach are ignored.

There are numerous advantages to the use of a planning-based approach. A relatively simple
organization can be created to handle large and complex tasks. Since engineers operate relatively
independently of each other and rigorous support exists for new actors, introducing new engineers is
easy and switching and replacing single engineers does not impact the rest of the project. Well-
developed quality assurance measures can be used to control performance with objective and
comparable indicators to determine the progress and effectiveness of the project.

The known limitations of the planning-based approach relate to the rigidity of the organizational
system and the difficulties in planning for highly dynamic projects. However, project managers often
underestimate the slow pace of the project and the difficulties in forecasting an accurate time of
delivery. By postponing the integration to the later stages of the project the cost of integration may
actually be higher as faults are more likely to lead to rework and delays. Coordination is primarily
reactive and one sided (top down). Engineers may become alienated and demotivated as they have
little control over the project and the career path for project managers is limited. Due to the
bureaucracy in the organizational system it is often difficult or even impossible to change how work is
organized or executed. Actors typically have a limited perspective on the system, efforts to reduce
system complexity and uncertainty may instead actually even increase the perceived complexity and
uncertainty.

45
Most of the functional attributes of the approach based on integration-driven development are known
by the actors within the project. Most of the dysfunctional elements however are generally not
considered by the project members and project management.

The strength of the integration driven approach is its ability to deliver fast projects that meet and often
even exceed set targets. Early integration and testing allows for the timely identification of faults,
which can be solved early on in the development process. The project’s management focuses its
attention primarily on the troublesome interfaces within the project, thereby further minimizing the
negative effects of integration issues. Proactive coordination and active leadership improves the
communication within the project. The emphasis on expanding individual perspectives encourages
learning while the increased autonomy of the project members increases motivation. A strength which
is often not realized is the project’s ability to react and convergence on critical issues. While a major
problem that is often ignored by project management is the potential for burnout of key-actors as the
integration driven approach is often more stressful for the project team.

The approach based on dynamic synchronization allows the team to make fast adjustments to
emerging events. The management team is mainly tasked with empowering project members through
increased coordination capacities. As a result the management team has less control over the project
which could be a downside. The approach actively builds interdependencies into the project,
increasing the project systems complexity. Through this process a particular project may become much
more complex than it needs to be. The emphasis on parallel activities increases the pace of the project
but also potentially creates risks as a result of project changes later in the process.

There are many attributes of dynamic synchronization which are still often underestimated or not
known. Additional benefits include a high convergence and transparency within the project and a high
capacity to solve problems in real time. Employees enjoy a large amount of autonomy and as a result
are often more motivated. Since all project members have to be aware of the overall state of the
project, the approach is also an effective process to increase sense-making. The ability to deliver
projects in an increased pace is a considerable competitive advantage.

Like the previously described integration driven approach, the approach based on dynamic
synchronization asks much of its project members, the constant changes within the project and the
pace of the project considerably increase the likelihood of burn-out amongst project members.

Beyond the strengths and weaknesses, Adler points to several key differences between the three
approaches. The emergent approaches organize the project by building up the product rather than
breaking it down. Within the approach based on planning, actors primarily focus on their own tasks,
while in the integration-driven approach, actors are encouraged to look beyond their tasks and actively
consider their impact on other systems. The approach based on dynamic synchronization actively
attempts to create additional interdependencies between project teams rather than removing or
minimizing them. Actors are furthermore exposed to the whole project complexity and are encouraged
and supported to engage with the rest of the project. Top management within the planning based
approach focuses on control and manages the integration of the project, while managers in the
emergent approaches have less control and focus on coordinating the project instead. Decision making
comes from the bottom up, in particular within the approach based on dynamic synchronization as
project members are fully responsible for their respective tasks. Within the emerging approaches,
system integration is a priority from the start of the project and is performed early and continuously.
Validating functionality through testing the behavior of subsystems is crucial to monitor the project’s
progress, which is determined based on the actual functionality of the product.

46
Adler (1999) further notes that the approach based on planning is most appropriate to handle very
large projects in stable environments. By breaking down the product, an overview of the project is
maintained despite the scale of the project. By delaying integration however, the project becomes
more susceptible to changes in the project system, as faults are noticed much later, resulting in larger
amounts of rework ultimately delaying the project.

The Integration driven development approach is argued to be more appropriate to handle projects
where the lead-time and the time of delivery are sacred. The parallel development and testing of the
product allows for earlier integration and a more flexible response to project changes. The project also
required more autonomous and highly skilled project members, is more likely to induce stress and
burn-out and often requires more resources simultaneously.

Finally, the approach based on dynamic synchronization con be considered as an up-scaled start-up-
like approach. The project team constantly balances on the edge of chaos as changes in the project
occur frequently and project members often have to respond to emerging events and opportunities.
As a result, the dynamic synchronization approach is most suitable for projects exposed to large and
continuous changes in requirements.

5.3 Reframing popular project management methods.

Baardman, Bakker & Beijnhem (2007) provide a practical overview of the most recent project
management methods within the Netherlands. The authors reviewed the most popular methods which
resulted in the creation of a longlist of 38 items. To be included in the subsequent thorough review of
methodologies, the approaches were assessed based on their popularity of use, ease of access,
distinguishability, applicability across industries and the quality and quantity of supportive literature
available. This process resulted in a shortlist of 10 methods which were each described in detail and of
which the strengths and weaknesses were assessed.

Where the previous section described broad approaches to manage projects and the corresponding
project’s complexity, this section will frame the common project management methodologies within
their broader respective approaches, providing new insight into how these methodologies deal with
project complexity and uncertainty.

Many different project management methodologies have been developed in the past, often sharing
some similarities while also emphasizing some differences. Baardman, Bakker & Beijnhem (2007)
retrace the history of project management back to the 1960s with the development of the system
management approach by NASA. System Management was developed to guide the execution of the
‘Man to the Moon’ program which was active from 1962 to 1970. In parallel, similar ideas were
developed within the Nautilus project which developed the first nuclear-powered submarine. Both
projects developed highly innovative products within complex and uncertain settings. To prevent
budget overruns, strict schedules and budgets were kept.

Baardman, Bakker & Beijnhem (2007) distinguishes between two families of project management
methodologies which have since evolved in parallel. The ideas and techniques first proposed by
systems management have been applied extensively in both industrial and governmental settings,
resulting in the first family of methods. The second family of methodologies has been developed within
the ICT-sector. Within the industrial family of methodologies, approaches such as ‘Projectmatig
Werken’, ‘Systems Management’, ‘New Product Development’, ‘Projectmatig Creëren’, ‘A4 –
Projectmangement’ and ‘Processmanagement’ can be found. Within the ICT-family, approaches such
as ‘Linear Application Development’, the ‘Dynamic Systems Development Method' and ‘Projects IN
Controlled Environment’ are utilized.

47
The A4-methode is based on the separation of work activities and the subsequent recombination of
work through coordination. Tools such as the work breakdown structure, and the product breakdown
structure are used to break down the product into activities. Progress is measured in relation to the
project plan and an early requirements freeze is preferred. Many of the core characteristics of the A4-
method align with the previously discussed approach based on planning.

Liniear Application Development (LAD) was created to manage large, complex and uncertain
development processes. Projects are structured based on linear phases separated by milestones.
Decision making is primarily based on milestones and results are defined per phase of the project. The
approach is primarily intended for the development of administrative information systems for
organizations, providing a planning based approach for the ICT sector.

The Projects IN Controlled Environment (PRINCE2) methodology primarily emphasizes the importance
of the human aspects of project development. Projects can only be considered successful when all
involved actors are satisfied and collaboration between all actors is considered crucial for project
success. The project manages work based on the division of work packages and the planning process
is product-oriented. The project is constructed through a combination of a number of predefined
processes. Depending on the scope and complexity of the project, these processes can be repeated.
Changes are managed structurally through predefined processes. PRINCE2 fundamentally aligns with
the approach based on planning as structured processes are heavily utilized in the management of the
project and work is planned based on the product components.

ProjectMatig Werken (PMW) utilizes a phased structure to manage the project. Decision documents
are prepared for each phase transition to allow the project’s client to control the project’s
continuation. The process performs best in stable conditions and when the requirements are frozen
early on in the development. Integration or testing activities are not emphasized within the
methodology leaving room for the project manager to fill in the particular actions within each phase.
PMW thus also aligns with the approach based on planning.

Systems Management manages the project based on a fundamental project lifecycle, assuming all
projects fundamentally follow a similar pattern of phases. Specifications are defined early on in the
project and changes are minimized during the project’s execution. Work breakdown structures and
product breakdown structures are used to divide the product into sub-products which are used in turn
to create a project planning. The development of each phase is supported with formal documentation
and the transitions between phases are seen as crucial management milestones to monitor project
progress.

New Product Development similarly utilizes a fixed set of phases and milestones to manage the project.
Each phase consists of a number of cross functional parallel tasks. By encouraging the different
traditionally separate departments to collaborate within a single project, NPD was able to increase the
communication between departments. While integration between departments is encouraged, actual
integration and testing of products components is still performed later on in the second to last phase
of the project, just before the launch. The management based on project phases as advocated by NPD
is reminiscent of the approach based on planning while the cross functional collaboration within the
project is suggestive of an integration driven approach. NPD shows that the characteristics of the
different approaches as described by Adler (1999) are not necessarily fixed to one approach. Rather,
ideas of different approaches can be utilized to develop a project management method that is most
appropriate for a particular project context.

48
The Dynamic Systems Development Method (DSDM) emphasized continuous adaptation to changes
to any aspect of the project, except for the project assignment, delivery date and budget. The
methodology assumes that people (the customers) don’t know what to choose until they are able to
see it developed. Nothing is ever perfectly build the first time and eighty percent of the development
can occur in twenty percent of the time once the final concept is clear. Projects exist within a context
which changes continuously. DSDM is fundamentally non-linear as the functionality is built
incrementally and iteratively. Active involvement of users is essential and teams are empowered to
make decisions without direct management involvement. Products are delivered frequently and
testing is integrated within the lifecycle. Complexity is managed by separating the project in smaller
relatively independent parallel subprojects which deliver subsystems. Considering these
characteristics, DSDM appears to align most with the integration-driven approach, although the
integration of subsystems is not explicitly highlighted.

Process management can be considered a somewhat odd method in project management as process
management is focused on processes rather than projects. Process management considers the
intention as central, by controlling the environment the goals can be reached while the actual results
are subservient. Process management practices are typically utilized to shape the idea generation of
large infrastructure projects where the input and influences of many actors have to be considered. By
embracing the influences of all actors, process management is able to build support for vague ideas
which slowly take shape as the process unfolds. On first glance, process management is difficult to fit
within the project management approaches described by Adler (1999). Arguably however, process
management is in line with many of the ideas presented by the approach of dynamic synchronization.
Where dynamic synchronization attempts to create converge amongst the people within the project,
process management attempts to create converge amongst organizations and stakeholders. Ideas are
shaped incrementally from the bottom up much like a product is shaped within the dynamic
synchronization approach.

Baardman, Bakker & Beijnhem (2007) provided a practical overview of some of the most common
project management methods within the Netherlands. Systems management was noted as one of the
earliest available methodologies and many of the now popular methods stem from systems
management. While each of these methods is different in some way, many of the approaches are still
based on the same assumptions regarding the management of complexity and uncertainty. Adler
(1999) previously highlighted the dominance of the planning-based approach within both the literature
and practice. After framing the methodologies presented by Baardman, Bakker & Beijnhem (2007)
within the three broad approaches presented by Adler (1999) this claim certainly seems valid. Many
of the reviewed project management methodologies do not explicitly take into account the effect of
project complexity. In particular, many of the planning-based methods implicitly assume that
complexity can be managed by separating the project into independent elements.

By analyzing the project management methods in relation to the approaches described by Adler (1999)
it became more apparent how particular project management methods manage project complexity.
Notably, the New Product Development approach was able to bridge the gap from a purely planning-
based approach towards a more innovation-driven approach by forcing collaboration between
previously separated groups of actors. The Dynamic Systems Development Method was the only
example found to truly align with the integration driven approach while the process management
methodology could be argued to share fundamental assumptions with the approach based on dynamic
synchronization.

49
 5.4 Managing project complexity in practice
The previous paragraph considered how practitioners in general manage projects and how these
project management methods influence project complexity. By framing project management methods
within the three general approaches to manage complex projects, insight was generated into the effect
of particular methods on project complexity. Similarly, the projects within the case organization can
be analyzed both in terms of their respective project complexity through the previously developed
complexity assessment framework, and in terms of the project management approaches used to deal
with the project’s complexities.

The project complexity framework for research was used to estimate the project complexities of
eighteen projects within the case organization. The sample consisted of all the projects supported by
the Benelux branch of the organization. The project plan of each project was analyzed and the project
complexity framework for research was utilized to estimate the respective project’s complexity. In
parallel, the project plans were analyzed to determine which general project complexity management
approach was followed (e.g. planning-based, integration-driven or dynamic synchronization).

Figure 11 shows an overview of the complexity estimates of the project subsystems of all projects.
Table 2 furthermore shows the descriptive statistics of the sample. The least complex project scored a
value of 7.7 (project B) while the most complex project was estimated at 10.47 (project G). The least
complex project consisted of three project partners, in two countries with three different roles
(research, university and SME). The project aimed to develop an innovative product by adding
intelligent sensors to a previously simple hardware solution. Alternatively, the most complex project
consisted of 14 project partners, spread over four countries with various roles. The project aimed to
develop a series of deliverables. Including amongst others an overview of the state-of-the-art business
models, an innovation funnel and an open service platform were developed in the project.

Inter-Organizational Complexity
7
6
5
Ecosystem Complexity 4 Social Complexity
3
2
1
0

Socio-Political Complexity Complexity of Scope

Technological Complexity

Project A Project B Project C Project D Project E Project F

Project G Project H Project I Project J Project K Project L
Project M Project N Project O Project P Project Q Project R

Figure 11: Overview of project complexity estimates.

50
Table 2: Descriptive statistics of project complexity.

Minimum Maximum Mean Std. Deviation

IOC 3,50 6,23 5,0300 ,70532
SC 3,69 5,98 4,7588 ,66037
CS 2,76 5,84 4,0825 ,95237
PSC 2,77 5,99 4,0931 ,95499
SPC 2,77 5,26 3,7550 ,75774
EC 4,04 6,15 4,8831 ,61289
PC 7,70 10,47 8,8056 ,87085

To determine which approach was predominantly used in each project, the project plans were
analyzed. The information within some of the project plans was limited, as a result the approaches
used by projects B, C, G, H, I and N could not clearly be identified. One of the clearest identifying factors
to determine which approach was used was the moment of integration. Projects A, E, L, P and Q were
all identified as utilizing the planning-based approach as the projects planned for late integration and
testing of the deliverables. Projects D, F, J, K, M, O and R integrated work tasks much earlier in the
project, and thus used methods which resembled the integration-driven approach more closely.

To explore the relationship between the project’s complexity, and the chosen project management
method, a one-way ANOVA analysis was conducted. A one-way ANOVA analysis effectively tests
whether two groups of data are similar or different. In this case, the analysis tests whether the projects
which utilize an integration-driven approach are equally complex as projects which utilize a planning-
based approach. The projects are only compared on their overall level of project complexity. If the
projects would be compared on the complexity of the six project subsystems, six individual ANOVA’s
would be required, resulting in an increased likelihood of type I errors as a result of the multiple
comparisons problem2 (Field, 2009).

Table 3 shows the results of the one-way ANOVA test. No statistical difference between the groups
could be determined by a one-way ANOVA (F(1,10) = 0,338, p = 0.574). The analysis shows that no
statistical difference can be found between the projects which utilize an integration-driven approach
and those which utilize a planning-based approach. This effectively implies that project managers
utilize both approaches, regardless of the inherent project complexity of a particular project.
Table 3: ANOVA analysis of integration-driven approach vs. planning-based approach.

Sum of Squares df Mean Square F Sig.

PC Between Groups ,039 1 ,039 ,338 ,574
Within Groups 1,145 10 ,114
Total 1,183 11
Total 1,280 11

2
The more tests are performed on a set of data, the more likely it is that a null hypothesis is rejected
while it is true. The probability of making a type I error can be calculated according to: 𝛼̅ = 1 −
𝑘
(1 − 𝛼{𝑝𝑒𝑟 𝑐𝑜𝑚𝑝𝑎𝑟𝑖𝑠𝑜𝑛} ) . When utilizing a standard significance level of 0.05 and if 6 tests are
performed, an 𝛼̅ can be calculated by filling in the equation: 𝛼̅ = 1 − (1 − .05)6 = 0.265. When
conducting six tests, there would thus be a chance of 26.5% that in one of the tests a statistically
significant difference between the groups is found which does not exist.

51
Little information was available on the expected dynamics within the projects, as a result it was not
possible to consider whether the projects that used an integration driven approach did so because
they faced considerable dynamic changes within the project or not.

Based on the review of the project portfolio of the Benelux branch, it appears that project managers
within the case organization utilize both planning-based approaches and integration-driven
approaches regardless of the inherent project complexity. It is likely that project managers adopt
project management approaches with which both they and the organizations within the project are
experienced. No data was gathered on the project success rates, as a result no claims can be
substantiated that one approach is more effective than the other. Although anecdotal evidence
suggests that given the inherently often complex settings within the case organization, integration-
driven approaches appear to be more effective.

Project Arche-types
Turner et al. (2003, p7) defined a project as: “a temporary organization to which resources are assigned
to undertake a unique, novel and transient endeavor managing the inherent uncertainty and need for
integration in order to deliver beneficial objectives of change.” Projects are often characterized as
unique and/or novel as no two projects are exactly the same. As a result it is difficult to translate the
lessons learned from one project to another as a small difference within the project’s context may be
enough to achieve a different outcome.

While projects are unique, many projects do follow similar patterns based on the management
methodologies utilized. The planning-based approach previously discussed for example highlights that
projects follow a typical project lifecycle consisting of a goal setting phase followed by planning,
execution and conclusion phases. While the individual activities performed within projects will vary,
the overall project approaches are comparable. It is also interesting to explore whether new insights
can be generated by comparing projects in terms of project complexity.

To explore whether any consistent patterns could be found within the project portfolio of the case
organization, a dual clustering approach was used as advocated by Hair et al. (2009). First a hierarchical
clustering approach was used to explore the general structure of the data, than a second non-
hierarchical clustering algorithm was used to provide the final clusters.

Cluster analysis techniques can be used to generate insight and understanding into a dataset, or for
the purpose of utility, for example by reducing the dataset into a smaller set of prototype clusters that
can be used in a further analysis. For the purpose of this research, clustering is used to gain insight into
the similarities between the projects within the project portfolio of the case organization. Cluster
analysis techniques create clusters based on the similarities within groups and differences between
groups. It was hypothesized that while projects are unique, they may be similar enough that projects
can be grouped according to their complexity estimates. In particular, by considering the differences
and similarities in terms of the complexities of the project subsystems, it was expected that project
Arche-types could be constructed. A better understanding of the Arche-types within the case setting
could in turn help the case organization better manage projects.

One common critic of cluster analysis is that as long as there is some heterogeneity within the dataset,
a clustering algorithm will always be able to generate a set of clusters. Only with conceptual support
and through validation can clusters become meaningful. In other words, it is easy to find structural
variety within the data but it is also difficult to prove the validity of the patterns found. The cluster
analysis presented here is primarily explorative and aims to provide insight into the data rather than
to extrapolate the insights from the sample to a broader population.

52
The cluster analysis aims to explore the project profile of the BeNeLux branch of the case organization.
The branch has so far managed 18 distinct projects, drawing from the previously conducted analysis
of project complexity, all 18 projects were included in the cluster analysis. The exploratory cluster
analysis aims to study only the BeNeLux branch of the case organization. The research does not aim to
draw any conclusions that can be inferred to the rest of the organization, to projects within the energy
sector or to project management in general. Since all projects within the branch are analyzed, the data
sample represents the whole population.

A visual inspection was performed to determine the existence of outliers. All projects were more or
less similar to at least one or two other projects. Due to the limited size of the dataset it was not
possible to conclude whether these cases were indeed true outliers or actual clusters. As such the
decision was made to include all projects into the analysis.

Before performing the cluster analysis, the data must conform to the assumptions of the analysis.
Unlike many statistical analysis techniques, a clustering analysis does not require the researcher to test
for specific statistical qualities, rather the research must adhere to two basic issues regarding research
design. First of all, the chosen sample must be representative of the population. Since the research in
this case aims to only explore the projects within the BeNeLux branch of the case organization, the
sample incudes the whole population and thus this issue is resolved. Secondly, the clustering variables
must be analyzed in terms of multicollinearity. If the clustering variables suffer from multicollinearity,
the correlated variables will influence the clustering process more than the uncorrelated variables.

Table 4 shows the correlations between the potential cluster variables. A review of the correlations
indicates that the variables are all somewhat correlated to each other. However, no two variables were
perfectly correlated to one another. Field (2009) considers correlations above 0.8 or 0.9 to be
indicative of (multi)-collinearity. A correlation of 0.809 was found between IOC and SC, all other
correlations between IOC, SC, CS, PSC, SPC and BEC were below the threshold and ranged between
0.783 and 0.383. All six sub-dimensions of project complexity were also relatively highly correlated
with PC, which makes sense as PC is calculated from its dimensions.

IOC SC CS PSC SPC BEC PC

IOC Pearson Correlation 1 ,809** ,710** ,575* ,383 ,616** ,775**
Sig. (2-tailed) ,000 ,001 ,013 ,117 ,006 ,000
SC Pearson Correlation ,809** 1 ,771** ,667** ,401 ,650** ,829**
Sig. (2-tailed) ,000 ,000 ,002 ,099 ,003 ,000
CS Pearson Correlation ,710** ,771** 1 ,783** ,541* ,731** ,921**
Sig. (2-tailed) ,001 ,000 ,000 ,020 ,001 ,000
PSC Pearson Correlation ,575* ,667** ,783** 1 ,670** ,725** ,898**
Sig. (2-tailed) ,013 ,002 ,000 ,002 ,001 ,000
SPC Pearson Correlation ,383 ,401 ,541* ,670** 1 ,561* ,740**
Sig. (2-tailed) ,117 ,099 ,020 ,002 ,016 ,000
BEC Pearson Correlation ,616** ,650** ,731** ,725** ,561* 1 ,820**
Sig. (2-tailed) ,006 ,003 ,001 ,001 ,016 ,000
PC Pearson Correlation ,775** ,829** ,921** ,898** ,740** ,820** 1
Sig. (2-tailed) ,000 ,000 ,000 ,000 ,000 ,000
**. Correlation is significant at the 0.01 level (2-tailed). *. Correlation is significant at the 0.05 level (2-tailed).
Table 4: Multicollinearity cluster variables.
While considerable correlations exist between IOC, SC, CS, PSC, SPC and BEC, the majority of the
correlations between the variables are below the threshold as proposed by Field (2009). The review of
multi-collinearity indicates that the variables are different enough such that multi-collinearity should
not be a fundamental barrier to the cluster analysis. The inclusion of all six sub-dimensions of project
complexity furthermore allows for a better conceptual comparison of the different projects.

53
A Complete linkage hierarchical agglomerative clustering algorithm was used to explore the data.
Hierarchical clustering methods are generally more appropriate for smaller data sets and are typically
used to create taxonomy’s of the data. The purpose of the cluster analysis is explorative as the clusters
are used to gain insight into the differences between the projects. A hierarchical agglomerative cluster
algorithm starts by considering each data point as a cluster, at each consecutive step the two closest
clusters are merged into a new cluster. As a result the clustering algorithm provides insight into the
nested nature of the clusters. Several methods exist to calculate the shortest distance(s) between
clusters. Each method has different strengths and weaknesses appropriate for different data
distributions. The Complete linkage method calculates the distance between two clusters based on the
two elements of the clusters that are the furthest away. In respect to the dataset, no particular
clustering algorithm was advocated over another from the perspective of the literature. The complete
linkage method is generally recognized as less susceptible to noise and outliers, generates compact
clusters and is most appropriate for a wide variety of clustering applications (Field, 2009). While several
different methods can be chosen to consider which distance to use when comparing clusters, several
different metrics also exist to calculate the respective distance between two points. In this case the
squared Euclidean distance was utilized as it is the most commonly suggested metric to use (Field,
2009).

Agglomerative hierarchical clustering algorithms start by dividing the whole sample into individual
clusters and consequently merge the clusters which are closest together, one cluster at a time. This
process ultimately results in one large cluster containing all data points. A dendrogram can be used to
visualize the process of cluster amalgamation, see figure 12 for the dendrogram of the hierarchical
cluster analysis.

Figure 12: Dendrogram Complete linkage hierarchical agglomerative clustering algorithm

54
Figure 12 provides insight into the nested nature of the clusters which can be found within the sample.
The clusters are positioned on the vertical axis while the horizontal axis represents the distances
between the clusters. As mentioned before, a hierarchical cluster algorithm ultimately results in one
large cluster including all data points. It is up to the researcher to interpret the dendrogram to
determine how many clusters are appropriate within the context of the research setting. To help
determine an appropriate number of clusters, agglomeration coefficients can be used. The larger the
agglomeration coefficients, the more dissimilar the clusters are. Figure 13 shows a plot of the
coefficients. The appropriate amount of clusters can be determined by determining the point where
the slope of the curve levels off (this point is also known as the ‘elbow’). From stage 15 to 14 the slope
of the curve is almost level, while the slope between stage 15 and 16 is high. Stage 15 is thus the
appropriate cutoff point. Since the analysis included 18 data points, this means that the appropriate
number of clusters is three. This aligns with the observations from the dendrogram which shows that
projects C, I, B, H and G form one relatively similar cluster, while projects D, J, A, O, P and F form a
second cluster. Finally, projects L, Q, E, M, K, N and R form the third cluster. Creating less than three
clusters means that relatively dissimilar clusters are merged, while creating more clusters results in
multiple clusters which are relatively similar.

Figure 13: Agglomeration Schedule Coefficients.

The sample could thus be divided into three clusters according to the complete linkage hierarchical
agglomerative clustering algorithm. Hair et al. (2009) however suggests that a hierarchical method is
used to determine the appropriate number of clusters, while a non-hierarchical clustering algorithm is
used to iteratively determine the actual clusters. Hierarchical methods have the downside that once
two clusters are merged, they cannot be unmerged. An iterative clustering method can change cluster
memberships and as a result sometimes perform better.

55
The k-means clustering algorithm is the most common non-hierarchical clustering method. The
sample, clustering variables and number of desired clusters are used as input. The algorithm initially
randomly assigns one observation to each cluster to act as a seed, the rest of the observations are then
assigned to the nearest respective cluster. The rest of the observations are assigned to the clusters
based on their proximity to the seeds. Cluster memberships are successively reassigned to minimize
within-cluster variation based on the distance from each observation to the cluster center. If the
within-cluster variation is improved by assigning an observation to another cluster the observation is
reallocated.

Running a k-means clustering algorithm on the same dataset resulted in the same three clusters. All
observations were attributed the same cluster memberships, regardless of the clustering technique
utilized, providing additional support for the inherent structure within the data. The k-means algorithm
furthermore provided the cluster centroids for each cluster. These centroids effectively can be seen as
prototype projects, or Arche-types. Figure 14 shows the three project cluster centroids and the
complexity estimates of the observations adhering to each cluster. On first glance, the projects within
cluster A have to lowest estimates of project complexity for almost all factors, although the centroid
of cluster B scores slightly lower on socio-political complexity. The projects within cluster B are
generally slightly more complex while the projects in cluster C score considerably higher on all factors.
During the analysis of multicollinearity it was noted that all factors were somewhat interrelated. Upon
inspection of the clusters, it appears that all sub-dimensions of project complexity scale to a similar
degree.

Cluster Centroids Cluster A

IOC IOC
6 E
6
4 EC 4 SC K
EC SC
2 Cluster B 2 L
0 Cluster C 0 M
Cluster A N
SPC CS SPC CS Q
R
PSC PSC

Cluster B Cluster C
IOC IOC
6 6
A
4 4 B
EC SC D EC SC
2 2 C
F
0 0 G
J
H
SPC CS O SPC CS
I
P

PSC PSC
Figure 14: Cluster centroids and memberships.

56
After establishing the clusters, the cluster stability and cluster validity must be established. To test the
cluster stability the k-means clustering algorithm was calculated multiple times to test whether
different seed observations would result in different clusters, this was however not the case.
Additionally, the results of the hierarchical agglomerative algorithm were compared to the k-means
algorithm and yielded similar clusters.

To assess the cluster validity, a set of additional variables can be used that theoretically are related to
the clustering variables, but which were not included in the cluster solution. Since the majority of the
variables measured within the research project were utilized to compute the project complexity
estimates, only one variable was used for this process: the number of organizations participating within
the project. Based on the descriptive statistics alone, it appears that a difference exist, as cluster A has
a mean of 3.86 organizations per project, Cluster B has a mean of 5.67 organizations per project and
cluster C has a mean of 11.80 organizations participating per project. A one-way ANOVA was utilized
to explore the differences in number of participating organizations between the clusters. Table 5 shows
the results of the one-way ANOVA test (F(2,15) = 16,267 , p = 0.000) which indicates that a statistical
difference does indeed exist between the groups.
Table 5: ANOVA - Nr. Participants & Clusters.

Sum of Squares df Mean Square F Sig.

Between Groups 193,010 2 96,505 16,267 ,000

Within Groups 88,990 15 5,933
Total 282,000 17

Since three clusters were generated by the clustering algorithm, the statistical difference found by the
one-way ANOVA needs to be further explored through a set of post hoc tests, as shown in table 6.
These post-hoc tests indicate that no statistical difference can be found between clusters A and B in
terms of number of project participants, but a statistically different number of project participants can
be found between both clusters A and C, and B and C.
Table 6: Post Hoc Tests - Nr. Participants & Clusters.

Mean Difference
(I) Cluster Number of Case (J) Cluster Number of Case (I-J) Std. Error Sig.

Cluster A Cluster B -1,80952 1,35511 ,202

Cluster C -7,94286* 1,42621 ,000

Cluster B Cluster C -6,13333* 1,47490 ,001

Cluster A 1,80952 1,35511 ,202
Cluster C Cluster B 6,13333* 1,47490 ,001

Cluster A 7,94286* 1,42621 ,000

For the validation of the clusters these results support the notion that the clusters depict groups which
have some predictive validity. However, as only a single variable was used for this analysis, the support
for this claim is limited. Ideally, several variables would be tested through a MANOVA analysis. Due to
the nature of this research, this was simply not possible within the given time frame.

57
The final step in the cluster analysis is to profile the clusters on a third set of descriptive variables to
explore the practical significance and theoretical basis of the clusters. Formally, this process would be
performed by analyzing a set of categorical variables through a chi-square test. Due to the low number
of observations within the sample though, such an analysis would run into several problems as a chi-
square test is based on assumptions regarding minimum sample sizes and minimum expected cell
counts.

As a compromise, the final cluster profiling step is performed through a simplified review of a set core
project characteristics. As highlighted earlier, the projects within cluster A had on average 3.86
participating organizations. The projects primarily aimed to develop technological innovations with an
emphasis on the integration of smart control functions.

The projects within cluster B similarly developed (smart) technological innovations. The overall scope
of the projects was typically broader and as a result the projects had on average 5.67 participating
project organizations. Since the scope and organizational system is larger, the projects experience
more inter-organizational, social and scope-related complexities, while the product service complexity,
socio-political complexity and the complexity of the business environment are relatively similar.

Finally, the projects within cluster C emphasized integration across businesses, focusing on upcoming
topics such as smart grids and smart city’s. The projects were either large technological/platform
development projects or knowledge development programs. The projects typically included both more
internal project partners (average of 11.9) and more external project partners (public stakeholders and
business partners).

When the research was initiated, it was hypothesized that despite the unique nature of projects,
Arche-types could be extracted from the existing project portfolio to help frame new projects and help
determine appropriate management practices. The preliminary cluster analysis presented in this
chapter indicates that projects can be described in terms of project complexity, and can be compared
based on the dimensions of project complexity. While not unexpected, the cluster analysis highlighted
the correlations between the dimensions of project complexity. While the correlations were below the
thresholds for multicollinearity, it became apparent that the different project systems are highly
linked. When the research started it was theorized that different Arche-types would experience high
complexity on some dimensions, and low complexity on others. In practice however, it appears that as
projects increase in scope, the overall project system increases also, resulting in amplified complexities
in all dimensions. The three Arche-types uncovered in this analysis effectively show three levels of
project complexity, were cluster A contains relatively simpler projects, and clusters B and C become
increasingly more complex. When the case organization will face a new project selection round, the
new potential projects can be compared in terms of complexity with the project Arche-types presented
in this section.

5.5 Understanding complexity management

To actively manage project complexity a systematic process is required. Maylor et al. (2013) first noted
that the first response should be the active selection of projects, and that the project staffing and
project methods should be considered next. Implicitly, these three suggestions advocate a complexity
management process. Figure 15 proposes a systematic solution to the management of project
complexity, which can be supported by the tools developed by this thesis.

A projects complexity is generally inherently designed into the project as a result of the projects
composition, scope, deliverables and environment. The management of project complexity should
start before officially initiating the project, and should continue through the development of the
project.

58
The first step is to estimate the project’s complexity. It is suggested that as many people as possible
from different levels of the project are involved in this step. By involving multiple project members
from different levels of the organization, the inherent perceptual challenges can be overcome. The
estimation process is furthermore a moment of reflection were project members are encouraged to
actively think about their role in the project, potentially improving sense-making and learning. The
pragmatic project complexity assessment developed in chapter four can be used during this process.

The second step is to enter in an open discussion of the antecedents and consequences of project
complexity. Different project members will experience the consequences of project complexity
differently. This is also a moment to discuss the potential different results found during the previous
estimation process and come to a consensus of the project’s complexity. The theoretical model
developed in chapter three can be used to explain the consequences of project complexity and guide
the discussion.

Next the project staff and project approach should be assessed. It is crucial that the staff is experienced
with projects of a similar complexity, and that the project management approach fits within the project
context. The importance of the project staff was noted by Maylor et al. (2013) but was considered out
of the research scope for this research; Remington (2011) and ICCPM (2012) however provide
additional information on topics of leadership and competency standards. Additionally, the Table 7
(next page) summarizes the core principles, strengths, weaknesses and contexts of the three
approaches described by Adler (1999) and discussed in the previous sections.

Depending on the fit between the project complexity, project staff and project approach, a decision
can be made to continue the project as proposed or not. If the project is declined in its current state,
the project team can choose to either adjust the current project plan or reject the project in its entirety.
If the project is accepted in its current state, the project can be initiated. It is expected that the project
will evolve over time, as a result the projects complexity will also change. It is therefore important that
the projects complexity is monitored throughout the project’s lifecycle.

Figure 15: Complexity Management

59
Table 7: A structural comparison of the three approaches.

Approach: Core principles: Strengths: Weaknesses: Context:

- Separate uncertainty from complexity. - Simple organization. - Rigidity of the organizational - Small-scale and
- Manage uncertainty through planning. - Approach is generally well known in system. large projects.
- Manage complexity by breaking down the project into independent practice and well supported by - Slow pace of development. - Stable
parts. literature. - High cost of integration. environments.
Planning-based

- Integrate late in the process and only when subsystems are stable. - Well-developed progress control - Higher chance of rework and
- Minimize deviations from the plan. tools. delays. Example(s):
approach

- Manage top-down through milestones and formal control metrics. - Easy to introduce/switch project - Reactive coordination
- A4, LAD, PRINCE2,
members. - Risk of demotivating the project
PMW.
team.
- Difficult to react to change.
- Integrate subsystems early and continuously; verify subsystems - Deliver fast projects that meet and - More stressful work Context:
through testing to measure project progress. often even exceed targets. environment and potential for - Projects where
- Manage complexity by Identifying challenging moments of integration - Early identification and resolution of burnout of key-actors. lead-time and time
and allocating the most skilled resources to aid integration. faults. - Requires highly skilled project
Integration-driven

of delivery are
- Manage uncertainty by configuring the project such that uncertainty is - Minimalize integration issues. members. sacred.
identified early and relevant resources can be allocated. - Improved communication. - Requires more resources
- Utilize both formal and informal communication, encourage - Encourages learning. simultaneously.
Example(s):
approach

interactions between teams and involve the customer. - React and converge on critical
- Project members are encouraged to proactive manage their tasks and emerging issues. - DSDM
contextualize their work within the broader scope of the project.

- Actors perform best under complexity when they are able to - Allows for fast adjustments to - Less management control. Context:
understand the whole project system. emerging events. - May result in an unnecessarily
Dynamic Synchronization-driven approach

- Projects exposed to
- Responsibility should be distributed across the project, providing the - Empowers and motivates project complex project structure. large and
means to handle uncertainty in real-time to all actors. members - Parallel execution of tasks may continuous changes
- Interdependencies should be encouraged and build as they provide - Fast project pace, potentially resulting induce risks later in the project in requirements.
control and distribute responsibility for set targets. in an increased competitive as a result of project changes.
- Projects are managed by providing as many actors as possible with the advantage. - More stressful work
complete complexity of the project. - High convergence and transparency environment and potential for
- Work is structured by actively creating reciprocal dependencies within the project. burnout of key-actors.
between work groups. Each sub-system is developed by multiple - High capacity to solve problems in real
teams, and each team works on multiple subsystems. time. Example(s):
- Decision making is done bottom up by the relevant project teams. The - Improves sense-making. - Process
contact with the customer is proactively managed and changes are management
welcome, regardless of the project phase.
- The main responsibility of the management team is to improve
coordination and to help project members understand their place in
the whole project. Coordination is both formal and informal.
- Coordination, communication and system integration are consider
vital for project success.

60
 6. Conclusions, limitations and recommendations
The field of project management has continuously searched for new and improved methods to
successfully deliver challenging projects. Risk management may be considered as one of the earliest
formal project management techniques developed to manage the unpredictability of projects. Risk
management aims to capture all the potential events that may negatively influence a project’s
outcome or execution and establishes either reactive or proactive strategies to manage these risks.
For each event, the likeliness of occurrence and impact on the project are considered to determine
appropriate reactions. Uncertainty management was introduced as an extension of risk management.
By considering different types of uncertainty’s such as variation, chaos, foreseen - and unforeseen
uncertainty, authors proposed alternative management styles depending on the uncertainty’s faced
by the projects. As projects have become larger and more intricate, methods such as risk – and
uncertainty management may no longer be enough. Complexity management considers how the
different parts of a project interact and how these interactions limit the project’s team to accurately
predict the project behavior.

By considering the relationships between risk, uncertainty and complexity, project managers may gain
a more comprehensive understanding of the particular challenges of a given project. While the
knowledge of risk – and uncertainty management are well developed and assimilated within the
project management profession, the knowledge of project complexity is less advanced and
understood. Project complexity has been studied in the context of project management for years.
However, many of the frameworks developed over the last two decades lack a clear theoretical
foundation, which limits the explanative power of the existing models. Additionally, the majority of
the frameworks developed utilize too many abstract definitions for practical use.

6.1 Conclusions
This thesis aimed to explore a dual research objective. Project complexity as a theoretical construct
has been further explored through a formal model, supplemented by an assessment framework and a
mathematical model. For practice a pragmatic framework was developed and the knowledge of the
management of project complexity was reviewed. Together these models and methods were used to
study the complexity and the project management methodologies within the case setting. Through
this process, the main – and sub-research questions of the thesis were explored.

What is project complexity?

Project complexity at its core encompasses two challenges. A complex project is a project which as a
result of the project’s size, variety and interdependencies is more likely to show non-linear and/or
emergent behavior, making the project as a whole unpredictable. Additionally, the scope of a project
prevents actors from forming complete mental models while the variability in the project results in
many different perspectives on the project. As a result, actors are no longer able to form accurate and
reliable mental models to help understand, foresee and manage the project system’s behavior. As
project members attempt to apply incomplete mental models on an already inherently unpredictable
project system, it becomes increasing difficult to accurately predict the causes – and effects of project
(management) decisions.

Project complexity is defined as: “the accumulated effect of the interactions between the many varied
interrelated parts of a project, which causes unpredictable behavior in the project and inhibits project
member to form accurate and reliable mental models to understand, foresee and manage the project
system’s behavior, even when given reasonably complete information about the project system.”

61
 What are the antecedents of project complexity?
The majority of literature on project complexity utilizes systems theory to analyze projects. By
analyzing the project as a system, the concepts of systems theory can be adopted to explain the
project’s behavior. Particularly intricate systems are best studied through the behavior of their
subsystems. For the purposes of this thesis, the project system has been separated into four
subsystems. The Inter-organizational system and the social system capture the communication
between organizations, departments, work teams and project members respectively. The system of
scope and the product service system in turn describe the relationships between the project’s goals,
deliverables, requirements, work processes, components and modules. Finally, the project’s business
environment and the socio-political system describe the behavior of outside influences such as market
forces, laws and regulations which impact the project system.

According to systems theory, the complexity of a system is dependent on the number of elements in
the system, the number of relationships between the elements in the system and the organization and
behavior of the relationships. As the size or the number of elements of a subsystem increases, the
amount of potential relations between its elements increases exponentially. As more elements are
included in a project, any variety between sets of elements is also increased exponentially. System size
effects system variety, and system interdependence. In turn, system variety and system
interdependence result in system complexity.

Different individuals may perceive the project differently, and as a result may have different
interpretations of the project’s complexity. If project members are less familiar with the project, it
becomes harder to correctly estimate the project system complexity. The ‘perceived’ project
complexity is a result of the real project complexity which is observed through the past professional -
and personal experiences of the reviewer.

As projects are executed over time, the project’s sub-systems may change drastically. Project partners
may be added or removed, the product service offering may refocus on another market, the
specifications may be adjusted, the project team may change, new policies may be implemented and
business partners may switch to join competitors. Dynamic changes within a project can be seen as
changes in either the sub-system size, variety or interdependence. For a dynamic analysis of system
complexity, the sub-system size, variety and interdependence should be estimated at t0 and some
future tn.

What are the consequences of project complexity?

Project complexity can induce both type I and type II ambiguity. The more complex a project is, the
more likely it is that the project actors will experience type II ambiguity. Additionally, any inherent
uncertainty in any sub-system of the project propagates through the interactions between the
elements of the project system, resulting in additional uncertainties within the project. The networked
dependencies within a project may furthermore introduce nonlinear or emergent behavior.
Uncertainty, emergent behavior and ambiguity in turn manifest in the form of risks and opportunities
which ultimately influence the project’s performance

While complexity inherently causes ambiguity, the complexity induced ambiguity may be amplified
when one does not understand the full complexity of the project. Thus the difference between the real
– and perceived project complexity moderates the effect of the real project complexity on complexity
induced ambiguity.

62
 Can project complexity be objectively measured?
Project complexity stems from ‘real world’ elements, but is also influenced by the individual’s
education, work experiences and social background. Different individuals may perceive the project
differently, and as a result may have different interpretations of the project’s complexity. Descriptive
or ‘real’ complexity thus exists, but any attempt to measure this real complexity is influenced by the
perspective of the observer. The ‘real’ project complexity is a product of the project size, project variety
and project interdependencies, while the ‘perceived’ project complexity is a result of the real project
complexity which is observed through the past professional - and personal experiences of the reviewer.

How can project complexity be managed?

To actively manage project complexity a systematic process is required. A project complexity
management process was proposed which utilizes the different tools developed within the research.
In short, Project complexity can be managed by either removing the sources of complexity or by
reducing their impact. However, the first response should be the active selection of complex projects.
A second response to manage the inherent project complexity is to consider the project staffing.
Project complexity stems from the collective behavior of the project system. It is therefore useful to
consider the effects of different project management approaches on the project system as a whole.
The initial phases of a project are typically dedicated to the exploration of the project scope and the
development of an appropriate project structure. Effectively, the project complexity is inherently
designed into the project as a result of the project’s definition. Due to the sensitivity of the project
system to its initial conditions, the most effective method to manipulate the project complexity is to
consciously design the project such that the initial project complexity is in line with the desired project
complexity.

How can project complexity be assessed (for research/practice)?

The complexity of the project system can be approximated based on the complexity of the inter-
organizational system, the social system, the system of scope, the product service system, the socio-
political system and the business environment. Chapter three proposed a theoretical – and
mathematical model to calculate a project complexity estimate based on estimates of each
subsystem’s size, variety, interdependence and dynamic changes. The size, variety, interdependence
and dynamic changes of each subsystem must in turn be estimated through a set of observable
elements of the project’s subsystems. Chapter four provides two separate frameworks, one designed
for research purposes, and one designed for practical use.

While it would enable the exchange of knowledge between practice and literature to have a single
standard to measure project complexity, the different usage cases of researchers and practitioners
made for a compelling argument to develop two analysis frameworks. The researchers can now
conduct broad and in depth analyses of project complexity to generate insight into the many different
factors that add to complexity, and to consider which factors add to complexity the most. While
practitioners can utilize a simplified project complexity assessment framework which captures the
most important factors of project complexity, requires less understanding of abstract or theoretical
definitions and is generally more easy to use. Through a better understanding of project complexity,
practitioners will be better able to manage the challenges induced by complexity.

Are there different strategies to influence inherent and self-induced project complexity?
Within systems theory, the importance of the initial state of a system is often emphasized. Depending
on the initial conditions a system may behave drastically different, as small changes proliferate through
the system. During a project’s lifecycle, there is typically one document which determines the majority
of the project’s structure. The ‘project plan’ provides a comprehensive overview of the project,
specifying the overall aim, budget, scope and arrangement of the project. Work packages, task

63
schedules, budgets, requirements and specifications are described in detail and together form a basis
of the project’s organization. Within the context of project management, the initial conditions of the
project system are effectively determined by the project plan.

When managing project complexity, it is thus important to realize that the project complexity is to a
large degree inherently designed into the project as a result of the project definition. Due to the
sensitivity of the project system to its initial conditions, the most effective method to manipulate the
project complexity is to consciously design the project such that the initial project complexity is in line
with the desired project complexity. Alternatively, as the project team realizes that a project is
becoming too complex over the course of the project’s development, they may decide to change the
project complexity by redefining the project system.

Project complexity can be managed by either removing the sources of complexity or by reducing their
impact. However, the first response should be the active selection of complex projects. By estimating
a project’s complexity before taking on a particular project, the fit between the project and the
organization can be considered. When a project includes particular complexities which the
organization has not faced before, the organization should deliberately decide to either proactively
change the project’s composition, kill the project or continue as planned.

A second response to manage the inherent project complexity is to consider the project staffing. It is
particularly important that the skills of the project manager align with the complexities faced by the
project, as the project manager is tasked with maintaining an overview of the project. When a project
is particularly complex on one dimension of project complexity, and the project manager lacks the
appropriate skills and experiences to manage the complexity of that dimension, it becomes more likely
that the negative effects of that dimension are underestimated and consequently poorly managed.

A third solution is to consider the overall project management approach. Project complexity stems
from the collective behavior of the project system. To influence a project’s complexity, a system wide
change is most effective. It is therefore more useful to consider the effects of different project
management approaches on the project system than the effects of individual methods on the project’s
subsystems.

What are the effects of different project management methods on project complexity?
Drawing from the extensive research on the management of complex development projects by Adler
(1999), three general approaches to manage complex projects have been discussed. The dominant
approach discussed in both literature and practice is the approach based on planning which attempts
to deductively optimize the project before its execution. An optimal way of executing the project tasks
is proposed before the project starts based on the information that is known of the project system. It
is assumed that the overall project can best be managed by separating the aspects of uncertainty from
the aspects of complexity. Uncertainty is best managed by rigorous planning, while complexity is best
managed by breaking the project down into small and easily controllable parts. Specialized resources
are best able to execute tasks when the work is as independent from other influences as possible, the
resulting subsystems should only be integrated once they are considered stable.

The second approach proposed by Adler (1999) was developed in response to the increasing need to
develop projects with shorter lead times. The approach based on integration-driven development has
fundamentally different assumptions regarding the management of project complexity. Complexity is
best managed by identifying the interfaces between tasks which are the most troublesome, and
allocating the most skilled resources to these boundaries. Uncertainty is best managed by configuring
the product and project such that uncertainties are identified early and relevant resources are
allocated to monitor them. Control over the project is achieved by continuously integrating the

64
subsystems of the product and testing their functionality, thereby verifying the functionality of the
respective subsystems.

The third project management approach described by Adler (1999) is based on dynamic
synchronization. The approach emphasizes speed and embraces flexibility and complexity. One of the
core assumptions is that actors perform best under complexity when they are able to see the whole
picture. Responsibility should be distributed across the project, providing the means to handle
uncertainty in real-time to all actors. Interdependencies should be encouraged and build as they
provide control and distribute responsibility for set targets. Projects are managed by providing as many
actors as possible with the complete complexity of the project.

The emergent approaches organize the project by building up the product rather than breaking it
down. Within the approach based on planning, actors primarily focus on their own tasks, while in the
integration-driven approach, actors are encouraged to look beyond their tasks and actively consider
their impact on other systems. The approach based on dynamic synchronization actively attempts to
create additional interdependencies between project teams rather than removing or minimizing them.
Actors are furthermore exposed to the whole project complexity and are encouraged and supported
to engage with the rest of the project. Top management within the planning based approach focuses
on control and manages the integration of the project, while managers in the emergent approaches
have less control and focus on coordinating the project instead. Decision making comes from the
bottom up, in particular within the approach based on dynamic synchronization as project members
are fully responsible for their respective tasks. Within the emerging approaches, system integration is
a priority from the start of the project and is performed early and continuously. Validating functionality
through testing the behavior of subsystems is crucial to monitor the project’s progress, which is
determined based on the actual functionality of the product.

Baardman, Bakker & Beijnhem (2007) provided a practical overview of some of the most common
project management methods within the Netherlands. Many of the reviewed project management
methodologies do not explicitly take into account the effects of project complexity. In particular, the
majority of the planning-based methods implicitly assume that complexity can be managed by
separating the project into independent elements although the validity of this assumption has been
questioned by Adler (1999). Notably, the New Product Development approach was able to bridge the
gap from a purely planning-based approach towards a more innovation-driven approach by forcing
collaboration between previously separated groups of actors. The Dynamic Systems Development
Method was the only example found to truly align with the integration driven approach while the
process management methodology could be argued to share fundamental assumptions with the
approach based on dynamic synchronization.

Are there different project Arche-types in terms of complexity within the case-setting?
Three Arche-types were found within the BeNeLux branch of the case organization. The projects within
cluster A had on average 3.86 participating organizations and primarily aimed to develop technological
innovations with an emphasis on the integration of smart control functions. The projects within cluster
B similarly developed (smart) technological innovations. The overall scope of the projects however was
broader and as a result the projects had on average 5.67 participating project organizations. Since the
scope and organizational system was larger, the projects experienced more inter-organizational, social
and scope-related complexities, while the product service complexity, socio-political complexity and
the complexity of the business environment were relatively similar. The projects within cluster C
emphasized integration across businesses, focusing on upcoming topics such as smart grids and smart
city’s. The projects were either large technological/platform development projects or knowledge

65
development programs. The projects typically included both more internal project partners (average
of 11.9) and more external project partners (public stakeholders and business partners).

The preliminary cluster analysis presented in this research indicates that projects can be described in
terms of project complexity, and can be compared based on the dimensions of project complexity.
While not unexpected, the cluster analysis highlighted the correlations between the dimensions of
project complexity. While the correlations were below the thresholds for multicollinearity, it became
apparent that the different project systems are highly linked. When the research started it was
theorized that different Arche-types would experience high complexity on some dimensions, and low
complexity on others. In the context of the case setting however, it appears that as projects increase
in scope, the overall project system increases also, resulting in amplified complexities in all dimensions.
The three Arche-types uncovered in this analysis effectively show three levels of project complexity,
were cluster A contains relatively simpler projects, and clusters B and C become increasingly more
complex.

Is there an ideal fit between project complexity and project management?

No empirical evidence within this study was uncovered to support the claim that one particular
approach is more suited or less suited to manage a particular type of project than another. However,
within the literature, several authors have argued that a planning based approach is more appropriate
to handle very large projects in stable environments. By breaking down the product, an overview of
the project is maintained despite the scale of the project. By delaying integration however, the project
becomes more susceptible to changes in the project system, as faults are noticed much later, resulting
in larger amounts of rework ultimately delaying the project.

The Integration driven development approach is argued to be more appropriate to handle projects
where the lead-time and the time of delivery are sacred. The parallel development and testing of the
product allows for earlier integration and a more flexible response to project changes. The project also
required more autonomous and highly skilled project members, is more likely to induce stress and
burn-out and often requires more resources simultaneously.

Finally, the approach based on dynamic synchronization con be considered as an up-scaled start-up-
like approach. The project team constantly balances on the edge of chaos as changes in the project
occur frequently and project members often have to respond to emerging events and opportunities.
As a result, the dynamic synchronization approach is most suitable for projects exposed to large and
continuous changes in requirements.

6.2 Research contributions

The presented research contributes both to the existing project management literature and to the
literature on design science research. While preparing the thesis, the design mode of research as
advocated by Simon (1969), Van Aken (2007) and Romme (2003) was recognized as a more appropriate
methodological foundation of the study than a purely scientific mode of research. Previous science-
based design approaches as advocated by authors such as Van Burg, Romme, Gilsing and Reymen
(2008) have been used primarily to develop design principles or design propositions. This research
however shows that these concepts can also be utilized to construct a much broader set of artefacts
such as theoretical models, measurement frameworks and literature reviews.

The study was initiated with a thorough literature study which focused both on the research subject
(project complexity) and on the research process (research methods). Design science research was
adopted as the principal research methodology, but additional research methods were borrowed from
other methodologies where appropriate. Through this process, the research was able to expand both
the theoretical and practical knowledge bases of project complexity. By supplementing the design-

66
science approach with additional methods to investigate particular research questions, the researcher
was able to explore a broad range of research topics. The continuous communication with practice
ensured an emphasis on the practicality of the research while the flexibility of the methodology
allowed the researcher to adjust the research to emerging interests from practice.

The research has furthermore expanded the knowledge base on project complexity through several
contributions. A new definition of project complexity was proposed explaining the ambiguity induced
by complexity through the limitations of mental models by project participants. Additionally, a formal
model of project complexity was proposed further elaborating upon the relations between the many
concepts related to complexity. In particular the model explored the relationships between size,
variety and interdependence within the context of six sub-dimensions of the project. The relationships
between complexity, uncertainty, ambiguity and familiarity have been debated within the literature
continuously. By framing these issues through the limitations of individual mental models a strong
argument can be made that uncertainty and ambiguity are induced by complexity.

The role of dynamic complexity is still debated within the literature. By describing the dynamics of the
project subsystems through both a likelihood of change and an expected size of change a new
framework was proposed which allows for a comprehensive analysis of the expected project
complexity as a result of dynamic changes to the project’s subsystems. Multiple frameworks have been
developed to estimate project complexity in the past. A new measurement framework was developed
by framing the previous frameworks into the model of project complexity. Through this process new
elements of project complexity were exposed while existing elements were validated. The new
framework has a more well-defined theoretical foundation and provides a more structural review of
project complexity.

Beyond the theoretical developments of the research, a review was made of the existing knowledge
on the management of project complexity. By summarizing the work of Adler (1999) the general
insights of the project management literature were presented in a simplified framework. Through this
simplification, practitioners will be able to make more informed decisions without requiring an
extensive background into project complexity literature. The active selection of complex projects was
proposed as one of the core methods to manage project complexity. While some project complexity
measurement frameworks exist within practice, the theoretical support for these models is limited. A
practical and simplified project complexity framework was developed based on the literature as a
means to assist in the analysis of project complexity.

Independently, each of the above mentioned contributions has expanded the knowledge of project
complexity in either the domain of literature or practice. Taken together though, the deliverables
present a set of tools that allow the practitioners of the case organization to analyze project complexity
to a degree that has not been seen before. Utilizing the frameworks and models presented in figures
16 through 18, practitioners will be able to estimate and discuss the project complexity, frame their
experiences within a conceptual model to understand their challenges and consiously adopt one
approach over another (note that the theoretical model in figure 17 has been slightly adapted to reflect
the project complexity framework presented in figure 16).

67
 Scale Score
Project definition 1 2 3
PD1 Stability of the overall project definition Stable project definition; Project definition might still Project definition requires
(success criteria, scope, requirements, will not change in change in minor areas in further defining in
methodology(ies), limitations and flexibility) foreseeable future. foreseeable future. foreseeable future.

PD2 Familiarity with the project definition Familiar product with New product with familiar New product with new
(Newness of technology and product) familiar technology, technology, innovation technology, radical
incremental innovation. through combination of innovation.
technologies.

PD3 Familiarity with the project definition (Market Familiar market with Unfamiliar market with Unfamiliar market with
and business model) familiar business model. familiar business model. unfamiliar business model.

PD4 Is the scope clear and aligned with the end-
user needs?
The end-user needs are
clear, the project scope is
highly aligned with the end-
user needs and is clear to all
project participants.
The end-user needs are not
entirely understood yet, the
scope is still broad to allow
for multiple interpretations
of the end-user needs.
No clear end-user needs can
be known as the project will
develop an entirely new
type of product or serivce.

Scale Score
Project organization 1 2 3
PO1 Stability of project organization (project Stable project organization Project organization might Project organization
manager, project members, dedication of will not change in still change in minor areas requires further defining in
resources, contracts, organization of work) foreseeable future. in foreseeable future. foreseeable future.
PO2 Familiarity with the project organization All partners have worked Two key partners have All partners are new to each
(Collaboration complexity) together before in a project worked together before in other, they have never
(not necessarily all in the project(s) worked together before in a
same project) project
PO3 Number of companies / projects sharing their 1 - 3 Organizations 4 - 6 Organizations 7 + Organizations
resources
PO4 Overall expected financial impact on project No financial impact on For all partners it has a Varying distribution of
stakeholders project stakeholders similar proportional financial impact per partner
financial impact (not over time but per
partner)
PO5 Strategic importance of the project to the No strategic importance to For all partners similar Different strategic
involved organizations involved partners strategic importance importance per partner (not
over time but per partner)

PO6 Stakeholder cohesion regarding the Only similar stakeholder Limited differences of Different stakeholder
characteristics of the type of business/activity profiles stakeholders profiles profiles
(size, functional role, public/private)

PO7 Number of interfaces between partners and 3 Interfaces 4-7 Interfaces More than 7 Interfaces
departments within partners organization
(like legal, marketing, R&D)

PO8 Cultural variety of the team members (ref. All in same quadrant 1 in other quadrant In more than 2 different
Trompenaars chart, see last slide) quadrants
PO9 The work will be carried out by independent The work in carried out by a The work is carried out by The work is carried out by
teams single project team. several project teams several project teams
independently of each working closely together,
other, with semiannual with weekly or monthly
coordination meetings coordination meetings

PO10The work will be carried out in a single 1 - 2 Nationalities, 8 3 - 4 Nationalities, 6 5 or more Nationalities, 4
country/timezone/location overlapping office hours overlapping office hours or less overlapping office
and all partners located and all partners located hours and all partners
within 200 km of each within 200 to 1000 km of located within 1000 km or
other each other more of each other
Scale Score
Project Environment 1 2 3
PE1 Stability of the project environment (legal and Stable project environment Project environment might Project environment will
social) will not change in still change in minor areas experience considerable
foreseeable future. in foreseeable future. changes in the foreseeable
future.
PE2 Familiarity with the project environment Familiar laws and familiar Familiar laws and unfamiliar Unfamiliar laws and
(legal and social) public stakeholders public stakeholders unfamiliar public
stakeholders
PE3 Magnitude of Legal and social implications Project execution and Project execution and Project execution and
from performing the project implications within existing implications challenge the implications outside the
legislation and public existing legislation and existing legislation and
opinion or expectation public opinion or public opinion or
expectation expectation

Figure 16: Project complexity assessment framework.

68
Figure 17: Model of Complexity

69
Approach: Core principles: Strengths: Weaknesses: Context:
- Separate uncertainty from complexity. - Simple organization. - Rigidity of the organizational - Small-scale and
- Manage uncertainty through planning. - Approach is generally well known in system. large projects.
- Manage complexity by breaking down the project into independent practice and well supported by - Slow pace of development. - Stable
parts. literature. - High cost of integration. environments.
Planning-based

- Integrate late in the process and only when subsystems are stable. - Well-developed progress control - Higher chance of rework and
- Minimize deviations from the plan. tools. delays. Example(s):
approach

- Manage top-down through milestones and formal control metrics. - Easy to introduce/switch project - Reactive coordination
- A4, LAD, PRINCE2,
members. - Risk of demotivating the project
PMW.
team.
- Difficult to react to change.
- Integrate subsystems early and continuously; verify subsystems - Deliver fast projects that meet and - More stressful work Context:
through testing to measure project progress. often even exceed targets. environment and potential for - Projects where
- Manage complexity by Identifying challenging moments of integration - Early identification and resolution of burnout of key-actors. lead-time and time
and allocating the most skilled resources to aid integration. faults. - Requires highly skilled project
Integration-driven

of delivery are
- Manage uncertainty by configuring the project such that uncertainty is - Minimalize integration issues. members. sacred.
identified early and relevant resources can be allocated. - Improved communication. - Requires more resources
- Utilize both formal and informal communication, encourage - Encourages learning. simultaneously.
Example(s):
approach

interactions between teams and involve the customer. - React and converge on critical
- Project members are encouraged to proactive manage their tasks and emerging issues. - DSDM
contextualize their work within the broader scope of the project.

- Actors perform best under complexity when they are able to - Allows for fast adjustments to - Less management control. Context:
understand the whole project system. emerging events. - May result in an unnecessarily
Dynamic Synchronization-driven approach

- Projects exposed to
- Responsibility should be distributed across the project, providing the - Empowers and motivates project complex project structure. large and
means to handle uncertainty in real-time to all actors. members - Parallel execution of tasks may continuous changes
- Interdependencies should be encouraged and build as they provide - Fast project pace, potentially resulting induce risks later in the project in requirements.
control and distribute responsibility for set targets. in an increased competitive as a result of project changes.
- Projects are managed by providing as many actors as possible with the advantage. - More stressful work
complete complexity of the project. - High convergence and transparency environment and potential for
- Work is structured by actively creating reciprocal dependencies within the project. burnout of key-actors.
between work groups. Each sub-system is developed by multiple - High capacity to solve problems in real
teams, and each team works on multiple subsystems. time. Example(s):
- Decision making is done bottom up by the relevant project teams. The - Improves sense-making. - Process
contact with the customer is proactively managed and changes are management
welcome, regardless of the project phase.
- The main responsibility of the management team is to improve
coordination and to help project members understand their place in
the whole project. Coordination is both formal and informal.
- Coordination, communication and system integration are consider
vital for project success.
Figure 18: Comparison of project complexity management approaches

70
 6.3 Limitations
The theoretical framework and measurement frameworks developed in the thesis drew from an
extensive literature base. While the analysis framework for research includes a broad set of factors
contributing to project complexity, it would be an overstatement to claim that the framework is
complete. The thesis previously argued that the properties that cause project complexity also limit the
researcher’s ability to analyze a project’s complexity, and as all mental models are inherently
incomplete. It is thus effectively impossible to claim that any framework of project complexity would
ever include all contributing factors. It is however not the aim of the research to provide a complete
analysis framework, rather the study intends to provide a more comprehensive framework compared
to previous studies.

The theoretical model and the analysis framework for research were both developed with a broad
range of projects in mind but were primarily tested against development projects within the energy
industry. As a result some factors might have been missed which would be appropriate in other types
of projects or within different industries. The practical analysis framework was developed to provide
a simpler and faster analysis of project complexity. The number of elements within the framework was
severely reduced, and as a result the use of the framework is inherently limited.

The review of project management practices was primarily based on the available knowledge within
the literature. It is not uncommon for scholarly literature to lag behind the most recent innovations
from practice, as such the provided overview is limited in its scope and it is possible that approaches
to manage project complexity exist which were not included in the research. Although the research
was able to frame the project management methods described by Baardman, Bakker & Beijnhem
(2007) within the three approaches described by Adler (1999), indicating that the approaches found
by Adler (1999) remain relevant.

The analysis of the project portfolio of the BeNeLux branch suffered from several major limitations.
The projects were analyzed by a single researcher, based only on the project plans of each project.
Since only a single source of data of each project was analyzed it was difficult to make any claims
regarding the validity, reliability and reproducibility of the research; it was not possible to utilize data
triangulation techniques within the time frame of the research to a sufficient degree to improve the
credibility and validity of the study. By analyzing the project plans of the organization, data could be
gathered relatively independently from the case setting, thereby limiting the impact of the study on
the day-to-day operations. A downside of the chosen data collection method however was that it was
in difficult to estimate the appropriate responses to some of the factors included in the measurement
framework, limiting the quality of the collected data. While conducting the analysis it was noted that
the sample size of the population was rather small for more elaborate data analysis techniques. As a
result it was not possible to profile the cluster analysis through formal techniques. Additionally, the
research primarily collected data on the factors that contribute to project complexity, as a result it was
difficult to validate the cluster analysis through additional related variables.

The analysis of the project portfolio of the case setting suffered from multiple limitations; however,
rather than drawing conclusions to a larger population, the issues of validity, reliability, quality of data
and sample size were negated by considering the analysis of the project portfolio as fundamentally
exploratory. The analysis conducted by the research are primarily intended to generate additional
insights into the particular projects typically faced by the case setting. It is not the aim of the research
to confirm or refute any causal relationships or effects through statistical evidence.

71
 6.4 Directions for future research
Dynamic complexity was integrated into the model of project complexity by describing the likelihood
of change and the size of the change in the size, variety and interdependence of each project
subsystem. The complexity of each subsystem can have 23 = 8 potential values as a result of the
uncertainty within the subsystems; the overall dynamic project complexity estimate can have 23∗6 =
262.144 different combinations. In chapter three a function was given to calculate the expected value
of the dynamic project complexity. It would however be interesting to explore the dynamic aspects of
project complexity in more detail.

Depending on the nature of the project, different sub-systems will likely experience different levels of
dynamic complexity. Probability mass functions can be used to visualize the probabilities that different
scenarios will occur. Figure 15 shows two potential probability functions that could occur in a particular
project. If the subsystem is relatively stable the likelihood that one of the antecedents will change is
low, or maybe zero. The PMF on the left of figure 15 shows a high probability of an inter-organizational
complexity of 3.93 at some future t, and two very low probabilities that the inter-organizational
complexity will be either 4.07 or 4.37. Alternatively, the PMF on the right of figure 19 shows a four
estimates of the social complexity which each can occur with a probability of 25%. The two PMF’s
provide insight into the expected complexity of the two subsystems as a result of the expected changes
in their antecedents.

PMF - Inter-organizational Complexity PMF - Social Complexity

1 0,3
0,8
Probability

Probability

0,2
0,6
0,4
0,1
0,2
0 0
3,83 4,03 4,23 4,43 4,33 4,83
Inter-organizational Complexity Social Complexity

Figure 19: Dynamic Complexity Analysis – Probability Mass Functions.

Since all dimensions of project complexity interact, the expected project complexity at some future t
may vary considerably depending on the dynamics of the six sub-dimensions. The expected value of
the project complexity only provides a limited view on the project’s dynamics. Depending on the
interactions between the dimensions of the project system, the estimate of the project’s system may
vary considerably. Figure 20 shows two histograms of the estimated future project complexity based
on two sets of fictitious data. For future research it would be interesting to explore how dynamic
changes in the project system influence the project complexity. By considering the probability mass
functions of the sub-dimensions, insight can be generated into the expected changes within the
project’s subsystems, while the histogram of the estimated project complexity shows the effects of the
interactions between the sub-dimensions.

72
 Histogram - Example case 1
1000 120,00%
800 100,00%
Frequency

80,00%
600
60,00%
400 Frequency
40,00%
200 20,00% Cumulative %
0 0,00%
8,8 8,9 9,0 9,1 9,2 9,3 9,3 9,4 9,5 9,6 9,7
Bin

Histogram - Example case 2

700 120,00%
600 100,00%
500
Frequency

80,00%
400
60,00%
300 Frequency
200 40,00%
Cumulative %
100 20,00%
0 0,00%
8,3 8,4 8,5 8,7 8,8 8,9 9,0 9,2 9,3 9,4 9,5
Bin

Figure 20: Dynamic Complexity Analysis – Histograms.

The theoretical model presented in this research provides insight into the antecedents and
consequences of project complexity. The antecedents of project complexity were used to construct a
mathematical model to calculate an estimate of project complexity. While difficult, it would be
interesting to explore how both the theoretical model and the analysis framework hold up to statistical
analysis techniques to test the relations between the constructs. In a later phase, the consequences of
project complexity could also be included in such an analysis.

The exploratory cluster analysis presented in chapter five provided some interesting preliminary
insights into different Arche-types within the case organization. For future research it would be
interesting to explore whether structural Arche-types can be found in larger samples of projects based
on their respective project complexity. Such an analysis would aid in the quest for the holy grail of
research on the management of project complexity; to establish structural approaches which are
proven to work in particular project contexts. It would be equally interesting, although less useful, to
prove that it is not possible to claim that a particular set of project management approaches performs
better or worse than another set of project management approaches in a particular project context.

73
References

Adler, Niclas. "Managing complex product development: Three approaches." (1999).

Aitken, Alicia, and Lynn Crawford. "A study of project categorisation based on project management
complexity." IRNOP VIII Conference (8th Annual International Research Network on Organizing by Projects).
2007.

Atkinson, Roger. "Project management: cost, time and quality, two best guesses and a phenomenon, its time to
accept other success criteria."International journal of project management 17.6 (1999): 337-342.

Baardman, Edwin, Gerard Bakker, and Jan Beijnhem. Wegwijzer voor methoden bij projectmanagement. Van
Haren, 2007.

Baccarini, David. "The concept of project complexity—a review."International Journal of Project

Management 14.4 (1996): 201-204.

Baskerville, Richard L., and A. Trevor Wood-Harper. "A critical perspective on action research as a method for
information systems research." Enacting Research Methods in Information Systems: Volume 2. Springer
International Publishing, 2016. 169-190.

Bhaskar, Roy. "The Possibility of Naturalism: A Philosophical Critique of the Contemporary Human Sciences
(Critical Realism--Interventions)." (1998).

Boaz, Annette, and Deborah Ashby. Fit for purpose?: assessing research quality for evidence based policy and
practice. London: ESRC UK Centre for Evidence Based Policy and Practice, 2003.

Bosch-Rekveldt, Marian, et al. "Grasping project complexity in large engineering projects: The TOE (Technical,
Organizational and Environmental) framework." International Journal of Project Management29.6 (2011): 728-
739.

Carlsson, Sven A. "Design science research in information systems: A critical realist approach." Design Research
in Information Systems. Springer US, 2010. 209-233.

Cicmil, Svetlana, and David Marshall. "Insights into collaboration at the project level: complexity, social
interaction and procurement mechanisms."Building Research & Information 33.6 (2005): 523-535.

Cole, Robert, et al. "Being proactive: where action research meets design research." ICIS 2005
Proceedings (2005): 27.

Corbett, L. M., J. Brocklesby, and C. Campbell-Hunt. "Thinking and Acting: complexity management for a
sustainable business." 2nd International Conference of the Manufacturing Complexity Network. 2002.

Darnall, Russell, and John M. Preston. "Project management from Simple to Complex." (2010).

Denyer, David, David Tranfield, and Joan Ernst Van Aken. "Developing design propositions through research
synthesis." Organization studies 29.3 (2008): 393-413.

Edmonds, Bruce. Syntactic measures of complexity. Diss. University of Manchester, 1999.

Field, Andy. Discovering statistics using SPSS. Sage publications, 2009.

Flood, Robert L., and Ewart Carson. Dealing with complexity: an introduction to the theory and application of
systems science. New York: Plenum Press. 1993

Gacenga, Francis, et al. "A proposal and evaluation of a design method in design science research." Electronic
Journal of Business Research Methods10.2 (2012): 89-100.

Gentner, Dedre, and Albert L. Stevens. Mental models. Psychology Press, 2014.

Geraldi, Joana G. "What complexity assessments can tell us about projects: dialogue between conception and
perception." Technology Analysis and Strategic Management 21.5 (2009): 665-678.

Geraldi, Joana G., and Gérald Adlbrecht. "On faith, fact and interaction in projects." (2007): 32-43.

74
Geraldi, Joana, Harvey Maylor, and Terry Williams. "Now, let's make it really complex (complicated) A systematic
review of the complexities of projects."International Journal of Operations & Production Management 31.9
(2011): 966-990.

Gidado, K. I. "Project complexity: The focal point of construction production planning." Construction
Management & Economics 14.3 (1996): 213-225.

Gladwell, Malcolm. The tipping point: How little things can make a big difference. Little, Brown, 2006.

Glaser, Barney, and Anselm Strauss. "The discovery ofgrounded theory."London: Weidenfeld and
Nicholson (1967).

Gransberg, Douglas D., et al. "Project complexity mapping in five dimensions for complex transportation
projects." Journal of Management in Engineering 29.4 (2012): 316-326.

Gregory, Robert Wayne. "Design science research and the grounded theory method: characteristics, differences,
and complementary uses." Theory-Guided Modeling and Empiricism in Information Systems Research. Physica-
Verlag HD, 2011. 111-127.

Hackman, J. Richard. "Learning more by crossing levels: Evidence from airplanes, hospitals, and
orchestras." Journal of organizational behavior 24.8 (2003): 905-922.

Hagan, George, Denise Bower, and Nigel Smith. "Managing complex projects in multi-project environments." C.
a. L. Egbu, ECW (Chair), Symposium conducted at the meeting of the 27th Annual ARCOM Conference, Bristol,
UK. 2011.

Hair, Joseph F. "Multivariate data analysis." (2009).

He, Qinghua, et al. "Measuring the complexity of mega construction projects in China—A fuzzy analytic network
process analysis." International Journal of Project Management 33.3 (2015): 549-563.

Hellström, Tomas. "Critical infrastructure and systemic vulnerability: Towards a planning framework." Safety
science 45.3 (2007): 415-430.

Hussein, Bassam A., Giedre Pigagaite, and Pedro P. Silva. "Identifying and dealing with complexties in new
product and process development projects."Procedia-Social and Behavioral Sciences 119 (2014): 702-710.

Hevner, Alan R. "A three cycle view of design science research." Scandinavian journal of information systems 19.2
(2007): 4.

Iivari, Juhani. "Distinguishing and contrasting two strategies for design science research." European Journal of
Information Systems 24.1 (2015): 107-115.

Johns, Gary. "Constraints on the adoption of psychology‐based personnel practices: lessons from organizational
innovation." Personnel Psychology46.3 (1993): 569-592.

Kim, Jongbae, and David Wilemon. "Sources and assessment of complexity in NPD projects." R&D
Management 33.1 (2003): 15-30.

le Moigne, J. L. "La théorie générale du système." Théorie de la Modélisation. Presses universitaires de

France (1990).

Lewin, Kurt. "Action research and minority problems." Journal of social issues 2.4 (1946): 34-46.

Lewin, Kurt. "Field theory in social science: selected theoretical papers (Edited by Dorwin Cartwright.)." (1951).

Lu, Yunbo, et al. "Measurement model of project complexity for large-scale projects from task and organization
perspective." International Journal of Project Management 33.3 (2015): 610-622.

Ludovic-Alexandre, Vidal, Marle Franck, and Bocquet Jean-Claude. "Modelling Project Complexity." Guidelines
for a Decision Support Method Adapted to NPD Processes (2007).

Martin, Joanne, et al. "Managing ambiguity and change." Managing ambiguity and change (1988).

75
Maylor, Harvey R., Neil W. Turner, and Ruth Murray-Webster. "How hard can it be?: Actively managing
complexity in technology projects." Research-Technology Management 56.4 (2013): 45-51.

Maylor, Harvey, Richard Vidgen, and Stephen Carver. "Managerial complexity in project‐based operations: A
grounded model and its implications for practice." Project Management Journal 39.S1 (2008): S15-S26.

Mesny, Anne, and Chantale Mailhot. "Control and traceability of research impact on practice: reframing the
‘relevance gap' debate in management."M@ n@ gement 15.2 (2012): 181-207.

Nguyen, An T., et al. "Quantifying the complexity of transportation projects using the fuzzy analytic hierarchy
process." International Journal of Project Management (2015).

Olsen, Richard Paul. Can project management be defined?. 1971.

Papas, Nikolaos, Robert M. O'Keefe, and Philip Seltsikas. "The action research vs design science debate:
reflections from an intervention in eGovernment." European Journal of Information Systems 21.2 (2012): 147-
159.

Peffers, Ken, et al. "A design science research methodology for information systems research." Journal of
management information systems 24.3 (2007): 45-77.

Penalva, JM. La modélisation par les systèmes en situations complexes. Paris, Université de Paris XI-Paris Sud.
Diss. Ph. D, 1997.

Pich, Michael T., Christoph H. Loch, and Arnoud De Meyer. "On uncertainty, ambiguity, and complexity in project
management." Management science 48.8 (2002): 1008-1023.

Purao, Sandeep, et al. "The sciences of design: observations on an emerging field." Harvard Business School
Finance Working Paper 09-056 (2008).

Qureshi, Sheheryar Mohsin, and ChangWook Kang. "Analysing the organizational factors of project complexity
using structural equation modelling." International Journal of Project Management 33.1 (2015): 165-176.

Remington, Kaye, and Julien Pollack. Tools for complex projects. Gower Publishing, Ltd., 2007.

Romme, A. Georges L. "Making a difference: Organization as design."Organization science 14.5 (2003): 558-573.

Rousseau, Denise M., Joshua Manning, and David Denyer. "Evidence in management and organizational science:
Assembling the field's full weight of scientific knowledge through syntheses. The Academy of Management
Annals, 2 (1): 475-515, 2008." Marketing Letters 21 (2008): 6581.

Rynes, Sara L., and D. Brian McNatt. "Bringing the organization into organizational research: An examination of
academic research inside organizations." Journal of Business and Psychology 16.1 (2001): 3-19.

Schlindwein, Sandro Luis, and Ray Ison. "Human knowing and perceived complexity: implications for systems
practice." Emergence: Complexity and Organization 6.3 (2004): 27-32.

Schrader, Stephan, William M. Riggs, and Robert P. Smith. "Choice over uncertainty and ambiguity in technical
problem solving." Journal of Engineering and Technology Management 10.1 (1993): 73-99.

Simon, Herbert A. The sciences of the artificial. Vol. 136. MIT press, 1996.

Sinha, S., A. I. Thomson, and B. Kumar. "A complexity index for the design process." WDK Publications (2001):
157-163.

Strauss, Anselm Leonard, and Juliet M. Corbin. Basics of qualitative research. Vol. 15. Newbury Park, CA: Sage,
1990.

Susman, Gerald I., and Roger D. Evered. "An assessment of the scientific merits of action
research." Administrative science quarterly (1978): 582-603.

Turner, J. Rodney, and Ralf Müller. "On the nature of the project as a temporary organization." International
Journal of Project Management 21.1 (2003): 1-8.

76
Van Aken, Joan Ernst, and Georges Romme. "Reinventing the future: adding design science to the repertoire of
organization and management studies."Organization Management Journal 6.1 (2009): 5-12.

Van Aken, Joan Ernst. "Design science and organization development interventions aligning business and
humanistic values." The Journal of Applied Behavioral Science 43.1 (2007): 67-88.

Van Burg, Elco, et al. "Creating University Spin‐Offs: A Science‐Based Design Perspective*." Journal of Product
Innovation Management 25.2 (2008): 114-128.

Van de Ven, Andrew H. Engaged scholarship: a guide for organizational and social research: a guide for
organizational and social research. Oxford University Press, 2007.

Venable, J. R., and Richard Baskerville. "Eating our own cooking: toward a more rigorous design science of
research methods." Electronic Journal of Business Research Methods 10.2 (2012): 141-153.

Vidal, Ludovic-Alexandre, and Franck Marle. "Understanding project complexity: implications on project
management." Kybernetes 37.8 (2008): 1094-1110.

Vidal, Ludovic-Alexandre, Franck Marle, and Jean-Claude Bocquet. "Building up a project complexity framework
using an international Delphi study."International Journal of Technology Management 62.2/3/4 (2013): 251-283.

Vidal, Ludovic-Alexandre, Franck Marle, and Jean-Claude Bocquet. "Measuring project complexity using the
Analytic Hierarchy Process."International Journal of Project Management 29.6 (2011): 718-727.

Vidal, Ludovic-Alexandre, Franck Marle, and Jean-Claude Bocquet. "Using a Delphi process and the Analytic
Hierarchy Process (AHP) to evaluate the complexity of projects." Expert systems with applications 38.5 (2011):
5388-5405.

Wenger, Etienne, Richard Arnold McDermott, and William Snyder. Cultivating communities of practice: A guide
to managing knowledge. Harvard Business Press, 2002.

Wozniak, Timothy M. "Significance vs. capability:" Fit for use" project controls." AACE International
Transactions (1993): A-2.

77
Appendix A – Project subsystems
A Review of the literature was conducted to generate an initial list of potential aspects of project
complexity to be included in the model. 18 distinct dimensions of project complexity were found during
this literature search. To limit the number of dimensions, the results from this list were grouped into
clusters of conceptually similar topics, see table 8 for an overview of all dimensions.

Six dimensions proposed by ten authors were clustered together under the label of inter-
organizational complexity. The majority of authors within the literature describe organizational
complexity as one of the core dimensions of project complexity (Baccarini, 1996; Vidal et al., 2007;
Bosch-Rekveldt et al., 2011; He et al., 2015; Kim et al., 2003; Maylor et al., 2008; Nguyen et al., 2015
and Lu et al., 2015). Some authors furthermore described additional dimensions to capture aspects of
the project which were relevant in particular industries’ or to provide additional alternative
perspectives. Nguyen et al. (2015) for example highlighted infrastructural complexity as a dimension
of project complexity in infrastructure projects. Gransverg et al. (2013) furthermore described cost –
financing and schedule complexity individually and Maylor et al. (2008) considered delivery
complexity; although these topics were filed under organizational complexity by authors such as Vidal
et al. 2011 and Bosch-Rekveldt et al. 2011. The influence of social and cultural aspects on the project
have been emphasized as both a part of organizational complexity by , and as independent dimensions
of project complexity by He et al. (2015) and Maylor et al. (2008). By defining both an organizational –
and social subsystem, the social aspects of collaboration can be separated from the scheduling,
planning and organizational aspects of the project.

Baccarini (1996), Vidal et al. (2007), Bosch-Rekveldt et al. (2011), He et al. (2015), Kim et al. (2003),
Nguyen et al. (2015), Lu et al. (2015), Gransverg et al. (2013), Remington et al. (2007) and Gidado
(1996) each recognize technological or task complexity as an important aspect of project complexity.
Moreover, Kim et al. (2003) described development complexity based on the integration of
components required and the integration of research and development decisions. While the labels
varied somewhat, each author described similar interactions. Aspects of the project scope were filed
under technological complexity by authors such as Vidal et al. 2011 and Bosch-Rekveldt et al. (2011).
Alternatively, He et al. (2015), Maylor et al. (2008) and Nguyen et al. (2015) each consider the
complexity of the project scope as a separate project dimension. The technological or product service
system complexity relates to the complexity of the final design, while the complexity of the project
scope relates to the definition of the project overall.

Aspects of the project context, market, marketing and stakeholders have been described both
independently from each other by Kim et al. (2003), Maylor et al. (2008), Bosch-Rekveldt et al. (2011),
He et al. (2015), Nguyen et al. (2015), Gransverg et al. (2013) and Crawford (2007), and as part of
organizational complexity by Vidal et al. (2011). Socio-political aspects have furthermore been
described as part of organizational complexity by Vidal et al. (2011), as part of the complexity of the
environment by Bosch-Rekveldt et al. (2011); and as an individual aspect of project complexity by
Nguyen et al. (2015), Maylor et al. (2013), Geraldi (2011) and Crawford (2007). The socio-political
complexity was separated from the complexity of the business environment to distinguish between
business relations based on an exchange of value, and political/public relations indirectly influencing
the project.

Based on the dimensions of project complexity included within these clusters, six sub-systems of the
project system are now proposed. These sub-systems have been defined, such that they are based on
the most common conceptualizations of project complexity, together provide a broad view of the
project through the combined effect of six clearly distinct perspectives of analysis, and can be defined
in accordance to systems thinking.

78
 Cluster Dimension of project complexity Number of articles Articles

(Inter-) Organizational 8 Baccarini (1996), Vidal et al. (2007), Bosch-Rekveldt et al. (2011), He et al. (2015), Kim et al.
organizational (2003), Maylor et al. (2008), Nguyen et al. (2015) and Lu et al. (2015)
Complexity
Intra-organizational 1 Kim et al. (2003)

Infrastructural 1 Nguyen et al. (2015)

Cost 2 Gransverg et al. (2013) and Crawford (2007)

Financing 1 Gransverg et al. (2013)

Schedule 1 Gransverg et al. (2013)

Delivery 1 Maylor et al. (2008)

Product-Service Technological/ task 10 Baccarini (1996), Vidal et al. (2007), Bosch-Rekveldt et al. (2011), He et al. (2015), Kim et al.
Complexity (2003), Nguyen et al. (2015), Lu et al. (2015), Gransverg et al. (2013), Remington et al. (2007)
and Gidado (1996)

Development 1 Kim et al. (2003)

Environmental Environmental/context 5 Bosch-Rekveldt et al. (2011), He et al. (2015), Nguyen et al. (2015), Gransverg et al. (2013) and
Complexity Crawford (2007)

Market 1 Kim et al. (2003)

Marketing 1 Kim et al. (2003)
Stakeholders 2 Maylor et al. (2008) and Crawford (2007)

Complexity of Goal/Mission/Directional/Scope 3 He et al. (2015), Maylor et al. (2008) and Nguyen et al. (2015)
Scope

Social Cultural 1 He et al. (2015)

Complexity
Team 1 Maylor et al. (2008)
Informational 1 He et al. (2015)

Socio-political Socio-political 4 Nguyen et al. (2015), Maylor et al. (2013), Geraldi (2011) and Crawford (2007)
Complexity

Others 4 Kim et al. (2003) and Crawford (2007)

Table 8: Dimensions of project complexity in literature.

79
Appendix B – Antecedents of project complexity
Within the literature, numerous frameworks have been developed which describe sets of elements
which are hypothesized to contribute to project complexity. By reframing the elements described in
these frameworks according to the proposed theoretical model, a new framework can be developed
to measure the size, variety, interdependence and dynamic changes of each of the project’s
subsystems. The elements proposed by Bosch-Rekveldt et al. (2011), Qureshi et al. (2015), Vidal et al.
(2011a), Nguyen et al. (2013), Maylor et al. (2013), He et al. (2015), Kim et al. (2003) and Aitken and
Crawford (2007) were reviewed to construct the new project complexity framework.

The components and relationships of the sub-systems were first described when constructing the
theoretical model. Based on these descriptions, the elements found in the literature were coded to
classify to which subsystem each elements adheres to. Next, the elements were coded according to
the antecedent to which they aligned. Finally, the coded elements were grouped based on their
similarity with other elements.

Some elements were directly copied from the literature if the literature provided a clear and
unambiguous description. For example, the element IOCS1: “Number of companies/projects sharing
their resources” was based on a group of elements describing the number of companies sharing their
resources. The element “number of companies sharing their resources” by Qureshi et al. (2015, p169)
was grouped together with the elements “Number of companies / projects sharing their resources” by
Vidal et al. (2011, p772) and “Number of organizational units and departments” by He et al. (2015,
p557). This group of elements was combined into a single element for the final framework to capture
the number of companies sharing their resources, which together with several others was used to
measure the size of the inter-organizational system. The element as proposed by Vidal et al. (2011)
was directly copied to represent the group of elements, as the element was most comprehensive.

Other elements were rephrased from the literature. In these cases, the literature provided guidance
on the general description of the element but the individual examples as proposed by the literature
were to vaguely defined to be directly used. The element IOCS3: “What is the estimated budget of the
project?” for example was based on the following elements from the literature: “What is the estimated
CAPEX of the project?” by Bosch-Rekveldt et al. (2011, p736), “How many financial resources does the
project have (e.g. own investment, bank investment, JV-parties, subsidies, etc.)?” by Bosch-Rekveldt
et al. (2011, p736), “Largeness of capital investment?” by Vidal et al. (2011, p5392), “The budget is
sufficient for the task” by Maylor et al. (2013, p48), “Largeness of capital investment” by Qureshi et al.
(2015, p169) and “Project size in terms of capital” by Nguyen et al. (2015, p1374).

Alternatively, some elements were added to the framework as a result of the theoretical framework.
For example, to estimate the size of the social complexity, the element SCS1: “How many
(independent) teams need to be coordinated?” was extracted from the literature. However, if the
number of teams are considered in the social system, then the variability – and interdependence
between the teams should also be included. Since no sources in the literature were found describing
the interdependencies between teams, a new element was created based on the theoretical model to
complement the framework: SCI1: “Interdependence between teams?”

While several articles from the literature highlight the dynamics of the project in general, and some
aspects in particular, no elements within the literature regarding system dynamics were found which
could directly integrated into the framework. The elements relating to the subsystem dynamics were
created for the purpose of the new framework to structurally include elements on the dynamics of c
the size, variety and interdependence of each subsystem based on the theoretical model.

80
The initial literature review provided 274 elements of project complexity. Of these 274 elements, only
5 elements could not be fitted in one of the project’s sub-systems. Additionally, 160 elements could
be directly attributed to either subsystem size, variety or interdependence. 49 elements were not
included in the review as they related to either familiarity or ambiguity which are both not antecedents
of project complexity. Furthermore, 26 elements related to project dynamics and were indirectly
included into the final framework. Finally, 51 elements were omitted as they were described either
too vaguely or too narrowly to be included in the framework.

After the coding and grouping process, a preliminary framework containing 119 elements was
constructed. To gain insight into the practical use of the framework, several projects were analyzed
using the framework. Through this process, it became clear that the number of elements in the
framework had to be reduced to increase the usability of the survey, several of the elements
furthermore required tweaking to improve the clarity of the items and item scales. By iteratively
testing the framework in more projects, the framework was continuously improved.

The final project complexity measurement framework includes 92 unique elements. 6 of these
elements were directly copied from the literature, while 32 elements were rephrased based on
elements found in the literature. 36 elements were included to take into account the dynamic nature
of project complexity. The last 18 elements were not yet described within the literature, but were
added to complement existing elements of the project sub-systems and antecedents.

81