This article was downloaded by: [University of Connecticut]

On: 07 October 2013, At: 17:40

Publisher: Routledge
Informa Ltd Registered in England and Wales Registered Number: 1072954 Registered
office: Mortimer House, 37-41 Mortimer Street, London W1T 3JH, UK

Technology Analysis & Strategic

Management
Publication details, including instructions for authors and
subscription information:
http://www.tandfonline.com/loi/ctas20

What complexity assessments can tell

us about projects: dialogue between
conception and perception
a
Joana G. Geraldi
a
Cranfield School of Management, Cranfield University ,
Cranfield, UK
Published online: 02 Jun 2009.

To cite this article: Joana G. Geraldi (2009) What complexity assessments can tell us about
projects: dialogue between conception and perception, Technology Analysis & Strategic
Management, 21:5, 665-678, DOI: 10.1080/09537320902969208

To link to this article: http://dx.doi.org/10.1080/09537320902969208

PLEASE SCROLL DOWN FOR ARTICLE

Taylor & Francis makes every effort to ensure the accuracy of all the information (the
“Content”) contained in the publications on our platform. However, Taylor & Francis,
our agents, and our licensors make no representations or warranties whatsoever as to
the accuracy, completeness, or suitability for any purpose of the Content. Any opinions
and views expressed in this publication are the opinions and views of the authors,
and are not the views of or endorsed by Taylor & Francis. The accuracy of the Content
should not be relied upon and should be independently verified with primary sources
of information. Taylor and Francis shall not be liable for any losses, actions, claims,
proceedings, demands, costs, expenses, damages, and other liabilities whatsoever or
howsoever caused arising directly or indirectly in connection with, in relation to or arising
out of the use of the Content.

This article may be used for research, teaching, and private study purposes. Any
substantial or systematic reproduction, redistribution, reselling, loan, sub-licensing,
systematic supply, or distribution in any form to anyone is expressly forbidden. Terms &
Conditions of access and use can be found at http://www.tandfonline.com/page/terms-
and-conditions
 Technology Analysis & Strategic Management
Vol. 21, No. 5, July 2009, 665–678

What complexity assessments can tell us

about projects: dialogue between conception
and perception

Joana G. Geraldi∗
Downloaded by [University of Connecticut] at 17:40 07 October 2013

Cranfield School of Management, Cranfield University, Cranfield, UK

Complexity is an eminent concept in the project management community. This paper explores
the value of complexity assessment to evaluate key management challenges of projects.
It compares and contrasts the results of complexity assessments with rich qualitative data
about projects through a multi-case study conducted with seven projects in a large plant engi-
neering company. The results suggest that, if used with caution, complexity assessment can
uncover significant challenges of projects. It also showed that complexities are partly inherent
and partly (self-) induced, and therefore managers and companies should consider complexity
not as given but as negotiable, and actively engage on the shaping of complexity throughout
the project. The assessment of complexity itself is a tool to enable such active management.

Keywords: complexity; uncertainty; project management, contingency

Introduction
Complexity is an eminent concept in the project management community. Among scholars the
concept has been researched since the 1990s resulting in several approaches for its conceptu-
alisation, appraisal and partly management. Among practitioners complexity is a new trend and
some organisations show the interest and will to support, and even apply, the outcome of research.
This makes it a fruitful time to promote a dialogue between our conceptions of complexity in the
academy and practitioners’ perceptions in the realities of projects.
In conversations with project managers and other employees in a large plant engineering com-
pany (main contractor for large engineering and construction projects), the term ‘complexity’
referred to ‘something’ undesirable that made a project unique, more complicated and more
difficult to execute, manage and control or even an ‘excuse’ for mistakes. The existence and
mystification of these intangible, complicated and undefined ‘things’ embedded in projects also
paralysed some of the new inexperienced project managers. This suggests that opening the box
of complexity may help practitioners.
Conceptions of complexity in project management field developed through two streams: com-
plexity in projects, which studies projects through the lenses of the complexity theories, and

∗ Email:[email protected]
ISSN 0953-7325 print/ISSN 1465-3990 online
© 2009 Taylor & Francis
DOI: 10.1080/09537320902969208
http://www.informaworld.com
 666 J.G. Geraldi

complex projects that aim at unfolding dimensions of complexity (e.g. Maylor, Vidgen, and
Carver 2008; Cooke-Davies et al. 2008). This paper focuses on the second stream.
The majority of the research within this stream focused on the development of frameworks
inductively (e.g. Maylor, Vidgen, and Carver 2008; Crawford et al. 2005; Turner and Müller
2006; Geraldi and Adlbrecht 2007), partly aimed at an assessment of a project’s level of
complexity. Few studies were also confirmatory, based on a combination of qualitative and quan-
titative methodology for development of concepts of complexity and validation, respectively
(Shenhar and Dvir 1996; Xia and Lee 2004, 2005; Ribbers and Schoo 2002), but such valida-
tion again cannot provide insights into what would be missing or whether those characteristics
were considered significant. Thus, there is still a demand to critically investigate these concepts
qualitatively.
With this motivation, the aim of the study is to put perceptions and conceptions side by side,
Downloaded by [University of Connecticut] at 17:40 07 October 2013

bringing colours to the hard numbers of complexity assessment. By doing this, it enables one to
discuss what a complexity assessment can tell us about the project and how this relates to what is
the practitioners’ perception of determining factors shaping the management of projects and its
outcomes.
The paper focuses on the use of complexity as a contingency, a way to identify project type
(Maylor, Vidgen, and Carver 2008; Remington and Pollack 2007) to help tailor organisations
and resources to specific project demands, and therewith going away from a one size fits all
approach (Shenhar 2001). Through lenses of contingency theory, it can be said that if complexity
should shape organisational structures, it should have a predicting power, and capture elements
that significantly impact the way projects would be (‘ideally’) shaped. Therefore, the following
questions guided this study:

• What can complexity assessment tell us about projects?

• Can this framework help us to identify and shape appropriate organisational responses to
different types of projects with information available in the beginning of the project?

Voices of conceptions
In the 1980s, scholars studying the construction industry strived to define and measure complexity
(Bennett and Fine 1980; Gidado 1993, in Baccarini 1996). The first publication explicitly focusing
on complexity in a project management journal was in the mid 1990s, as Baccarini (1996) proposed
integration and differentiation based on Lawrence and Lorsch (1967). Thus, the contingency
approach has accompanied studies on complex projects since its start.
Since then, the subject received increasing attention from academics and practitioners (Jaafari
2003; Singh and Singh 2002; Thomas and Mengel 2008).
Aspects related to complexity appeared as ungrouped (Crawford, Hobbs, and Turner 2005;
Müller and Turner 2006), or grouped around, e.g. products, processes, technology and customer
interface (Chapman and Hyland 2004), technological or organisation (Xia and Lee 2004, 2005),
MODeST (mission, organisation, deliver, stakeholders and team) (Maylor, Vidgen, and Carver
2008). However the majority converged to one or a group of structural complexity, uncertainty
and dynamic. Table 1 summarises the key studies on complexity.
This study is based on the framework proposed by Geraldi and Adlbrecht (2007), where com-
plexity is divided into three types: complexity of faith, fact and interaction. Complexity of faith
is similar to the concept of uncertainty and is present when creating something unique, solving
new problems or dealing with high uncertainty. Activities are vague and cannot be solved with
 Dialogue between Conception and Perception 667

Table 1. Overview of key literature in complex projects.

Concepts Contributions

Dynamic and Xia and Lee (2004, 2005) propose the juxtaposition of, on the one hand, technological
structural and organisation and, on the other, dynamic and structural complexity based on
complexity a comprehensive literature review, field interviews and focus groups, and were
subsequently validated by survey with 541 project managers of information system
development projects.
Ribbers and Schoo (2002) define complexity as variability (similar to dynamic), variety
and integration (similar to structural complexity) to capture the environmental
characteristics of Enterprise Resource Planning (ERP) implementations. After the
theoretical definition of complexity, these authors applied the concept to 15 cases of
ERP implementations.
Maylor, Vidgen, and Caver (2008) conducted a ground study on what makes projects
Downloaded by [University of Connecticut] at 17:40 07 October 2013

complex to manage based on exploratory and large-scale workshops with over

100 project managers. The authors proposed the MODeST framework (mission,
organisation, deliver, stakeholders and team) embracing over 100 indicators of
complexity. They discerned structural complexity as a snapshot of the project and
dynamic complexity as to how these changed.
Remington and Pollack (2007) suggested among other types of complexity the
temporally complex, which refers to acute dynamism, especially when changes are
not under control of the team.
Uncertainty and Williams (1999) defines complexity as a combination of structural complexity (number
structural of elements and their interdependence) and uncertainty (defined as uncertainty in
complexity goals and methods, based on Turner and Cochrane 1993). The paper is theoretical
and draws on well-established concepts, such as the interdependencies types. A
later article, Williams (2005) also eludes to the importance of pace as an attribute of
complexity.
Little (2005) proposes a framework based on the juxtaposition of structural complexity
and uncertainty and defined four types of projects: dogs, colts, cows and bulls. The
paper is based on experiences with a company and is not academically developed.
Tatikonda and Rosenthal (2000) investigate the relationship between characteristics
and outcomes of product development projects. Characteristics are technological
novelty (similar to uncertainty) and complexity (degree of interdependence between
and among the product and process technologies to be developed, the newness of
the project’s objectives to the development of organisations; and the difficulty of the
project objective).
Shenhar and Dvir (1996) did not focus on complexity but on the development of a
typology of projects and their implications on project management, but their results
are very close to the structural complexity (scope) and uncertainty (technological
uncertainty). The typology was developed based on a combination of qualitative (26
case-studies in 16 companies) and quantitative methodologies (127 answers in 76
companies). The results were able to prove the contingency hypothesis that different
project types demand different management approaches.
Adding pace Shenhar and Dvir (2007) further developed their two dimensional framework and
created the diamond approach to projects, which considered pace, technology,
novelty and complexity (termed earlier scope).
Adding Apart from Geraldi and Adlbrecht (2007)’s framework, Remington and Pollack (2007)
interaction propose the directionally complex as a type of complexity, referring to ambiguity in
the definition of the objectives together with key stakeholders, especially present in
the beginning of a project, and demand a good relationship management
 668 J.G. Geraldi

off-the-peg solutions, or with pre-defined procedures or answers, such as sales and R&D. Thus,
to learn by doing and re-working are not only acceptable but even expected.
When facing complexity of fact, we do not have enough time to collect, analyse and internalise
information, and have to make decisions and act without properly understanding every piece of
information necessary. The challenge here is to keep a holistic view of the problem and not to
get lost in the, possibly immense, amount of detail. In such an environment, mistakes are almost
inevitable, but these are very expensive, and hence, should be avoided.
The third complexity – complexity of interaction – takes place in the interfaces between
people and organisations, and includes aspects such as politics, ambiguity, multiculturality,
empathy, etc.
Not much needed to be adjusted. Dynamic and pace are the only key dimensions not represented
in the complexity of faith, fact and interaction framework. Technological and organisational
Downloaded by [University of Connecticut] at 17:40 07 October 2013

complexity will be analysed separately, as suggested by Xia and Lee. The evaluation of these
complexities is based on set of indicators already used in the previous studies of the author,
adapted through this literature review (see Appendix 1).

Research design
The research design used in this study was multi-case, which is based on the logic of replication
(Yin 2003) – each case represents an independent experiment that can confirm or disprove emerg-
ing concepts. This research design provided in-depth understanding of the company’s structure,
processes, mechanisms, conditions, relationships and development (Eisenhardt 1989), avoided
the inflexibility of normal science (Kuhn 1962) and kept this investigation as close to the reality
as possible. The method had also a particular value in applied research for generating practical
tools and improvements (Karvinen and Bennett 2006).
The cases were seven different projects executed by a large plant engineering company,
Company A (see company description in next sections). The set of projects were defined together
with members of the organisation (the head of the application department, in the sales phase,
and subsequently evaluated by the head of the scheduling and procurement department), and was
deliberately composed of different types of projects realised in the organisation – differing sizes,
technological difficulty, type, client, countries involved, etc. The aim was to identify the icon
complex projects of the company, showing the different faces of complexity. This was relevant
to explore possible cases that were considered complex but that the current framework could not
capture.
At the start, the sample comprised 28 projects, some of which had been finalised for several years
and others that were still in the early stages of execution. Empirical data allowed the reconstruction
of 12 of these, and seven were considered for the analysis.

Data collection
The data collected was both real-time and retrospective. The projects were analysed during a
three-month permanent stay in the company, in which the author was physically placed in two
different departments (one in the sales phase and the other in the execution phase), and attended
project meetings as a passive note taker.
A record was kept of prompt annotations as well as a protocol of the facts, ideas and stories
(by writing or recording notes), avoiding loss of relevant information.
 Dialogue between Conception and Perception 669

In order to collect more structured information on each of the projects, at least three people
from of each project were interviewed, so that information could be triangulated. Many of the
interviewees were involved in more than one case.
The interview guides were divided into two parts. The first part comprised closed questions
on complexity measurements for different phases of the project. The measurements were partly
developed along the investigation process as the author gained more insights into the complexity
of the company. Consequently questions were modified several times and interviewees were
revisited when judged necessary.
The second part of the interview guide was semi-structured based on a topic guide rather than
questions and it attempted to establish the ‘story’ of each project. The questions were formulated
following the contingencies of the dialogue between interviewer and interviewee (Thiollent 1980),
and detailed with follow-up questions asking for examples, further explanations, and so on.
Downloaded by [University of Connecticut] at 17:40 07 October 2013

Another source of information was documentation provided by interviewees, such as change

orders records, cost calculation, organisational charts, list of amendments on site, lessons learned
documents, etc.

Data analysis
The analysis was based on comparing and contrasting not only the different cases but different
moments of each case. Specifically the perceived complexity was compared in the beginning of
the project, still in the sales and first weeks after contract signature, with how the project evolved
later.
The data analysis followed three stages. First, aspects of complexity were assessed based on the
answers of first part of the guide by those involved in the early phase. The data was triangulated
with assessments of the same case by other people involved in the front end of the project.
Care was given to ensure that the information guiding the evaluation could only have been
established in the beginning of the project by:

• providing assessment divided into phases

• understanding the chain of events and inquiring about the availability of information in each
moment
• observing projects developed as they developed (Cases 1, 3 and 6).

In a second stage, the new aspects of complexity (see last section) were evaluated based on the
open questions of people involved in the front end of the project.
The third stage used similar steps as in Brown and Eisenhardt (1997). First, each case was
analysed separately, the information from several sources was critically joined creating a case
study for each of the projects. Thereafter, this information was contrasted with the evalua-
tion of complexity and points of convergence and divergence were analysed in each case.
Finally, each case was compared, and interpretations, emerging concepts and patterns were reg-
istered and analysed across the cases. The process was interactive and repeated until saturation
emerged.
One of the difficulties in this process was not to colour the analysis of complexity assessment
with insights from qualitative analysis and the other way around. In order to tackle this issue,
quantitative analysis was made first and was not revised during data analysis. Also analysis
was deliberately executed on different days, and information flowing from one to the other was
conscientiously controlled.
 670 J.G. Geraldi

Voices of perceptions
Contextualisation
Company A employs more than 24,000 people in over 200 facilities worldwide and had a turnover
of over ¤3 billion in 2004. The research investigated the company’s business focus with the most
significant turnover of the group, which alone employs almost 10,000 people in over 70 facilities
worldwide.
The company supplies integrated and customised plant solutions for a continuous production
process. The project budget varies from ¤3 million for spare parts or small rebuilds, up to ¤300
million for a new complete production line. A complete plant project takes about 18 months
from contract signature to ramp up. Such plants had low repeatability; in more than 100 years of
existence, the company has sold only two identical plants – which were constructed in parallel
Downloaded by [University of Connecticut] at 17:40 07 October 2013

on the same site. Still, the company is engaged in the standardisation of their product, which
is deemed to have very positive influence on the design quality, delivery time and coordination
efforts, especially relating to new machines.
The market is relatively small and very transparent. The potential clients are concentrated in
the hands of a few players, and so is the competition. Fluctuation of orders intake is a significant
threat to the industry, as losing any large order leads to grave impacts on turnover, as well as to
lost opportunity for technological development in some cases.

Assessment of complexity vs reality

Table 2 indicates results of the assessment of complexity in the beginning of the seven projects
and Table 3 provides the analysis based on results of qualitative data and documentation.

Data analysis and discussions

Complexity assessment is not the Holy Grail (and it was also not expected to be), but it provides
managers with a tool to assess and actively manage complexity. This section discusses key
strengths and weaknesses of the assessment.

Strength: a good snapshot

Despite of its limitation, the comparison between the analysis derived from the assessment and
qualitative data indicates that the complexity assessment provides a good snapshot of areas poten-
tially challenging in the present moment (I), and many of these are engrained in the project and
will continue to be challenging throughout the project.
In Cases 5 and 6, the size of the project and their low technological uniqueness summarised
the key aspects of the project. The two projects were indeed similar, especially as a result of their
prestige and high level of standardisation. In Case 5 however, this degree of standardisation was
very tangible for the client, raising the wrong expectations, while in Case 6 the degree was not
as clear, and expectations were easier to manage. Even though the assessment could not tell the
‘story’, the issues with the client were indicated.
In Case 7 the dynamic was clearly a key issue that was underestimated throughout the project,
and the assessment could have been a warning signal to the team, pointing to the necessity of
mechanisms to deal with changes more carefully.
 Dialogue between Conception and Perception 671

Table 2. Complexity assessment.

Group Characteristics Case 1 Case 2 Case 3 Case 4 Case 5 Case 6 Case 7

Means Faith 3.8 2.8 4.3 3.3 1.3 2.0 2.8

Change 4.0 1.0 4.0 3.5 2.0 2.5 3.5
Fact 3.2 1.8 3.3 2.0 2.8 3.2 2.3
Pace 5.0 2.0 2.0 5.0 3.0 2.0 2.0
Interaction 3.1 1.4 3.8 1.3 1.5 1.3 1.3
Tech 2.8 2.7 3.0 3.5 2.2 2.5 3.2
Org 4.8 1.2 4.8 1.8 1.5 2.3 2.0

Complexity of Level of maturity Tech 3 4 4 5 1 2 3

faith
Downloaded by [University of Connecticut] at 17:40 07 October 2013

Org 5 1 5 2 1 2 2
Customisation Tech 3 5 3 5 2 2 4
and uniqueness
Org 4 1 5 1 1 2 2
Complexity of No. of people/ Tech 2 2 3 2 4 3 3
fact systems
Org 5 1 5 2 2 3 2
Interdependence Tech 2 2 2 2 2 3 2
Org 5 2 4 2 1 3 2
Size of the project 2 1 3 1 4 4 2
Scope 3 3 3 3 4 3 3
Complexity of Reference Tech 4 2 3 2 1 2 2
interaction
Org 5 1 5 2 3 2 2
Transparency Team 1 1 4 1 1 1 1
Client 4 2 5 1 2 1 1
Partners 3 2
Others
Empathy Team 1 1 3 1 1 1 1
Client 4 1 3 1 1 1 1
Partners 3 1
Others
Complexity Tech 3 1 3 5 3 3 5
of change
Org 5 1 5 2 1 2 2
Complexity 5 2 2 5 3 2 2
of pace

The high technological uniqueness and low maturity in Case 4 also suggest a focus on engi-
neering activities, but as all other complexities were low and the relationship with the client
was exceptionally good, appropriate managerial response was not considered. Case 3 had similar
situation but the optimism around the project success was significantly lower through the presence
of all other complexities, which instigated a more appropriate organisational response. Optimism
could also have been an issue in Case 2, however, the project needed less attention, the clarity was
higher and the project was very small, but still technologically challenging, providing engineers
with a good opportunity to try new concepts and negotiate them with the client.
 672 J.G. Geraldi
Downloaded by [University of Connecticut] at 17:40 07 October 2013

Table 3. Analysis based on complexity assessment vs interviews.

Based on the assessment Based on interviews

Case 1 The most complex project from the sample. The key This was a large refurbishment project in Australia. As a result of disagreements
source of complexity is the organisation, it is manifested between the European based headquarters and the project location, the client’s
in terms of complexity of fact, interaction, pace and organisation was itself a source of ‘complexity’. However, what made this project
change. Interestingly, the high complexity of fact is exceptionally complex was the very limited time to complete the work on site,
disproportional to the size of the project. The data also which demanded a high level of pre-assemble. However, in an attempt to save
suggests issues in the relationship with the client. money and profit from favourable exchange rates, the internal organisational
structure (deliberately) involved too many countries. This led to logistic ‘chaos’
later in the project, especially because of import–export regulations, which were
not carefully considered. This was particularly an issue because of the high pace
of the project. Thus, problems emerged in the juxtaposition of ‘self-induced’
organisational complexity and ‘inherent’ high pace.
Case 2 This was the simplest project; the means did not indicate The project was technologically very challenging, but the company had a very good
any complexity. A more detailed analysis shows that the relationship with the client, who was physically very close to Company A. The
project involves high technological uniqueness. calculations were realistic, and the project profited from plenty of resources,
especially engineers, which is an exception. This was the only project that
planned more engineering hours than necessary. The project finished on time, on
budget and on scope.
Case 3 This project is almost as complex as the first, and The project was embedded in a complex political context. The facility in the USA
is particularly characterised by high organisational attracted the client and won the order, but it was closing and all activities had
complexity, and complexity of faith and change. The to be transferred to the headquarters. The US facility did not have enough
organisational uniqueness is the highest of the sample, know-how to design such a machine and was about to sign a contract with very
and the complexity of interaction is particularly high with low technological maturity. The headquarters intervened in the last weeks of
issues in empathy and transparency with both the client negotiation, but technological maturity was still low. Moreover, the client did not
and internal team. This indicates a clear problem in the make the down payment as requested in the contract and it was not clear if the
organisational setting. The high degree of change in the work should continue or not. After the strategic decision of the CEO, a relatively
organisation may be a consequence or cause of such high inexperienced but highly motivated team was built to run the project. The team
complexity. controlled the development in engineering very tightly and did not let the political
issues intervene in the execution of the project. Regular engineering meetings
were established and controlled. The project ended successfully.
 Case 4 Generally the project seems simple, but pace and dynamic The project was technologically very challenging, demanding a new prototype. The
were latent. This combination could be explained by company had a ‘too good’ relationship with the client and the order was sold far
badly managed concurrent work in the beginning of the too quickly (in two weeks only – significantly lower than the usual months up to
project. The low level of technological maturity and high years of negotiations), and therefore technological maturity was very low. There
uniqueness of the order also point to this possibility. were many changes in the beginning of the project as both parties had more
time to mature their decisions. However, the project team was optimistic, and by
Downloaded by [University of Connecticut] at 17:40 07 October 2013

month seven and ‘almost finished’ engineering, it was realised that 20% of the
engineering work was still to come. This led to delays.
Case 5 When looking at the means, there is no alarmingly high This is a large project, and an example of the dark side of standardisation. The
complexity, but the detailed assessment shows that the project is a copy of an existing machine in the same site, but a few years later.
project is very large in terms of budget, scope and number Suppliers and their products and technologies changed, and this demanded
of technical systems involved. Interestingly the number adaptations in the machine. However, the client was reluctant to pay extra for
of people is too small in relation to its size, which points engineering as it is the ‘same’ plant. Internally the project worked very well, it
to a very large but ‘standard’ order. was prestigious and had high priority.
Case 6 Case 6 is very similar to case 5, a slightly less standardised Large and prestigious project to be involved with, which applied a pre-defined
technologically, and lower scope. technological concept and consequently was technologically simple. The
relationship with the client was good, the plant was located in Spain, which is not
far but ‘nice’, and attracted many engineers. High dynamic shortly before closing

Dialogue between Conception and Perception

the contract, but then normal levels of dynamism after that. The project did not
suffer from false expectations, the goals were realistic and enough resources were
made available.
Case 7 Case 7 was very simple except for a relatively high level Dynamics made the project complex to manage. It was a technically challenging
of uniqueness and of change. The level of maturity is project and the client made frequent changes, following the sales negotiations, and
relatively high and therefore it is difficult to understand the changes continued until shortly before delivery, and were accepted without a
the level of change. clear analysis of the impact of changes in the delivery date or in the other parts of
the machine. The continuous changes also led to several technical problems, only
uncovered on site. The company was in a delicate financial situation in which the
demand was very low, and every project was seen with optimism. Change orders
initiated by the client mean extra cash, and larger orders, and therefore these were
welcomed. But this led to a lower profit margin and high penalty payments.

673
 674 J.G. Geraldi

Limitations
The assessment has its limitations. First, complexity assessment, as a thermometer, is meant to
show only the temperature of the body, and therefore it cannot disclose what is really happening.
For example, in Case 1 it would have been reasonable to suggest that high organisational complex-
ity was an answer to the high pace. However what was actually happening was that the high pace
conflicted with the organisational structure in place, making the project even more challenging.
Thus, the interdependence of complexities was key to understand Case 1. Similarly, in Case 7 the
financial situation of the company was driving the high level of changes. In Case 3, in contrast,
complexities were tackled independently. The interdependence of complexity parameters also
influenced other projects.
Second, averages may mislead by neutralising important elements of complexity. This was the
situation in four out of seven cases (Cases 2, 5, 6 and 7), as the mean values did not indicate any
Downloaded by [University of Connecticut] at 17:40 07 October 2013

kind of complexity, but these projects had different complex aspects, i.e. technology (Case 2),
size and standardisation (Cases 5 and 6) and change (Case 7).
Denying the importance of single elements considered characteristics of complexity would
mean that many of projects we consider complex today would be considered simple, for example,
cutting edge research such as the Large Hadron Collider, projects that change continuously, or
those spread over several countries, cultures and languages, or defence projects in which security
constraints slow down the processes dramatically, and so on.
Potential indicators of complexity may be many and everywhere, as suggested by Klir (1991),
who equates complexity to the amount of information required to describe the system (based
on Ashby’s law of requisite variety) and to resolve any uncertainty associated with it. The large
number of indicators (over 100) identified in the inductive study conducted by Maylor, Vidgen,
and Carver (2008) is another evidence of this challenge.
This raises a more fundamental challenge in the conception of complexity assessment: the
balance between too comprehensive and too simple frameworks. For example, if we consider
‘uniqueness of the organisational settings’, it is not clear whether it refers to internal or external
organisation, whether it would be a new client, or a new supplier, or a new partner, etc. By detailing
it further, however, there is a risk of missing relevant indicators or creating such a level of detail
that project managers may lose the overview of what really matters in the project.
This also leads to other relevant questions. If such large number of indicators is now grouped
under the term complexity, what is complexity then? Does complexity lay on the coexistence and
high intensity of complexities or do punctual high values create complex projects? Perhaps these
may be answered by another question. Why are we analysing complexity of projects in the first
place?
This study focuses on complex projects and not complexity in projects. Within this perspec-
tive, the author argues for a broader conception of complexity that may approximate to what
makes projects difficult to manage. The indicators are then ideally shaped by the reasons under-
mining the use of such assessment. For example, if it is used as a way of establishing priorities
(or more powerful organisational designs), it is also important to consider the potential impact
of such assessments in making decisions and shaping behaviour and establishing, for instance
‘preferences’ to most weighted characteristics of complexity.

On the nature of complexity: inherent but also self-induced

Beyond the evaluation of the value of complexity assessment, the results pointed to the constructed
nature of complexity. The cases confirmed that ‘no project is an island’ (Engwall 2003),
 Dialogue between Conception and Perception 675

their complexities are inherent to the project, its context, available competences and history.
For example, past experience shaped the complexity in Case 5. In Case 4, the abrupt and sig-
nificant event in the beginning of the project that became engraved in the way it continued to
evolve. In Case 7, the economic environment encouraged changes that would have been banded
in the past. Cases 2 and 6 showed the influence of clients, which enable a realistic calculation of
projects. Cases 5 and 6 profited from the image of the project inside of the organisation promoting
more access to resources and a smooth development.
However, the cases indicated that complexity can be self-induced and modified. Case 1’s internal
organisational structure was a conscious decision of members of the team. Even the pace in the
construction site was a result of a negotiation with the client, and therefore became a fixed
constraint only after the signature of the project, and even then, further negotiations could have
been possible. Case 3 was able to turn around the project situation, by intentionally treating
Downloaded by [University of Connecticut] at 17:40 07 October 2013

different complexities in different levels of the organisation.

In theory, this indicates the constructed nature of projects, and calls for other theoretical
perspectives rather than contingency, which fails to consider companies as actors influencing
the system to which they belong (Donaldson 2001). Structuration theory (Giddes 1984) could
shadow light into the shaping of complexities, as it considers a mutual-adaptation between
environment and the companies, where both are actively involved and able to influence one
another.
In practice, companies could leverage dynamic capability based on the ability to understand
the constructed nature of projects, and challenge and shape constraints appropriately. The use of
complexity assessment frameworks for analysing complexity could facilitate critical engagement
with contextual ‘constraints’, as it is believed to be a step towards active management: the focuses
lies on complexities as present challenges and not future possibilities.

Towards active management of complex projects

The nature of complexity points to the possibility of its active management. The assessment is
believed to be a tool supporting such management. It was able to predict some of the problems
that projects were facing and were going to face. In contrast to risk assessment, complexity
assessment is not based on assumptions about the future, but around the characteristics of the
situation faced now, and, therefore, more tangible. For example, complexity focuses on the low
level of technological maturity now and not in the possible consequences of this in the future. Risk
management is based on a pro-active thinking, which is very difficult to implement and follow up in
project execution, turning ideal risk management to bureaucratic risk administration. Complexity
assessment provides a different perspective to deal with uncertainty by enabling change in the
mindset from pro-actively dealing with possibilities to actively shaping current characteristics of
the project.
Active management also provides a direction for how to shape the assessment and balance
between too high or low levels of detail. It is suggested to undertake assessments as a reflective
act and not as a ‘check list’, understanding that explanations based solely on the assessment can
be misleading, averages are not a good measurement, absolute values can be questioned, other
aspects not contained in the framework can be relevant and coexistence of complexity should be
taken into consideration. Thus, for an active management of complexity, project managers and
project-based companies can profit from complexity assessments if used as a point of start to
shape appropriate organisational responses to as well as to influence complexity.
Figure 1 provides an overview of the arguments posed here.
 676 J.G. Geraldi
Downloaded by [University of Connecticut] at 17:40 07 October 2013

Figure 1. Overview of arguments.

Conclusions
‘All models are wrong but some are useful’, claims George Box. This study explores the strengths
and limitations of complexity assessments based on the analysis of seven projects in a plant
engineering company based in Germany.
In summary, the cases indicate that the assessment could predict many of the issues in the
projects. However, it is still a challenge to balance levels of detail in the assessment, making it as
simple as possible but not simpler, as claimed by Einstein.
The cases also revealed the constructed nature of complexity.Although projects are embedded in
their context – coloured by past experiences, global and organisational context, etc. – complexities
should not be taken as given in many cases: new colours can be added deliberately. In other words,
complexity is socially constructed, and therefore can be shaped, negotiated and managed actively.
The complexity assessment itself can be used as a vehicle to instigate such management, because
of its focus on what makes the current situation complex rather than on propositions of future
developments.
The study was limited to only one company, in one sector, and consequently, these conclusions
should be further studied in different industrial settings, such as IT, construction, research and
development, in which the framework would be probably adapted and expanded. Longitudinal
studies would also promote better insights into the prediction power of such assessments. It would
also be relevant to study how companies would apply such an assessment in real projects and
whether this would provide the envisaged impact in the long term, and therewith continue the
dialogue between conceptions and perceptions.
 Dialogue between Conception and Perception 677

Notes on contributor
Joana G. Geraldi holds a position as senior research fellow in the International Centre for Pro-
gramme Management (ICPM) at the Cranfield School of Business. After gaining experience
within IT projects, she commenced her PhD in project management at the University of Siegen,
Germany, which was aimed at understanding how companies are able to balance the forces lead-
ing towards ‘bureaucratisation’ and towards ‘chaotification’ of their organisational structures. Her
current research interest lies in organisational solutions for projects and programmes in compa-
nies, specifically, in uncertainty, agility (and change) and complexity management in project and
programme contexts.
Downloaded by [University of Connecticut] at 17:40 07 October 2013

References
Baccarini, D. 1996. The concept of project complexity – A review. International Journal of Project Management 14, no.
4: 201–4.
Bennett, J., and B. Fine. 1980. Measurement of complexity in construction projects. Department of Construction
Management, University of Reading, UK.
Brown, S.L., and K.M. Eisenhardt, 1997. The art of continuous change: linking complexity theory and time-paced evolution
in relentlessly shifting organisations. Administrative Science Quarterly 42, no. 1: 1–34.
Bryman, A. 1995. Research methods and organisation studies, vol. 20. London: Allen and Unwin.
Chapman, R., and P. Hyland. 2005. Complexity and learning behaviors in product innovation. Technovation 24, no. 7:
553–61.
Cooke-Davies, T., S. Cicmil L. Crawford, and K. Richardson. 2008. We’re not in Kansas anymore, Toto: mapping the
strange landscape of complexity theory, and its relationship to project management. Project Management Journal
38, no. 2: 50–61.
Crawford, L., B. Hobbs, and J.R. Turner. 2005. Project categorization systems. Newton Square: PMI.
Donaldson, L. 2001. The contingency theory of organizations. Thousand Oaks, London, New Delhi: Sage.
Engwall, M. 2003. No project is an island: linking projects to history and context. Research Policy 32, no. 5:
789–808.
Geraldi, J.G., and G. Adlbrecht. 2007. On faith, fact and interaction in projects. Project Management Journal 38, no. 1:
32–43.
Gidado, K. 1993. Numerical index of complexity in building construction with particular consideration to its effect on
production time. University of Brighton, UK.
Harvey, H., R. Vidgen, and S. Carver. 2008. Managerial complexity in project-based operations: a grounded model and
its implications for practice. Project Management Journal 39, no. 1: 15–26.
Jaafari, A. 2003. Project management in the age of complexity and change. Project Management Journal 34: 47–57.
Karvinen, K., and D. Bennett. 2006. Enhancing performance through the introduction of customer orientation into the
building components industry. The International Journal of Productivity and Performance Management 55, no. 5:
400–22.
Klir, G.J. 1991. Facets of systems science. New York: Plenum.
Kuhn, T.S. 1970. The structure of scientific revolutions. Chicago: University of Chicago Press, 1996.
Lawrence, P.R., and J.W. Lorsch. (1969). Organisation and environment. Boston, MA: Harvard Business School Press.
Little, T. 2005. Context-adaptive agility: managing complexity and uncertainty. IEEE Software 22, no. 3: 28–35.
Maylor, H., R. Vidgen, and S. Carver. 2008. Managerial complexity in project-based operations: a ground model and its
implications for practice. Project Management Journal 39: 15–26.
Remington, K., and J. Pollack. 2007. Tools for complex projects. London: Gower.
Ribbers, P.M.A., and K.-C. Schoo. 2002. Program management and complexity of ERP implementations. Engineering
Management Journal 14, no. 2: 45–52.
Shenhar, A.J. 2001. One size does not fit all projects: exploring classical contingency domains. Management Science 47,
no. 3: 394–414.
Shenhar, A.J., and D. Dvir. 1996. Toward a typological theory of project management. Research Policy 25, no. 3: 607–32.
Shenhar, A.J., and D. Dvir. 2007. Reinventing project management: the diamond approach to successful growth and
innovation. Cambridge, MA: Harvard Business School Press.
 678 J.G. Geraldi

Singh, H., and A. Singh. 2002. Principles of complexity and chaos theory in project execution: a new approach to
management. Cost Engineering 44, no. 12: 23–33.
Tatikonda, M.V., and S.R. Rosenthal. 2000. Technology novelty, project complexity, and product development project
execution success: a deeper look at task uncertainty in product innovation. IEEE Transactions on Engineering
Management 47, no. 1: 74–87.
Thiollent, M. 1980. Crítica metodológica, investigação social e enquete operária. São Paulo: Ed. Polis.
Thomas, J., and T. Mengel. 2008. Preparing project managers to deal with complexity – Advanced project management
education. International Journal of Project Management 26, no. 3: 304–15.
Turner, J.R., and R. Cochrane. 1993. Goals-and-methods matrix: coping with projects ill-defined goals and/or methods
of achieving them. International Journal of Project Management 11, no. 2: 93–102.
Turner, J.R., and R. Müller. 2006. Matching the project manager’s leadership style to project type. In Proceedings of the
European Academy of Management EURAM 2006 Conference, 17–19 May, Oslo, Norway.
Williams, T.M. 2005. Assessing and moving from the dominant project management discourse in the light of project
overruns. IEEE Transactions on Engineering Management 52, no. 4: 497–508.
Williams, T.M. 1999. The need for new paradigms for complex projects. International Journal of Project Management
Downloaded by [University of Connecticut] at 17:40 07 October 2013

17, no. 5: 269–73.

Xia, W., and G. Lee. 2004. Grasping the complexity of IS development projects. Communications of the ACM 47, no. 5:
68–74.
Xia, W., and G. Lee. 2005. Complexity of information systems development projects: conceptualization and measurement
development. Journal of Management Information Systems 22, no. 1: 45–83.
Yin, R.K. 2003. Case study research. 3rd ed. London: Sage.