CITI CofEe Club

White paper
Project complexity

Thomas Docker and

Geoff Vincent

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
Page 1 of 16
 Preface

This white paper has been written by Thomas Docker and Geoff Vincent.

The white paper has been developed from an earlier white paper produced by
Thomas Docker, following a workshop held on project complexity at CITIs CofEe
Club on 12th June, 2008, hosted by Norwich Union Healthcare.

CITI's Centres of Excellence Club (CofEe Club) provides a networking environment

for senior managers with responsibilities for making their organisations highly
successful in portfolio, programme and project management (PM3).

If you want to know more about CofEe Club, please go to our forum at
www.eciti.co.uk/cofee and click on Introduction to CofEe Club.

CofEe Club

Page 2 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
 Permission is given to quote from this
paper, subject to any quote providing
acknowledgement of the source.

CITI Limited, 2009

Page 3 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
 Project complexity

It is generally accepted that organisations are now operating within a more challenging
environment than previously, and that this environment is likely to continue becoming more
challenging for a number of years yet.

Arguably, many change initiatives and products that make it to market are testing the
capability of the PM3 community.1 Increasingly, practitioners are subscribing to a view that
projects per se are becoming more complex. However, little has been done to substantiate
this claim and there is no generally agreed view on what complexity means in PM3.

In this white paper, a project view of complexity is developed that distinguishes it from
concepts with which it is often confused; notably, complicated and uncertainty.

A scheme is proposed for determining complexity in a project, based around four sources.
By way of example, an approach to developing numerical scoring schemes is presented,
which would allow a project to be given a numerical score to describe its overall level of
complexity. The paper also contains some working principles that could be incorporated
into an organisations enterprise project office as a starting point for developing a corporate
view on project complexity.

It is suggested in the paper that an organisation which can determine the complexity level in
a project can make meaningful decisions on how the complexity is to be managed. The
view taken is that complexity management should be more the concern of the project board
than the project manager.

Developing a view on complexity

Complexity has been an area of study for many years, particularly in mathematics and
computing, arguably predating the digital computer through the work of Turing and others.

The most reported association is chaos theory. In mathematics, chaos theory describes the
behaviour of dynamic systems (i.e., systems whose state evolves with time) that are highly
sensitive to initial conditions. This behaviour has been characterised in the butterfly
effect.2 As a result of this sensitivity, which manifests itself as an exponential growth of
perturbations from the initial conditions, the behaviour of chaotic systems appears to be
random. This happens even though these systems are deterministic; that is, their future
dynamics are fully defined by their initial conditions, with no random elements involved.
This behaviour is known as deterministic chaos, or simply chaos.

Page 4 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
More recently, complexity has become a focus for management disciplines and it is here
that PM3 complexity has particular relevance. According to Blackman:3

Complex systems are found in nature and society. They are defined by relationships
and networks rather than by their constituent elements. These relationships form to
exchange information and through this information exchange the system evolves
behaviours that distinguish it from the external environment. In social systems this
includes shared meanings and practices.

The increase in emphasis by the professional bodies and in the literature on softer
disciplines, such as stakeholder management and leadership, suggests that managing
projects as systems containing human relationships and networks, with significant
information interchange, may be more important than treating them as technical challenges.

Warren Weaver posited that the complexity of a particular system is the degree of difficulty
in predicting the properties of the system if the properties of the systems parts are given.4

This is a useful summary from which we can develop the following definition for complexity,
as it relates to projects:5

Complexity in a project is the degree of difficulty in predicting the properties of the

project, if the properties of its components are given, as a consequence of the human
relationships and networks that exist within and around the project.

By way of a simple example: if we plan a specific project, how difficult would it be to write
an accurate, reasonably detailed, post-project review (incorporating lessons learned)
immediately following planning? If the project is of three months duration, using a small
number of known resources, producing a well understood product, we might be able to get
reasonably close to what will occur in the project. In the majority of cases, however,
relationships and networks are likely to come into play that would make such crystal ball
gazing unsuccessful, if not highly misleading.

Making explicit in the definition human relationships and networks reflects the view that
human complex systems are different from others in nature and need to be modelled
differently.6 According to Snowden and Boone, the following are ways that humans are
distinct from other animals:

They have multiple identities and can fluidly switch between them without conscious
thought. (For example, a person can be a respected member of the community as
well as a terrorist.)

They make decisions based on past patterns of success and failure, rather than on
logical, definable rules.

Page 5 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
 They can, in certain circumstances, purposefully change the systems in which they
operate to equilibrium states (think of a Six Sigma project) in order to create
predictable outcomes.

Complexity and uncertainty

It is worth noting that the definition for complexity, given earlier, includes the statement that
the properties of a projects components are known. Within the literature of project
management, there appears to be unnecessary confusion in distinguishing complexity from
uncertainty.

Scott Page distinguishes between complex and uncertain in the following way:7

A complex environment [] differs from an uncertain environment. In the latter, the

multiple outcomes associated with an action are just assumed. In the former, the
multiplicity results from interdependence of actions.

There have been attempts to relate complexity and uncertainty together in projects by
stating that a project is complex because of the degree of uncertainty that exists within it.
This view is not subscribed to here: one can be completely uncertain about an
environment, through lack of knowledge, when that environment is straightforward. If one
stood facing a closed door with no knowledge of what is on the other side, a level of
uncertainty is likely to exist. What is on the other side may, simply, be an empty cupboard.
On the other hand, it could be a completely new universe populated by aliens; something
that is highly complex.

It is suggested here that a perception of complexity abounds in projects due to not

addressing uncertainty in the most appropriate way or at the most appropriate time. In a
sense, after Shannon, this could be described as a form of information entropy.8 The less
useful project information is available or contained in interactions (e.g., meetings and
reports), the higher the projects entropy. This entropy would include misinformation and
attempts to hide information when it is deemed unsuitable, but would not include cases
where disinformation (or counter-knowledge) is provided deliberately to mislead.
Disinformation is more clearly an indication that there is something pathologically wrong
with a project.

Significant project entropy is considered a characteristic of far too many projects. Two
possible, but related reasons are:

1. that agreement does not exist between the project manager and the project board
on what needs to be monitored and made visible within the project

2. an organisation has standards of reporting that is not suited to the project and what
it is meant to achieve.

Page 6 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
The difference between complicated and complex

Another area of confusion, which is fundamental to our interest, is differentiating complex

from complicated. Distinguishing between them is reasonably straightforward to explain, by
way of an example due to Moore.9

The wiring on an aircraft is complicated. To figure out where everything goes would take
a long time. But if you studied it for long enough, you could know with (near) certainty
what each electrical circuit does and how to control it. The system is ultimately
knowable. If understanding it is important, the effort to study it and make a detailed
diagram of it would be worthwhile.

So complicated = not simple, but ultimately knowable.

Now, put a crew and passengers in that aircraft and try to figure out what will happen on
the flight. Suddenly we go from complicated to complex. You could study the lives of all
these people for years, but you could never know all there is to know about how they will
interact. You could make some guesses, but you can never know for sure. And the
effort to study all the elements in more and more detail will never give you that certainty.

So complex = not simple and never fully knowable. Just too many variables interact.

Managing humans will never be complicated. It will always be complex. So no book or

diagram or expert is ever going to reveal the truth about managing people.

If this is the case, then technically complex projects are complex because of the human
aspects and not the technical intricacies, which are just complicated and, ultimately,
knowable.

As all projects are human endeavours, each project will have an inherent level of
complexity. If this is so, is there such a thing as a simple project? The answer is yes, if
we accept that simple is the opposite to complicated. This interpretation appears to be
consistent with a view expressed by Tony Hoare, within the context of designing software:10

There are two ways of constructing a software design. One way is to make it so simple
that there are obviously no deficiencies. And the other way is to make it so complicated
that there are no obvious deficiencies. The first method is far more difficult.

The final comment of Hoare is particularly pertinent in projects. Taking the time and effort
to make things simple, or keep them so, is often not done or allowed to be done, with the
result that many project products are more complicated than they need to be, increasing the
likelihood of unfortunate consequences.

If simple is the opposite of complicated, is there an opposite of complex? As our definition

of complex refers to (the effects of) degrees of interaction, independent is a suitable
opposite. However, the nature of projects is such that it is highly unlikely that an
independent project can exist.
Page 7 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
Snowden and Boone provide a framework that is consistent with our separation of
complicated and complex. They describe a complicated context as the domain of experts
and a complex context as the domain of emergence. They argue that:

In a complicated context, at least one right answer exists. In a complex context,

however, right answers cant be ferreted out. Its like the difference between, say, a
Ferrari and the Brazilian rainforest. Ferraris are complicated machines, but an expert
mechanic can take one apart and reassemble it without changing a thing. The car is
static, and the whole is the sum of its parts. The rainforest, on the other hand, is in
constant flux a species becomes extinct, weather patterns change, an agricultural
project reroutes a water source and the whole is far more than the sum of its parts.
This is the realm of unknown unknowns, and it is the domain to which much of
contemporary business has shifted.

Snowden and Boone suggest that modern business leadership increasingly needs to be
able to manage complexity.

Inherent and added complexity

As projects depend on human interactions, there will be an inherent level of complexity in

any project and this inherent complexity cannot be removed. Unfortunately, it is relatively
easy to add complexity into a project. Typically, this is done by making the project more
complicated and, because of the human interactions involved in this increased
complication, extra complexity results.

A few examples of added complication that lead to added complexity are:11

Not having a clear mission for a project

Not having sensible and agreed roles and responsibilities

Not having realistic estimates on which to base the planning

A just do it environment.

Factors that can be shown to impact inherent and added complexity

There is plenty of evidence in the reporting of public projects, for a number of the following
factors, plus a general acceptance of the others. This list is not exhaustive. It is
reasonable to assume that most, if not all of these, apply to non-public projects as well:

Public or corporate profile the political environment (both a small p and capital
P)

Page 8 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
 Stakeholders such as the number, type, positioning and stability of position; clarity
and acceptance of roles and responsibilities

Uncertainty the level and when and how it is resolved12

Statement of requirements agreeing in a timely fashion what the problem or

opportunity is that is being addressed and what would constitute an acceptable
solution (product)

Technical complexity in terms of the complexity of the products being produced

and their method of production, or the way we wish or need to manage the project
(e.g., an excessively time-boxed project requiring schedule crashing, or a resource
constrained project requiring the use of unsuitable resources)

Financial relating to funding and benefits realisation; realistic business cases.

Measuring complexity

If we are to make meaningful statements regarding the complexity of a project, we need to

be able to characterise complexity. An obvious first question may be: is there a complexity
ruler by which the complexity of a project can be measured as a single metric a
complexity score? Those who are aware of the information economics (IE) scheme for
assessing the relative business worth of heterogeneous projects, would probably answer
yes.13 In IE, assessing each project leads to the production of a single integer value
(score). Interpreting the value of a single project has no significant purpose. The
approach has significance when used to compare the integer values across a number of
projects to help decide which projects should be part of a (corporate) portfolio. As a first-
level indicator, the relatively higher value a project has, the more suitable it is to add or
retain in the portfolio. In practice, other considerations around portfolio mix will need to be
taken into account in making a decision on which projects to have in the portfolio.

A major focus of interest for our discussion of IE is that the single point value for a project is
determined from a number of factors that are assessed using more complicated sub-
schemes that analyse both quantitative and qualitative data. Given, in particular, the
dependence on qualitative data, the concept of a universal IE ruler for measuring projects is
flawed. Applying the scheme consistently within a single organisation is problematic
enough.

If we transfer these ideas into measuring complexity in projects, it might be possible to, at
least, define an organisation-dependent ruler for measuring complexity that depends on
complex-project equivalents of the sub-schemes in IE. A recent example of where this
have been done is in the complex modernisation programme in Remploy.14

As a starting point, figure 1 identifies four sources of complexity to represent our sub-
schemes; namely:15
Page 9 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
 Organisational relates to the formal and informal governance and management
structures within an enterprise, particularly the relationship between the enterprises
governance and management structures and those used within projects. This can
be paraphrased as the political arena. Also refers to the resourcing of projects.

Technical refers to both the product technical challenges in developing the project
product(s) and those challenges that relate to the way the project is run (e.g., the
need for significant schedule crashing to achieve a deadline).

Business implication relates to business pressures consequent on the running of

the project and the use of the project product(s) to deliver business value.

Statement of requirements (SoR) relates to the clear determination of the problem

or opportunity to be addressed, described through requirements, and what would
constitute a satisfactory solution, with the commitment to these by the project
stakeholders throughout the life of the project.

These are not, necessarily, independent from each other. The lack of a skilled resource,
e.g., may be due to all of the following: fiefdoms in the organisation or restrictions on
buying in resource (organisational complexity); lack of general availability of resource with
the required skills due to relative novelty of the solution (organisational and technical
complexity), which is brought about by stakeholders stating unrealistic wants rather than
needs (statement of requirements complexity). Also, addressing one may impact others;
e.g., solving a resourcing issue by putting a less-skilled-than-required person on an
assignment may be done at the cost of increasing the technical complexity.

Figure 1 provides an example scheme for interpreting the four sources of complexity and
their levels.16 Most of the elements are based on quantitative data and, arguably, those
that are qualitative can be discriminated within enough to allow measurement. The scheme
probably presents the most detailed discrimination that can be supported in practice: low,
medium and high. To go further has connotations of the emperors new clothes!

The values in figure 1 provided to discriminate the complexity levels have been determined
from ongoing research carried out at CITI since 1996 and are proposed for general use.
Possibly, over time, an individual organisation may seek to modify these values, based on
metrics collected by its enterprise project office. As well, other characteristics to be
measured may be identified to augment or replace those shown. If this is the case, care
needs to be exercised that a single factor is not being magnified, unnecessarily, by its
appearance in different sources. It has already been noted that in most projects the
sources of complexity are likely to have interdependencies. One of the strengths of the
scheme in figure 1 is the general independence of the characteristics in each source
assessment.

Page 10 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
Figure 1 measuring the sources of project complexity

Organisational Complexity
Low Medium High
Stakeholder (SH) SH understands and Sponsor commitment is Sponsor detached
conflict potential supports change variable / low SH displays different
outcomes SH generally in agreement, priorities / interests
but disagrees over details
Sources of Single source OR 2 3 sources 4+ sources OR
resources Fixed / fused team Multiple sources
geographically distant
Project involves < 5 procedural 5 6 procedural changes Multiple functional
changes to changes 2+ functional changes changes, impacting
operations in SH < 2 functional changes across the company
business units
Technical Complexity
Low Medium High
Number of products < 10 primary products < 25 primary products > 25 primary products
< 100 sub products < 400 sub products > 400 sub products
Number of different < 4 categories 4 7 categories > 7 categories
categories of
product
Number of external < 2 dependencies 2 5 dependencies > 5 dependencies
(to the project)
dependencies
Compression < 7% 8% 20% >20%
against natural
sequencing
Business Complexity
implications Low Medium High
Approach / budget Internal Business External
fixing agency
Timescales fixed by External Internal Business
Source of major Known within control Unknown within control of Outwith user remit
risks to benefits of user user
Statement of Complexity
Requirements Low Medium High
(SoR)
Clarity of products All primary products All primary products Some primary
countable and countable products not yet
describable < 20% of products not understood
describable at a detailed > 20% of products not
level describable at a
detailed level
Clarity of problem to SHs able to describe Problem to be addressed Nature and / or
be solved nature of problem in unclear OR magnitude of problem
problem terms SHs do not agree on as yet unknown
SHs agree on nature of nature of problem
problem
Statement of Benefits stated and Benefits stated Multiple benefits with
benefits nature of business Business impact not conflicting business
impact understood and understood and/or agreed implications.
agreed with SHs with SHs Change plan not
Benefits to product agreed with SHs
linking clear

Page 11 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
Providing a profile of project complexity

Using the above scheme, a radar diagram can be used to provide a highlight view of the
complexity profile of a project, along the lines of the example shown in figure 2.

Figure 2 radar diagram showing the complexity profile for a project

Organisational

SoR Technical

Business implications

Working from the inside, the lozenges indicate low, medium and high complexity,
respectively, for the four sources. The coloured-in shape represents a project with low
organisational complexity, medium business implications and SoR complexities, and high
technical complexity. The minimum coloured region would have low complexity for all four
sources and will correspond with the innermost lozenge. The maximum coloured region
would correspond to the outermost lozenge and it is questionable whether any organisation
would seek to run such a project. If it does, the governance of the project needs to be such
that the management of the complexity can be separated from the management of the
project. We will elaborate on this in the section titled managing complexity.

Numerical scoring schemes

If deemed appropriate, a numerical scoring scheme can be developed to provide an overall

measure for comparison purposes, similar in principle to the IE score. Numerical scoring
schemes have wide application in decision analysis and typically involve the use of value
functions and weightings.17 A simple example scheme is one where low complexity is given
a value of 1, medium complexity a value of 2, and high complexity a value of 3; as well,
each source of complexity is given a weighting of 1. With this scheme, the numerical score,
NS, for the example project in figure 2 is derived as follows, working clockwise round the
radar diagram, starting at organisational complexity, where each factor is value x weighting:
Page 12 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
NS = 1x1 + 3x1 + 2x1 + 2x1 = 8

(low organisational + high technical + medium business implications + medium SoR).

Using this scheme as a first-level indicator, lower scoring projects are likely to be favoured
over higher scoring ones. If this scheme was being used in choosing a project portfolio,
many other factors would need to be included in any decision making (e.g., financials and fit
to business strategy).

Five scoring scheme examples are shown in figure 3, reflecting different emphases.
Looking at scheme E, the sources have been ranked (highest to lowest) business
implications (BI), organisational, SoR, and technical. This could suggest that an
organisation using this scheme is best able to address technical complexity, followed by
SoR complexity, with organisational complexity (i.e., politics) posing a bigger challenge,
and business implications being most critical.

Figure 3 example scoring schemes

Complexity levels Sources of complexity

Figure 2
values (v) weightings (w)
example
Scheme L M H Org Tech BI SoR NS Comment

A 1 2 3 1 1 1 1 8 Simple scheme used

previously. Each complexity
source value is multiplied by
its weighting (v times w):
1x1 + 3x1 + 2x1 + 2x1 = 8

B 1 2 3 2 1 2 1 11 Organisational and business

implication weightings are
double those of scheme A:
1x2 + 3x1 + 2x2 + 2x1 = 11

C 1 2 4 2 1 2 1 12 Scheme B modified with

doubling of values rather than
linear increase:
1x2 + 4x1 + 2x2 + 2x1 = 12

D 1 3 9 2 1 2 1 20 Scheme B modified with

tripling of values rather than
linear increase:
1x2 + 9x1 + 3x2 + 3x1 = 20

E 1 3 9 3 1 4 2 30 Sources of complexities
ranked using different
weights, with tripling of values
for complexity levels:
1x3 + 9x1 + 3x4 + 3x2 = 30

Page 13 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
Managing complexity

It is suggested here that managing complexity is fundamentally different from project

management. Up to a point, which is probably organisation-specific (and will vary over time
as changes happen within an organisation), standard project management techniques will
handle low levels of complexity. Beyond that point, the organisation will need to ensure
robust project governance and business management activities are in place to ensure the
complexity can be managed to a satisfactory level by business managers, consistent with
Snowden and Boones views of the competences required of business leaders. In which
case, the project manager should be better able to focus on the complicated elements and
use standard project management techniques to run the project.

In the simplest of cases, managing much of the complexity would be the responsibility of
the sponsor or project board. In reality, this is probably what happens in most organisations
at the moment, but in an ad hoc fashion and usually as a recovery measure: when a
project starts to go pear-shaped senior management interest often increases and they
become more involved in decision making. If an adequate assessment scheme is in place,
more informed decisions could be made early in the project on the most appropriate
structure of the project board and the responsibilities and workload of its members.

In most practical environments, it is likely that the project manager will still be required to
manage some level of complexity. If this is the case, there are two obvious requirements:

1. The project manager is known to be able to manage complexity at this level

2. The organisation provides the best support environment, through the most
appropriate project governance structure.

Hopefully, what is being proposed here will allow a more rigorous approach to managing
project complexity to be adopted within organisations. With this in mind, a set of working
principles are provided in the next section.

Working principles

These working principles can form the basis for developing an approach to managing
complexity.

All projects have an inherent level of complexity

Some projects are relatively straightforward, which means they have low complexity, and
some are highly complex.

Complexity is not a binary measure

As a consequence of the previous principle, it is not the case that a project is either
complex or not. This is a complex project is, therefore, a tautology.18
Page 14 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
Being complex and being complicated are two different things
A project may involve the use of complicated processes or the production of complicated
products without being significantly complex.19

Large projects do not need to be significantly complex

It is not the case that all large projects are significantly complex, so they should not be
treated as such.

Small projects are not necessarily of low complexity

Nor is it the case that all small projects are of low complexity. Some may be highly
complex, so do not let all small projects be treated as relatively trivial.

Each project can have complexity added to it

Complexity can be added into projects from the start (e.g., through unrealistic business
cases and poor governance) and throughout the life of the project.

Minimise added complexity

As a follow on from the previous comment, it is considered the responsibility of all those
involved with a project to minimise the added complexity.

Complexity management is different from project management

Project management techniques do not scale up to provide the right type of management
for medium to highly complex projects. The application of business management
techniques by senior business managers is required to ensure a project manager can
function successfully.

Conclusion

This paper has demonstrated that project complexity can be moved from an abstract
concept to a tangible, manageable entity. To do this beyond theoretical boundaries, or
those of a single organisation, requires agreement on what project complexity is and,
most likely, what it isnt. Hopefully, the paper has dispelled some of the confusion by
separating complexity from complication and uncertainty.

Within the context of projects, complexity is considered to be an outcome of the

involvement of humans in the endeavour; which moves it beyond being complicated. An
observation made within the paper is that complexity can be added into a project through
making it more complicated than it need be, with a consequential increase in human
interaction (and, hence, increased complexity). It is suggested here that this can happen
far too easily. The reader is invited to review a project they are involved with to spot added
complication (e.g., the lack of a well-defined project mission) and determine how this has
made the project more complex (e.g., disagreement on the purpose of the project and what
its objective is).

Page 15 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009
A primary purpose for assessing the level of complexity in a project should be to help
determine the correct governance and management for the project. Determining the level,
and complexity profile, should be fundamental in determining the do-ability and
desirability.

1
PM3 is shorthand for project management, programme management and portfolio management.
2
Sensitivity to initial conditions is popularly known as the butterfly effect, so called because of the title of a
paper given by Edward Lorenz in 1972 to the American Association for the Advancement of Science in
Washington, D.C. entitled Predictability: Does the Flap of a Butterflys Wings in Brazil set off a Tornado in
Texas? The flapping wing represents a small change in the initial condition of the system, which causes a
chain of events leading to large-scale phenomena. Had the butterfly not flapped its wings, the trajectory of
the system might have been vastly different. (Wikipedia.)
3
Tim Blackman, Complexity theory and the new public management, 2001.
4
Warren Weaver, Science and complexity, American Scientist, 1948.
5
We will restrict the discussion in this paper to projects. Much of the following discussion applies to
programmes and, possibly portfolios. A follow-on paper will look at these in detail.
6
David J. Snowden and Mary E. Boone, A leaders framework for decision making, Harvard Business
Review, November 2007.
7
Scott E. Page, Uncertainty, Difficulty, and Complexity, 12th June, 1998; scotte@page.biz.uiowa.edu.
8
Claude E. Shannon, A mathematical theory of communication, Bell System Technical Journal, 1948.
Information entropy is a measure of uncertainty in a random variable; the higher the uncertainty, the larger
the entropy. In some branches of science, entropy is a measure of the disorder of a system.
9
Johnnie Moore, More Space, http://astroprojects.com/morespace/. Copyright
http://creativecommons.org/licenses/by-nc-sa/2.5/.
10
Tony Hoare, The emperors old clothes, Communications of the ACM, February 1981. ACM Turing Award
for 1980 talk.
11
Unfortunately, there are many ways of making a project more complicated. These are but a drop in the
ocean.
12
A large degree of uncertainty does not, necessarily, relate to complexity, if the uncertainty can be resolved at
an appropriate time.
13
Marilyn M. Parker and Robert J. Benson with H. E. Trainor, Information economics: linking business
performance to information technology, Prentice Hall, 1988.
14
http://www.citi.co.uk/Client_case_studies/Public-services/Remploy.
15
Other schemes can be devised. At CITI, e.g., when it is appropriate, we split organisational complexity into
organisational complexity (e.g., governance and political matters) and resource complexity (e.g., availability
of appropriate resources to activities). The Remploy case study is an example where five sources of
complexity have been used.
16
Thomas Docker, Christopher Worsley & Peter Harpum, Youve assessed your project managers. Now
what?, AIPM Conference, 2001.
17
Paul Goodwin & George Wright, Decision analysis for management judgment, 3rd edition, Wiley, 2003.
18
However, statements like, This is a very complex project could be meaningful, depending on whether or
not a method for quantifying complexity is in place.
19
Adopting Warren Weavers view of complexity, this means that complex is the opposite of independent,
while complicated is the opposite of simple.

Page 16 of 16

tel: +44 1908 28 36 00 email: CofEe@citi.co.uk

fax: +44 1908 21 88 34 web: www.citi.co.uk
CITI Limited, 2009