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
Transcript
Eindhoven University of Technology
MASTER
Managing project complexitydeveloping tools for practice through design science research
Swinkels, E.
Award date:2016
Link to publication
DisclaimerThis document contains a student thesis (bachelor's or master's), as authored by a student at Eindhoven University of Technology. Studenttheses are made available in the TU/e repository upon obtaining the required degree. The grade received is not published on the documentas presented in the repository. The required complexity or quality of research of student theses may vary by program, and the requiredminimum study period may vary in duration.
General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand 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
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
ii
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
iii
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.
iv
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
v
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.
vi
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.
vii
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.
viii
Table of Contents Abstract ............................................................................................................................................................................................................. iii
Preface ............................................................................................................................................................................................................... iv
Management summary ....................................................................................................................................................................................... v
Table of Contents ............................................................................................................................................................................................. viii
List of Figures ..................................................................................................................................................................................................... ix
List of Tables ...................................................................................................................................................................................................... ix
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.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
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.3 Reframing popular project management methods. ................................................................................................................... 47
5.4 Managing project complexity in practice ................................................................................................................................... 50
6.2 Research contributions .............................................................................................................................................................. 66
6.4 Directions for future research .................................................................................................................................................... 71
Appendix A – Project subsystems .................................................................................................................................................................... 78
Appendix B – Antecedents of project complexity ............................................................................................................................................ 80
ix
List of Figures Figure 1: Core knowledge development cycle. ....................................................................................... 8
Figure 2: Research cycles ......................................................................................................................... 9
Figure 3: Formal model of Project Complexity. ..................................................................................... 22
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
1
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.
2
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
3
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?”
4
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?”
5
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.
6
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
7
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
8
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
for a representation of this process.
Figure 1: Core knowledge development 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.
9
Cycle Chapter (Sub-)Research Question
Methodological Cycle 2. Research design n.a.
Model Development Cycle 3. Towards a model of project complexity
What is project Complexity?
Instrument Development Cycle 4. Quantifying project complexity
How can project complexity be assessed?
Project Profiling Cycle 5. Managing project Complexity Are there different project Arche-types in terms of project complexity?
Project Complexity Management Cycle
5. Managing project Complexity How can project complexity be managed?
Figure 2: Research cycles
10
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’.
11
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?”
12
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.
13
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.
14
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
15
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.
16
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
17
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.
18
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
19
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
20
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.
21
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.
22
Figure 3: Formal model of Project Complexity.
23
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.
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
impact
Highly similar Somewhat similar Highly dissimilar Crawford et al. (2007)
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
needed
Highly similar Somewhat similar Highly dissimilar Vidal et. al. (2011) and Qureshi et al. (2015)
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
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.
33
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’.
34
Figure 10: Baseline project complexity framework.
Element Simple Medium ComplexYour note/output (please choose
the most relevant type element)
Your comments (please put additional
comments if you have any)
Newness of technology, products and markets New product in familiar market New product in unfamiliar marketNew product with new technology in
unfamiliar market
Stability of overall project definition (success
criteria, scope, requirements, methodology(ies),
limitations and flexibility)
Stable project definition; will not
change in foreseeable future.
Project definition might still change in
minor areas in foreseeable future.
Project requires further defining in
foreseeable future.
Magnitude of Legal, social and environmental
implications from performing the project
Project execution and implications
within existing legislation and public
opinion or expectation
Project execution and implications
challenge the existing legislation and
public opinion or expectation
Project execution and implications
outside the existing legislation and
public opinion or expectation
Overall expected financial impact on project
stakeholders
No financial impact on project
stakeholders
For all partners it has a similar
proportional financial impact
Varying distribution of financial impact
per partner (not over time but per
partner)
Strategic importance of the project to the involved
organizations
No strategic importance to involved
partners
For all partners similar strategic
importance
Different strategic importance per
partner (not over time but per partner)
Stakeholder cohesion regarding the characteristics
of the type of business/activity (size, functional
role, public/private)
Only similar stakeholder profilesLimited differences of stakeholders
profilesDifferent stakeholder profiles
Number of interfaces between partners and
departments within partners organization (like
legal, marketing, R&D)
3 Interfaces 4-7 Interfaces More than 7 Interfaces
Cultural variety of the team members (ref.
Trompenaars chart, see last slide)All in same quadrant 1 in other quadrant In more than 2 different quadrants
Collaboration complexity
All partners have worked together
before in a project (not necessarily all
in the same project)
Two key partners have worked
together before in project(s)
All partners are new to each other, they
have never worked together before in a
project
Project complexity: 0 0 0
Overall project complexity: Medium
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)
PROJECT NAME:Name of assessor:
35
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
36
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.
3 Interfaces 4-7 Interfaces More than 7 Interfaces
PO8 Cultural variety of the team members (ref.
Trompenaars chart, see last slide)
All in same quadrant 1 in other quadrant In more than 2 different
quadrants
PO9 The work will be carried out by independent
teams
The work in carried out by a
single project team.
The work is carried out by
several project teams
independently of each
other, with semiannual
coordination meetings
The work is carried out by
several project teams
working closely together,
with weekly or monthly
coordination meetings
PO10The work will be carried out in a single
country/timezone/location
1 - 2 Nationalities, 8
overlapping office hours
and all partners located
within 200 km of each
other
3 - 4 Nationalities, 6
overlapping office hours
and all partners located
within 200 to 1000 km of
each other
5 or more Nationalities, 4
or less overlapping office
hours and all partners
located within 1000 km or
more of each other
Scale Score
Project Environment 1 2 3
PE1 Stability of the project environment (legal and
social)
Stable project environment
will not change in
foreseeable future.
Project environment might
still change in minor areas
in foreseeable future.
Project environment will
experience considerable
changes in the foreseeable
future.
PE2 Familiarity with the project environment
(legal and social)
Familiar laws and familiar
public stakeholders
Familiar laws and unfamiliar
public stakeholders
Unfamiliar laws and
unfamiliar public
stakeholders
PE3 Magnitude of Legal and social implications
from performing the project
Project execution and
implications within existing
legislation and public
opinion or expectation
Project execution and
implications challenge the
existing legislation and
public opinion or
expectation
Project execution and
implications outside the
existing legislation and
public opinion or
expectation
38
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.
39
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.
40
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.
41
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
42
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.
43
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
44
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.
45
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.
46
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.
47
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
- Separate uncertainty from complexity. - Manage uncertainty through planning. - Manage complexity by breaking down the project into independent
parts. - Integrate late in the process and only when subsystems are stable. - Minimize deviations from the plan. - Manage top-down through milestones and formal control metrics.
- Simple organization. - Approach is generally well known in
practice and well supported by literature.
- Well-developed progress control tools.
- Easy to introduce/switch project members.
- Rigidity of the organizational system.
- Slow pace of development. - High cost of integration. - Higher chance of rework and
delays. - Reactive coordination - Risk of demotivating the project
team. - Difficult to react to change.
- Small-scale and large projects.
- Stable environments.
Example(s): - A4, LAD, PRINCE2,
PMW.
Inte
grat
ion
-dri
ven
ap
pro
ach
- Integrate subsystems early and continuously; verify subsystems through testing to measure project progress.
- Manage complexity by Identifying challenging moments of integration and allocating the most skilled resources to aid integration.
- Manage uncertainty by configuring the project such that uncertainty is identified early and relevant resources can be allocated.
- Utilize both formal and informal communication, encourage interactions between teams and involve the customer.
- Project members are encouraged to proactive manage their tasks and contextualize their work within the broader scope of the project.
- Deliver fast projects that meet and often even exceed targets.
- Early identification and resolution of faults.
- Minimalize integration issues.
- Improved communication.
- Encourages learning.
- React and converge on critical emerging issues.
- More stressful work environment and potential for burnout of key-actors.
- Requires highly skilled project members.
- Requires more resources simultaneously.
Context: - Projects where
lead-time and time of delivery are sacred.
Example(s):
- DSDM
Dyn
amic
Syn
chro
niz
atio
n-d
rive
n a
pp
roac
h - Actors perform best under complexity when they are able to
understand the whole project system. - 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. - Work is structured by actively creating reciprocal dependencies
between work groups. Each sub-system is developed by multiple teams, and each team works on multiple subsystems.
- Decision making is done bottom up by the relevant project teams. The contact with the customer is proactively managed and changes are 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.
- Allows for fast adjustments to emerging events.
- Empowers and motivates project members
- Fast project pace, potentially resulting in an increased competitive advantage.
- High convergence and transparency within the project.
- High capacity to solve problems in real time.
- Improves sense-making.
- Less management control. - May result in an unnecessarily
complex project structure. - Parallel execution of tasks may
induce risks later in the project as a result of project changes.
- More stressful work environment and potential for burnout of key-actors.
Context: - Projects exposed to
large and continuous changes in requirements.
Example(s):
- Process management
61
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.”
62
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.
63
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
64
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
65
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
66
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-
67
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).
3 Interfaces 4-7 Interfaces More than 7 Interfaces
PO8 Cultural variety of the team members (ref.
Trompenaars chart, see last slide)
All in same quadrant 1 in other quadrant In more than 2 different
quadrants
PO9 The work will be carried out by independent
teams
The work in carried out by a
single project team.
The work is carried out by
several project teams
independently of each
other, with semiannual
coordination meetings
The work is carried out by
several project teams
working closely together,
with weekly or monthly
coordination meetings
PO10The work will be carried out in a single
country/timezone/location
1 - 2 Nationalities, 8
overlapping office hours
and all partners located
within 200 km of each
other
3 - 4 Nationalities, 6
overlapping office hours
and all partners located
within 200 to 1000 km of
each other
5 or more Nationalities, 4
or less overlapping office
hours and all partners
located within 1000 km or
more of each other
Scale Score
Project Environment 1 2 3
PE1 Stability of the project environment (legal and
social)
Stable project environment
will not change in
foreseeable future.
Project environment might
still change in minor areas
in foreseeable future.
Project environment will
experience considerable
changes in the foreseeable
future.
PE2 Familiarity with the project environment
(legal and social)
Familiar laws and familiar
public stakeholders
Familiar laws and unfamiliar
public stakeholders
Unfamiliar laws and
unfamiliar public
stakeholders
PE3 Magnitude of Legal and social implications
from performing the project
Project execution and
implications within existing
legislation and public
opinion or expectation
Project execution and
implications challenge the
existing legislation and
public opinion or
expectation
Project execution and
implications outside the
existing legislation and
public opinion or
expectation
69
Figure 17: Model of Complexity
70
Approach: Core principles: Strengths: Weaknesses: Context: P
lan
nin
g-b
ased
ap
pro
ach
- Separate uncertainty from complexity. - Manage uncertainty through planning. - Manage complexity by breaking down the project into independent
parts. - Integrate late in the process and only when subsystems are stable. - Minimize deviations from the plan. - Manage top-down through milestones and formal control metrics.
- Simple organization. - Approach is generally well known in
practice and well supported by literature.
- Well-developed progress control tools.
- Easy to introduce/switch project members.
- Rigidity of the organizational system.
- Slow pace of development. - High cost of integration. - Higher chance of rework and
delays. - Reactive coordination - Risk of demotivating the project
team. - Difficult to react to change.
- Small-scale and large projects.
- Stable environments.
Example(s): - A4, LAD, PRINCE2,
PMW.
Inte
grat
ion
-dri
ven
ap
pro
ach
- Integrate subsystems early and continuously; verify subsystems through testing to measure project progress.
- Manage complexity by Identifying challenging moments of integration and allocating the most skilled resources to aid integration.
- Manage uncertainty by configuring the project such that uncertainty is identified early and relevant resources can be allocated.
- Utilize both formal and informal communication, encourage interactions between teams and involve the customer.
- Project members are encouraged to proactive manage their tasks and contextualize their work within the broader scope of the project.
- Deliver fast projects that meet and often even exceed targets.
- Early identification and resolution of faults.
- Minimalize integration issues.
- Improved communication.
- Encourages learning.
- React and converge on critical emerging issues.
- More stressful work environment and potential for burnout of key-actors.
- Requires highly skilled project members.
- Requires more resources simultaneously.
Context: - Projects where
lead-time and time of delivery are sacred.
Example(s):
- DSDM
Dyn
amic
Syn
chro
niz
atio
n-d
rive
n a
pp
roac
h - Actors perform best under complexity when they are able to
understand the whole project system. - 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. - Work is structured by actively creating reciprocal dependencies
between work groups. Each sub-system is developed by multiple teams, and each team works on multiple subsystems.
- Decision making is done bottom up by the relevant project teams. The contact with the customer is proactively managed and changes are 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.
- Allows for fast adjustments to emerging events.
- Empowers and motivates project members
- Fast project pace, potentially resulting in an increased competitive advantage.
- High convergence and transparency within the project.
- High capacity to solve problems in real time.
- Improves sense-making.
- Less management control. - May result in an unnecessarily
complex project structure. - Parallel execution of tasks may
induce risks later in the project as a result of project changes.
- More stressful work environment and potential for burnout of key-actors.
Context: - Projects exposed to
large and continuous changes in requirements.
Example(s):
- Process management
Figure 18: Comparison of project complexity management approaches
71
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.
72
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.
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
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.
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
200
400
600
800
1000
8,8 8,9 9,0 9,1 9,2 9,3 9,3 9,4 9,5 9,6 9,7
Fre
qu
en
cy
Bin
Histogram - Example case 1
Frequency
Cumulative %
0,00%
20,00%
40,00%
60,00%
80,00%
100,00%
120,00%
0
100
200
300
400
500
600
700
8,3 8,4 8,5 8,7 8,8 8,9 9,0 9,2 9,3 9,4 9,5
Fre
qu
en
cy
Bin
Histogram - Example case 2
Frequency
Cumulative %
74
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.
75
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).
76
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.
77
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.
78
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.
79
Cluster Dimension of project complexity Number of articles Articles
(Inter-) organizational Complexity
Organizational 8 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)
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 Complexity
Technological/ task 10 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)
Development 1 Kim et al. (2003)
Environmental Complexity
Environmental/context 5 Bosch-Rekveldt et al. (2011), He et al. (2015), Nguyen et al. (2015), Gransverg et al. (2013) and 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 Scope
Goal/Mission/Directional/Scope 3 He et al. (2015), Maylor et al. (2008) and Nguyen et al. (2015)
Social Complexity
Cultural 1 He et al. (2015)
Team 1 Maylor et al. (2008)
Informational 1 He et al. (2015)
Socio-political Complexity
Socio-political 4 Nguyen et al. (2015), Maylor et al. (2013), Geraldi (2011) and Crawford (2007)
Others 4 Kim et al. (2003) and Crawford (2007)
Table 8: Dimensions of project complexity in literature.
80
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.
81
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.
![Seeker [ehv3] Eindhoven](https://static.documents.pub/doc/80x56/5594536e1a28abc84f8b4770/seeker-ehv3-eindhoven.jpg)
