cov1PMJ0808.

qxd 8/9/11 11:04 AM Page 1

September 2011

Volume 42
Number 5

4 Frontinus—A Project Manager From the Roman

Empire Era
Derek Walker and Christopher J. Dart

17 Translation and Convergence in Projects:

An Organizational Perspective on Project Success
Neil Alderman and Chris Ivory

31 The Relationship Among Systems Engineers’ Capacity

for Engineering Systems Thinking,
Project Types, and Project Success
Moti Frank, Arik Sadeh, and Sharon Ashkenasi

42 Exploring PMOs Through Community of Practice Theory

Monique Aubry, Ralf Müller, and Johannes Glückler

57 Cultural Patterns Influencing Project Team Behavior in

Sub-Saharan Africa: A Case Study in Ethiopia
Fanta Tesgera Jetu, René Riedl, and Friedrich Roithmayr

78 Exploring Risk Dimensions in the Indian Software Industry

Arpita Sharma, Santoshi Sengupta, and Aayushi Gupta
cov2PMJ0808.qxd 8/8/11 12:35 PM Page 1
MISSION
The mission of the Journal is to provide infor-
mation advancing the state of the art of the
knowledge of project management. The Journal
is devoted to both theory and practice in the
field of project management. Authors are
encouraged to submit original manuscripts
that are derived from research-oriented studies
as well as practitioner case studies. All articles
in the Journal are the views of the authors and
are not necessarily those of PMI. Subscription
rate for members is $14 U.S. per year and is
included in the annual dues.
PMI is a nonprofit professional organiza-
tion whose mission is to serve the professional
interests of its collective membership by:
advancing the state of the art in the leadership
and practice of managing projects and pro-
grams; fostering professionalism in the man-
agement of projects; and advocating accept-
ance of project management as a profession
and discipline. Membership in PMI is open to
all at an annual dues of $119 U.S. For informa-
tion on PMI programs and membership:
Project Management Institute, 14 Campus
Blvd, Newtown Square, PA 19073–3299 USA; Tel:
11-610-356-4600; Fax: 11-610-482-9971; E-mail:
customercare@ pmi.org; Website: www.PMI.org;
Toll-free: 1-855-746-7879 (United States), 1-855-
746-7879 (Canada), 1-800-563-0665 (Mexico)
PMI Asia Pacific Service Centre, Singapore;
Tel: 165 6496 5501; E-mail: customercare.asia-
pac@pmi.org
PMI Europe-Middle East-Africa (EMEA)
Service Centre, Lelystad, The Netherlands; Tel: 131
320 239 539; E-mail: customercare.emea@ pmi.org;
Toll-free Numbers: 00-800-7464-8490 for Austria,
Belgium*, Bulgaria*, Czech Republic*, Denmark,
Estonia*, Finland, France, Germany, Hungary, Iceland,
Ireland, Italy, Latvia*, Lithuania*, Luxembourg,
Malta*, Netherlands, Norway, Poland, Portugal,
Russia*, Slovak Republic*, Slovenia*, Spain,
Sweden*, Switzerland, United Kingdom, Vatican
City; 00-800-4414-3100 for Cyprus, Greece; 131 320
239 539 (toll number) for Andorra, Belarus, Bosnia
and Herzegovina, Croatia, Liechtenstein,
Macedonia, Moldova, Monaco, Romania, Serbia
and Montenegro, Ukraine.
*Use the toll number (131 320 239 539) from
mobile phones in these countries.
© 2011 Project Management Institute, Inc. All rights reserved.
“PMI” the PMI logo, “Making project management indispensable for business results,” “PMI Today,” “PM Network,” “Project Management Journal,” “PMBOK,” “CAPM,” “Certified
Associate in Project Management (CAPM),” “PMP,” the PMP logo, “PgMP,” “Program Management Professional (PgMP),” “PMI-RMP,” “PMI Risk Management Professional (PMI-RMP),”
“PMISP,” “PMI Scheduling Professional (PMI-SP),” and “OPM3” are registered marks of Project Management Institute, Inc.
The PMI Educational Foundation logo and “Empowering the future of project management” are registered marks of The PMI Educational Foundation. For a comprehensive list of PMI
marks, contact the PMI Legal Department.
Editor
Christophe N. Bredillet, PhD, DSc, MBA
■ collective works, or for resale. Such permission
Publisher
Donn Greenberg; donn.greenberg@pmi.org
Wiley Executive Editor
Isabelle Cohen-DeAngelis;
icohen@wiley.com
Product Editor
Roberta Storer; roberta.storer@pmi.org
Project Management Journal Associate
Natasha Pollard; natasha.pollard@pmi.org
Publications Production Supervisor
Barbara Walsh; barbara.walsh@pmi.org
Book Review Editor
Kenneth H. Rose, PMP
Contributing Editors
Lisa M. Fisher
Linda R. Garber
■ $463.00, and rest of world, $497.00. Claims for
PMI India Service Centre, New Delhi, India;
Tel: 191 124 4517140; E-mail: (membership-relat-
ed queries): customercare. india@pmi.org
Other Locations: Beijing, China; Shenzhen,
China; Montevideo, Uruguay; Bengaluru, India;
Sydney, Australia; Porto Alegre, Brazil; Mumbai,
India; Washington, DC, USA. See www.pmi.org/
AboutUS/Pages?Customer-Care.aspx for con-
tact details.
The Project Management Journal (Print
ISSN 8756-9728); Online ISSN 1938-9507 at
Wiley Online Library (wileyonlinelibrary.com)
is published six times a year by Wiley
Subscription Services, Inc., a Wiley Company,
111 River Street, Hoboken, NJ 07030-5774.
Copyright © 2011 Project Management
Institute, Inc. All rights reserved. No part of this
publication may be reproduced in any form or
by any means, except as permitted under
Section 107 or 108 of the 1976 United States
Copyright Act, without either the prior written
permission of the publisher, or authorization
through the Copyright Clearance Center, 222
Rosewood Drive, Danvers, MA 01923; Tel: (978)
750-8400; Fax: (978) 646-8600.
The code and copyright notice appearing
on the first page of an item in the journal indi-
cates the copyright holder's consent that copies
may be made for personal or internal use of
specific clients, on the condition that the copi-
er pay for copying beyond that permitted by
Sections 107 and 108 of the U.S. Copyright Law.
The per-copy fee is to be paid through the
Copyright Clearance Center, Inc. This consent
does not extend to other kinds of copying, such
as copying for general distribution, for advertis-
ing or promotional purposes, for creating new
requests and other permission inquiries should
be addressed to the Permissions Department,
c/o John Wiley & Sons, Inc, 111 River Street,
Hoboken, NJ 07030-5774; Tel. (201) 748-6011;
please visit http://www.wiley.com/go/permis-
sions for more information.
NONMEMBER SUBSCRIPTION INFORMATION
Personal rates: For print in the US, Canada, and
Mexico, $135.00, rest of world, $159.00; elec-
tronic, all regions, $135.00; and for print and
electronic, in US, Canada, and Mexico, $150.00,
rest of world, $174.00. Institutional rates: For
print in the US, $365.00, in Canada and Mexico,
$405.00, and rest of world, $439.00; electronic,
all regions, $365.00; and for print and electron-
ic, in the US, $423.00, Canada and Mexico,
undelivered copies will be accepted only after
the following issue has been received. Please
enclose a copy of the mailing label or cite your
subscriber reference number in order to expe-
dite handling. Missing copies will be supplied
when losses have been sustained in transit and
where reserve stock permits. Please address all
subscription inquiries to Subscription Manager,
Jossey-Bass, A Wiley Imprint, 989 Market Street,
5th Floor, San Francisco, CA 94103-1741; Tel. (888)
378-2537, (415) 433-1767 (International);
E-mail: jbsubs@jbp.com.
Postmaster: Periodical postage paid at
Newtown Square, PA 19073 USA and at addi-
tional mailing offices. Send address changes to
Project Management Journal Subscription
Distribution U.S., c/o John Wiley & Sons, Inc.,
111 River Street, Hoboken, NJ 07030-5774.
Reprints: Reprint sales and inquiries should
be directed to the Customer Service Department,
Gale Krouser, c/o John Wiley & Sons, Inc., 111
River Street, Hoboken, NJ 07030-5774; Tel: (201)
748-8789; Fax: (201) 748-6326; E-mail:
gkrouser@wiley.com.
MANUSCRIPTS
All manuscripts must be submitted electronically
via the journal’s Manuscript Central site
(http://mc.manuscriptcentral.
com/pmj). Questions regarding submission
guidelines and manuscript status should be sent
to Natasha Pollard (natasha.pollard@ pmi.org).
All manuscripts submitted to the journal via
Manuscript Central are assumed for publica-
tion and become the copyright property of PMI
if published.
cov3PMJ0808.qxd 8/8/11 12:36 PM Page 2
cov4PMJ0808.qxd 8/8/11 12:37 PM Page 2
 Project Management Journal ■ Volume 42, Number 5 ■ September 2011
Page 1
12:38 PM
8/8/11
spinePMJ0808.qxd
01PMJ0808.qxd 8/8/11 12:13 PM Page 1

September 2011
Volume 42, Number 5

The Professional Research Journal of the Project Management Institute

2 From the Editor

Christophe N. Bredillet, PhD, DSc, CASR 3PM, Dakar, Senegal

PAPERS
4 Frontinus—A Project Manager From the Roman Empire Era
Derek Walker and Christopher J. Dart

17 Translation and Convergence in Projects: An Organizational Perspective on Project Success

Neil Alderman and Chris Ivory

31 The Relationship Among Systems Engineers’ Capacity for Engineering Systems Thinking,
Project Types, and Project Success
Moti Frank, Arik Sadeh, and Sharon Ashkenasi

42 Exploring PMOs Through Community of Practice Theory

Monique Aubry, Ralf Müller, and Johannes Glückler

57 Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa:

A Case Study in Ethiopia
Fanta Tesgera Jetu, René Riedl, and Friedrich Roithmayr

78 Exploring Risk Dimensions in the Indian Software Industry

Arpita Sharma, Santoshi Sengupta, and Aayushi Gupta

92 Cover to Cover—Book Reviews

Kenneth H. Rose, PMP

96 Erratum
02-03PMJ0808.qxd 8/8/11 12:14 PM Page 2
From the Editor
Christophe N. Bredillet, PhD, DSc, CASR 3PM, Dakar, Senegal
In this issue of the Journal, articles presented to the read-
ers cover project management practices throughout histo-
ry (“Frontinus—A Project Manager From the Roman
Empire Era,” Walker and Dart), project success and failure
revisited through integrated theoretical lens on the one
hand (“Translation and Convergence in Projects: An
Organizational Perspective on Project Success,” Alderman
and Ivory) and, on the other hand, with a focus on systems
engineers’ capacity for engineering systems thinking
(“The Relationship Among Systems Engineers’ Capacity
for Engineering Systems Thinking, Project Types, and
Project Success,” Frank, Sadeh, and Ashkenasi), project
management offices (PMOs) investigated through com-
munity of practice theory (“Exploring PMOs Through
Community of Practice Theory,” Aubry, Müller, and
Glückler), influence of cultural patterns on project
team behavior (“Cultural Patterns Influencing Project Team
Behavior in Sub-Saharan Africa: A Case Study in Ethiopia,”
Jetu, Riedl, and Roithmayr), and human factors and differ-
ences of perception and their impact on risk management
(“Exploring Risk Dimensions in the Indian Software
Industry,” Sharma, Sengupta, and Gupta).
Walker and Dart draw a comparison of some project
management approaches and practices between Roman
times and today in order to address three research ques-
tions: (1) Have the best project management practices
for initiating, funding, and implementing infrastructure
projects changed fundamentally over the past 2,000
years? (2) If so, in what ways? (3) What implications may
this have for current project management practices? The
analysis, using a case study approach based on infra-
structure project, focuses on three roles: project manag-
er, project sponsor, and champion. The authors conclude
that if some practices are still used today, such as project
funding, decision making, and outsourcing of labor,
some techniques and approaches have changed due to
changes in culture and technology such as knowledge
transfer and legal frameworks. The authors conclude in
providing some useful insights about the nature of
changes to project management practice that may be
expected during this century, in particular in the areas of
strategic orientation, procurement approach, leadership
enhancing commitment, dispute resolution, and co-
knowledge creation between client and contractor.
Project Management Journal, Vol. 42, No. 5, 2–3
© 2011 by the Project Management Institute Published online in
Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/pmj.20267
2 September 2011 Project Management Journal ■ DOI: 10.1002/pmj
Starting with the assessment that the increasing
complexity of the project management context has led
to rethinking the way in which projects are managed and to
the search for new concepts and theories, Alderman and
Ivory present some new thinking while focusing on the
complex social and political aspects of managing proj-
ects. In order to develop new models of project manage-
ment processes and to discuss project success and
failure in an innovative perspective, the authors integrate
a range of theories (actor-network theory, multi-nodality,
and sense making). Building on the theoretical corpus,
the authors argue that success and failure can be character-
ized in terms of a continuum between project convergence
and divergence. With the support of the above theories, the
causes of divergence and convergence are discussed using
four illustrative case studies (Millennium Dome, Eden
Project, Heathrow Terminal 5, and The Scottish
Parliament Building). The discussion of these cases leads
the authors to formulate some suggestions to managers
of complex projects seen as networks: (1) clear, consis-
tent, and stable vision from the outset; (2) encourage-
ment for convergent, organic organizations; and
(3) identifying and acting on likely points of divergence.
Frank, Sadeh, and Ashkenasi turn their attention to
the issue that, despite the fact that systems engineering
and Project Management Bodies of Knowledge have
been rapidly growing in recent years, about two thirds of
all projects still fail. Investigating some possible reasons
for this situation, and after an in-depth review of the lit-
erature of both project management and systems engi-
neering publications, the authors observe that most of
the works focus on processes. They suggest focusing on
people—project managers and systems engineers.
Building on their previous researches, the authors
explore the relationship among systems engineers’
capacity for engineering systems thinking (CEST), proj-
ect types, and project success. This quantitative research
is based on a self-report questionnaire, composed of three
parts: (1) the participants’ CEST assessment, (2) several
measures of project success assessment, and (3) four
dimensions of project type assessment (based on NTCP
framework). The data collected are from 114 senior sys-
tems engineers randomly selected from the sampling
frame. The findings suggest that there is a statistically
02-03PMJ0808.qxd 8/8/11 12:14 PM Page 3
significant positive correlation between CEST and proj-
ect success, and that this relation is moderated positive-
ly by a project’s novelty, complexity, and technological
uncertainty (for instance, the more the project is innova-
tive, the higher the correlation between subjects’ CEST
and project success).
In the context of the internationalization of business
with services or products that are developed, managed,
or supported in multiple countries, multinational and
national organizations compete in a global market.
Making more with less is a source of competitive advan-
tage, and, to this regard, reuses good practices, supports
innovative practice, and prevents the reinvention of the
wheel and the associated loss of value (cost and time
to market). This is one reason why the so-called “knowledge
economy” emphasizes mechanisms to share knowledge. If
knowledge management is a challenge for permanent
organizations, it is an even greater one for project-based
organizations due to their temporal dimension. In their
paper, Aubry, Müller, and Glückler investigate the role of
project management offices (PMOs) in knowledge shar-
ing and learning through community of practice theory.
Thus this paper takes a new theoretical stance and brings
some valuable insights to the role of PMOs in knowledge
management. The research relies on a national health
care in-depth case study. Preliminary findings are used to
confirm the relevance of this approach. The authors sug-
gest a framework to explore the learning mechanisms
within the PMOs’ communities of practice. This explo-
ration led them to discuss key concepts such as commu-
nities and practices, network of practice, community of
PMOs and PMOs in transition, variety of communities
of PMOs and cultural influence.
The human element is recognized as a key factor to
project success. Papers about cultural impact are raising
increased attention as well. Reviewing the literature,
Jetu, Riedl, and Roithmayr show that empirical studies
about the influences of cultural patterns on human
element—and especially project team behavior—are not
well developed or satisfactory. Since Ethiopia, the sec-
ond largest population in Sub-Saharan Africa, intro-
duced a market economy in 1991, the government has
conducted a number of reform packages involving major
changes projects. Thus, the research relies on an in-
depth case study conducted in Ethiopia’s service sector.
The authors consider here project team behavior, and
besides the well-perceived cultural values commonly
referred to in the existing literature, the authors analyze
the deep-rooted underlying causes, which include
Ethiopian cultural habits, as a main factor influencing
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
project team behavior. They conclude that cultural
habits related to team relationship, team learning, and
team working have the most influence on project team
behavior, and this has a significant and direct effect on
project success. Nevertheless, the authors raise that the
validity of inference and the conclusion derived from
this study are affected by a number of other factors that
have not been considered in the research, external fac-
tors beyond team control for instance. The authors con-
clude the paper suggesting some recommendations for
improving the management of teams by being more
conscious of the role of cultural habits and modifying
some of them.
It is widely recognized that the success of software
projects is quite subjective in nature and is fettered by
many risks. But the perception of risks and of their level
may vary from individual to individual and is also
dependent on the characteristics of the executives and
the project. Furthermore, the Indian software industry is
characterized by the diversity of the projects: from size to
complexity and from scope to criticality, “in-house” or
outsourced, number, and type of stakeholders. In this
context, which is particularly relevant and understudied,
Sharma, Sengupta, and Gupta aim to evaluate the vari-
ous risk dimensions across a number of demographic
characteristics of software practitioners and also aim to
study the variance in risk dimensions among the various
project characteristics handled by software practition-
ers. An important by-product of the paper is that it helps
to understand the perception of the team vis-à-vis mid-
dle management and top management in the specific
context of the research. On the basis of a pilot study, this
quantitative research has led to the design of a survey
listing 23 risks affecting the software development life
cycle. A total of 32 companies were surveyed and 300
valid questionnaires were collected. The authors identify
four main general risk factors (software requirement
specification variability risk, team composition risk,
control processes risk, and dependability risk) and dis-
cuss their perception among middle and top manage-
ment. The results show a difference in the perceptions
(based on personal attributes and project attributes)
toward these risk dimensions, whereas top management
perceives these risks to be more controllable and having
less impact on the success of the project compared with
the perception of middle management.
Enjoy reading this Journal issue.
Ordo ab chaos
Christophe N. Bredillet
3
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 4
PAPERS
Frontinus—A Project Manager From
the Roman Empire Era
Derek Walker, RMIT University—Department of Property, Construction
and Project Management, Melbourne, Victoria, Australia
Christopher J. Dart, The University of Melbourne, The School of Historical
and Philosophical Studies, Melbourne, Victoria, Australia
ABSTRACT ■
We compare selected project management
practices undertaken almost 2,000 years ago
with current literature on best project manage-
ment practice. We take a case study approach
focusing on a person who could be seen to have
taken a project manager, project sponsor, and
champion role. We suggest that some project
management approaches used in Roman times
are routinely used today; however, changes in
the culture and technology have transformed
possibilities for project management tech-
niques, and so changed approaches are
inevitable. The paper provides useful insights
about the nature of changes to project manage-
ment practice that may be expected during this
century.
KEYWORDS: project management; history;
culture
Project Management Journal, Vol. 42, No. 5, 4–16
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20253
4 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
INTRODUCTION ■
everal project management authorities cite ancient civilizations as
S having practiced a form of project management while developing the
great building and infrastructure projects of antiquity. For instance,
Morris (1994, p. 4) discusses the example of the Great Wall of China
and traces project management work being undertaken in a rudimentary
form back beyond the Romans to early civilizations such as the Egyptians,
who built the pyramids and magnificent urban structures such as temples,
administration palaces, and the like.
While in some cases the physical remains of these ancient structures
have been preserved, it is also through source materials (e.g., ancient litera-
ture, papyri, clay tablets, inscriptions, and relief artwork) that we have been
provided with evidence of accounting information, administrative orders,
and other instructions that suggest an orderly, planned, and somewhat coor-
dinated approach to project management in antiquity. In some instances,
modern archaeological work has also revealed much about the social status
and conditions of those who carried out the labor. It is apparent that tradi-
tional skilled trade information and knowledge have enabled these struc-
tures to be designed and built, which suggests a kind of project management
approach that may be familiar to today’s project managers. Unfortunately,
ancient source material is often damaged, fragmented, or entirely lacking,
in some cases requiring much reconstruction work to be performed by
modern-day scholars.
The Romans, like many other major ancient civilizations, undertook
complex, large-scale infrastructure projects. While project management
functions took place, they were not necessarily understood and described as
such by the Romans. Furthermore, the technologies and project manage-
ment approaches used were often learned or adapted from other societies.
For the study of the Roman world (in some periods), there is a rich collection
of source material that has been preserved. While scholars dealing with
source materials from the Roman Empire must still confront the same
obstacles of badly fragmented or incomplete documentation, several factors
make the Romans a particularly appropriate topic for a project management
case study. First, there is an extensive body of literature on the Roman
Empire that has survived, and some of these texts are almost entirely intact.
So too, centuries of the intensive work of historians, philologists, numisma-
tists, epigraphers, and archaeologists have resulted in an extensive corpus of
Roman law codes, judicial decisions, public contracts, and many other doc-
uments relevant to a study of Roman project management practices. Thus,
the Roman experience of project management offers one of the most reliable
and potentially valid insights into project management in antiquity.
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 5
In this article, we base our study
on a surviving treatise by a late first-
century Roman official, the De
Aquaeductu, by Sextus Julius Frontinus.
This text, which dates back to the year
97 CE,1 describes in detail the manage-
ment of the sophisticated network of
aqueducts that supplied daily running
water to approximately one million
inhabitants of the city of Rome. The
treatise’s survival means that we are
provided with a unique insight into
the management of a very important
piece of Roman public infrastructure in
the first century CE.
The evolution of project manage-
ment has occurred over the centuries
and, by using a distant historical case
study, we can explore the ways that
project management has changed, the
reasons for these changes, and what
changes may be expected in the future.
As such, this article focuses less on the
physical infrastructure and artefacts of
Roman aqueducts (or, for that matter,
the roads, temples, and fortifications)
and more on the decision-making
processes that were evident in
conceiving and managing these pieces
of infrastructure.
The Romans were not the first to
develop great infrastructure projects.
Large-scale urban centers were
developed in Egypt and the Near East
in the third millennium BCE. The
Romans also gained much of their
knowledge and technology from the
Greeks, who adapted their project man-
agement knowledge from an historical
flow of knowledge transfer between the
peoples of Mesopotamia, Northern
Africa, and Persia. In turn, the Romans
were very good adapters, and their
influence was widely felt around
the Mediterranean—from England to
Mesopotamia and from the Sahara
to Northern Europe. Much of their
1 We use the correct historical terms for measuring time—
that is, CE, or common era, and BCE, or before the com-
mon era, which are also known as in the year of our Lord
(i.e., Anno Domini, or AD) and before Christ (BC), respec-
tively.
infrastructure development is more vis-
ible to us today, so our perception of the
feats of project management is more fine-
ly honed by this legacy from the
Mediterranean world. Fortunately,
the historical records from Roman times
are rich and varied, and this period in his-
tory has been studied extensively over
the centuries; so we have reasonably
reliable evidence to work with when
evaluating what transpired in those
times compared with today’s project
management practices. In looking at
the processes of realizing Roman-era
infrastructure projects, we can draw
heavily upon the well-established theo-
ry, archaeological, literary, and meta-
analyses from centuries of scholarship.
The research questions posed in
this article are as follows:
1. Have the best project management
practices for initiating, funding, and
implementing infrastructure projects
changed fundamentally over the past
2,000 years?
2. If so, in what ways?
3. What implications may this have
for current project management
practices?
The first author has a practical proj-
ect management perspective, gained
from studying project management
at the doctoral level as well as having
significant project management prac-
tice experience on large construction
projects. The second author is an
ancient historian who specializes in the
social and institutional history of the
Roman world. This means that we can
explore the project management per-
spectives of a Roman case study, using
someone who we might recognize even
now as a project manager, even though
this individual lived 1,900 years ago.
The valuable historical insights this
article contributes to the understand-
ing of project management focuses on
the following:
• the manner in which the originating
mandate for the project was devel-
oped and the management options
for undertaking such projects;
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
• management processes undertaken
in terms of organizational structure,
planning, and control tools;
• resourcing of projects; and
• the political process of project stake-
holder engagement.
We used a case study that focuses
on the lived experience of Frontinus, a
person we recognize as an early exam-
ple of an “accidental” project sponsor
and manager. An accidental project
manager is one who has been thrust
into the role with little or no training,
development, or explanation of what
the role requires (Graham, 1992; Pinto &
Kharbanda, 1995).
The remainder of this article is
structured as follows. First, the type of
case study project is established. Next,
the historical context of the Roman
Empire in determining the rationale
for its projects is briefly summarized
by providing historical facts that allow
readers to understand why infrastruc-
ture projects were necessary; the force
of authority that sanctioned such
projects and the chain of decision
making that led from the project’s
inception (its perceived need) through
to its business case development and
gateway processes, which in turn led
to its sanctioning, design, and deliv-
ery. These steps are followed by a brief
description of the case study project,
which sets its needs and delivery
record within the contemporary con-
text of the needs of the Roman
Empire. The next section focuses on
the cultural milieu and the forces at
play between the project stakehold-
ers. This helps to clarify authority and
accountability lines so that we can
better understand the pressures and
drivers exerted on by the person we
can identify as the project sponsor
and project manager for the case
study project. This is then compared
with contemporary exemplar stan-
dards drawn from the current project
management literature. Conclusions
that address the research questions
follow.
5
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 6
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
The Case Study Project
Manager—Frontinus, Project
Manager for the Aqueducts
of the City of Rome
(Late First Century CE)
Turner and Cochrane (1993) identify
four types of projects based on using a
four-quadrant model of methods with
an axis of well-defined goals and
another of well-defined methods.
Engineering projects, or “earth” proj-
ects, have both well-defined goals and
methods. These types of projects are
typically initiated by a client to fulfill a
particular need, and the project man-
ager oversees the refinement of the
needs analysis stage transitioning into
design, procurement, and realization.
Early published project case studies
typically cite construction, shipbuilding,
aerospace, and manufacturing projects
as examples of projects because they
attract a “scientific” view of operations
management influence (Morris, 1994;
Morris & Hough, 1993). The Roman
case study project described in this
article is a traditional project manage-
ment “engineering” type of project.
It would be easy to hypothesize that
not much has changed between the
case study about the Roman Empire of
the late first century CE and today—
other than that there have been obvious
changes in technology and attitudes
toward authority and leader/follower
interactions. The differences are, how-
ever, illuminated by the comparisons of
the case study with current project
management practices for similar con-
temporary projects. This allows us to
appreciate the impact of any shifts in
project management approaches on
the contemporary practices for this
kind of project.
Ancient history presents particular
methodical obstacles that have
informed the choice of subject.
Naturally we could not interview any-
one who witnessed how the project
may have been managed during the
Roman Empire times but because
Frontinus left the legacy of his book, we
were able to use this as a useful source
6 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
of research data, along with other his-
torical data. Source material from the
Roman world has survived sporadically,
and the principal data sources are:
• literary sources: textual sources (e.g.,
Livy, Cicero, and Frontinus) that
describe the legal and political
processes for initiating projects,
assigning funds, and making officials
accountable;
• inscriptions: some preserved public
contracts, along with the names of the
contractors and the costs assigned for
each task, as well as milestones and
other official markers, which have
preserved some of the names of the
responsible magistrate(s); and
• archaeology: the physical remains of
some infrastructure projects have sur-
vived into the modern era or have
been excavated; specifically, numer-
ous sections of roads, bridges, and
aqueducts have been preserved.
In 97 CE, Sextus Julius Frontinus
was appointed to the post of curator
aquarum (superintendent of the aque-
ducts supplying the city of Rome). In
the late first century CE, this was a pres-
tigious post that was outside of the tra-
ditional military magistracies. Holders
of the office were recommended by the
emperor to the senate, which then
formally approved the appointment.
The curator bore the principal respon-
sibility of ensuring the delivery and
operational aspects of the supply of
fresh water to Rome, the most populat-
ed city in the preindustrial world. What
is unusual about Frontinus is that,
among all the other men who had held
this position, he was the only one
known to have written a manual on the
curatorship, detailing the operation
and management of the city’s aque-
ducts. His manual has survived and
provides a unique insight into the man-
agement of Roman public infrastruc-
ture (Peachin, 2004, p. 12f.) in the first
century CE and, as such, provides much
of our data for analysis.
Frontinus was born circa 35 CE,
probably in southern Gaul. He held a
number of public offices during his life:
he was praetor of the city of Rome in
70 CE, held his first consulship in 72–73
CE, was governor of Britain between
the years 73 and 74 CE and 78 CE, was
the proconsul of Asia in 86 CE, was the
curator aquarum in 97 CE, and held
the consulship twice again in 98 and
100 CE (Bruun, 2007; Ward-Perkins,
1937). Over the course of Frontinus’ life,
the Romans conquered Britain, the
eruption of Vesuvius buried Pompeii
and Herculaneum, and the future
emperor, Titus, destroyed the temple of
Jerusalem.
During the era of Rome’s first
emperor, Augustus, the emperors built
up an increasingly large civil adminis-
tration. Augustus may have been
responsible for the introduction of a
number of other curatorships, in par-
ticular those responsible for public
buildings and for regulating the flow of
the Tiber River (Badian, 1996). The
gradual expansion of this administra-
tion was advantageous to many citizens
of equestrian status2 from the provinces,
furnishing men with a means to social
advancement through managing the
increasingly vast infrastructure of
the empire.
By 97 CE, when Frontinus was cura-
tor aquarum, the city of Rome had
numerous officials in charge of issues
of public concern, such as mainte-
nance of the Tiber River, organizing the
publicly funded corn supply, the main-
tenance of aqueducts and public build-
ings, the city cohorts, and the vigiles
(i.e., city firefighters). In the provinces,
imperial administrators were primarily
concerned with fiscal matters, while
the day-to-day administration of the
provincial cities was typically left to
the local elites. Italian and provincial
towns also had their own officials who
tended to the local water supply. In the
small city of Tibur, a short distance
2This status constituted the lower of the two aristocratic
classes of ancient Rome, ranking below the senatorial
order. These would later be considered throughout Europe
as “knights” in later medieval times.
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 7
from Rome, inscriptions indicate that,
at one time, there was an official called
a tribunus aquarum and another offi-
cial called a praefectus rivi supernatis
(Mommsen, CIL, 14.3674 and 3682).
Similarly, in Egypt, a preserved papyrus
provided details about the accounting
of income and expenditure made by
local water commissioners in the town
of Arsinoë (Hunt & Edgar, no. 406).
The surviving text of Frontinus con-
sists of a preface and two books. The
work has been recognized (at least as
early as the Renaissance) as a valuable
manual on the management of the net-
work of aqueducts supplying Rome and
was used by both papal engineers
and administrators who maintained
the city’s ancient infrastructure as late
as the 1600s (Bruun, 2008). The first
book deals with aspects identified by
Frontinus as pertinent matters for the
management of the aqueducts of
Rome (Frontin. Aq. pref. 3) and outlines
the construction of each aqueduct in
chronological order. For each aque-
duct, Frontinus provides an explana-
tion of the magistrate or magistrates
responsible for the initial construction,
the original rationale for construction,
and where the aqueducts began in rela-
tion to their distance to landmarks such
as roads and rivers. For the most part,
his measurements were up to date and
based on the contemporary road sys-
tem (Evans, 1993, p. 450). He then
describes the aqueduct courses, what
distances were laid underground,
which parts were constructed above
ground, and where the aqueducts
began to discharge into the city
(Frontin. Aq. 1.5–15). This summary
concludes with the observation:
With such an array of indisputable
structures carrying so many waters,
compare, if you will, the Pyramids
or the useless, though famous,
works of the Greeks. (Frontin. Aq.
1.16)
Frontinus then proceeds to des-
cribe the aqueducts in terms of their
relative elevations at entries into the
city (Frontin. Aq. 1.18) and describes
the basins for removing sediment and
gauges for measuring volume (Frontin.
Aq. 1.19–22). The remainder of book
one explains the detailed system of
measuring the operation of the aque-
ducts (Frontin. Aq. 1.23–63). Book two
outlines the discrepancies between the
operation statistics that Frontinus
inherited and (what he claims to be) the
actual measures he reached during his
administration. There is a discussion
about the different forms of system
fraud and the legal frameworks within
which the curator operated.
In his introductory remarks,
Frontinus identifies three aspects he
believes concern the office of curator
aquarum: usage (usum), health
(salubritatem), and security (securi-
tatem). He further explains that, having
been appointed to this important
office, he deemed it necessary to first
familiarize himself with the task by
writing the manual.
He explicitly stated that the work
was produced at the beginning of his
administration, primarily for his own
use, although he conceded that his
work might be of assistance to future
men in the post. These statements
undermine recent attempts to infer
hidden agendas in Frontinus’ work. In
particular, Peachin (2004) has argued
that Frontinus wrote the manual in
order to convince the senatorial elite to
desist from illegal tapping of the water
system, Bruun (2007) has succinctly
refuted such a limited interpretation of
Frontinus’ motivations, and Rodgers
(2004, pp. 8–12) has correctly noted a
range of possible motives.
In the preface, Frontinus sets out
his principles for the management of a
public office:
I believe that there is no surer foun-
dation for any business than this
[knowledge of one’s own job], and
that it would be otherwise impossi-
ble to determine what ought to be
done, what ought to be avoided;
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
likewise that there is nothing so dis-
graceful for a decent man as to con-
duct an office delegated to him,
according to the instructions of
assistants. Yet precisely this is
inevitable whenever a person inex-
perienced in the matter in hand has
to have recourse to the practical
knowledge of subordinates. . . . they
are, as it were, but the hands and
tools of the directing head. (Frontin.
Aq. pref. 2)
Frontinus relates his principle that
those tasked with the primary responsi-
bility of a job should possess practical
knowledge about the task. He asserts
that managers should only delegate
physical and/or operational tasks to
subordinates; all decision making
should be performed by the individual
with the principal responsibility.
This is interesting in project man-
agement terms because it implies that a
project was identified to satisfy a par-
ticular need or benefit (in this case, the
supply of fresh water), which entailed
procuring the project, overseeing its
realization, and then taking responsi-
bility for the utilization of the project’s
infrastructure. This entailed a program
of work (projects) that included identi-
fying and justifying the business case
for the initial development of the infra-
structure, its procurement, and then its
operation. The responsibility extended
to ensuring the supply of fresh water,
rather than just building an aqueduct,
because the curator was also responsi-
ble for overseeing the ongoing opera-
tion. Setting aside any program
management issues, we can still learn
much about how the historical and
archaeological records allow us to
understand how the physical aqueduct
infrastructure project was initiated,
developed, and maintained (Evans,
1994).
Frontinus recognized that his posi-
tion did not merely involve the obvious
engineering responsibilities of ensur-
ing the day-to-day operation and
ongoing oversight of maintenance and
construction, but also that success or
7
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 8
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
failure had potential social and political
ramifications:
[The Emperor] has laid upon me the
duties of water commissioner, an
office which concerns not merely
the convenience but also the health
and safety of the City, and which has
been administered by the most emi-
nent men of our state. (Frontin.
Aq. pref. 1)
Comparing the Historical
Context of Infrastructure
Projects in the Roman World
With Contemporary Issues
Roman history is typically divided into
two basic eras: the Roman Republic
(from 509 BCE to 28 BCE), a period in
which the Roman state was run by a
plutocratic oligarchy, and the Imperial
Era (from 28 BCE to the collapse of the
Western Empire), a period in which the
state was dominated by the rule of one
or more emperors. Understandably,
over such a long period, massive social,
political, and constitutional changes
took place, the most momentous being
the shift in the first century BCE toward
sole rule. This extended period also nat-
urally led to changes in the approaches
to project management as the sociopo-
litical and socioeconomic climates
changed. This raises interesting gover-
nance issues beyond the scope of this
article, but some are touched on where
relevant to the focus of project manage-
ment during this era. Crouch (1993) has
argued that the increasing knowledge
about and advances in water manage-
ment went hand in hand with the grow-
ing ability of the Greco-Roman world to
build larger and more complex urban
environments.
The majority of substantial infra-
structure projects, under both the
Roman Republic and then under
the emperors, were either undertaken to
provide basic public services (e.g., aque-
ducts, ports, public spaces, and sewers)
or to serve military purposes (e.g., walls,
roads, and ports). Some of the main
characteristics of these projects were:
security was a prime consideration,
8 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
whether these projects were of a mili-
tary or civilian nature; entertainment,
social, and cultural venues (e.g., tem-
ples and baths) were often privately
funded; the benefits of projects to local
economic activity and trade were typi-
cally considered secondary to the pro-
vision of a specific service; facilitating
the efficient movement of food and
water was a prime concern for the state
because plague, famine, and food riots
were common throughout Roman his-
tory; and, finally, the delivery of proj-
ects of public significance was an
important means of asserting personal
social status.
Sources of Funds
At the most basic of levels, there were
three sources of funding for potential
projects: public finances, private bene-
faction, or imperial benefaction. The
emperors typically had their own per-
sonal fortunes, which could be spent on
specific projects, or an emperor could
indirectly use public funds (typically
acquired through warfare or taxation).
For most curators, the principal sources
of funds were either the aerarium (the
state treasury) or local cities (Eck, 2003).
The Roman military consisted of
approximately one quarter of a million
men and was the single largest item of
the state’s expenditure. Frequently,
major public works were paid for by the
state from the proceeds of war. The first
major infrastructure projects undertak-
en by the Romans occurred soon after
Rome became the dominant power in
the fourth century BCE in Italy. In 312
BCE, the Roman state began its first two
major infrastructure projects in Italy: a
highway that ran from Rome to the
southern Italian city of Capua and an
aqueduct that brought spring water into
the city of Rome (Livy, 9.29). Similarly,
the Colosseum in Rome and a number of
other works were paid for by the
Emperor Vespasian with funds acquired
through his wars in the East (Suetonius,
Ves. 9 and 17). There was a long-standing
Roman tradition of constructing tem-
ples and other monuments from the
proceeds of war to commemorate the
successful completion of campaigns.
There are numerous examples of
private benefaction within local com-
munities, both throughout Italy and in
the provinces. While many cities in
the Empire had Roman citizenship, the
local community, and in particular
the local elite, were expected to finance
many regional projects. Emperors
sometimes funded large-scale regional
projects, such as Hadrian’s substantial
works in the city of Athens (Ridley, 1987,
p. 484) or Antoninus Pius’s disaster
relief in Asia Minor (Huttl, 1933/1973;
Ridley, 1987, pp. 498–499).
The above illustrates that projects
were financed for a variety of reasons,
and sources of funding came from the
state, private individuals, and purloined
resources from conquered regions.
Securing funding was a strategic deci-
sion.
Reasons for Projects—Making
the “Business Case” the Rationale
Roman officials were unpaid and
worked for the personal and familial
prestige that was attached to public
office. In the cases of the aforemen-
tioned aqueduct and highway, which
began construction in 312 BCE, in
accordance with the traditions of the
Roman Republic, these projects were
named after the magistrate who over-
saw their completion; in this instance,
the censor Appius Claudius, gave these
pieces of infrastructure the names via
Appia and aqua Appia. Similarly,
Roman laws typically took the name of
the magistrate who proposed them;
thus, a law passed by Gaius Julius
Caesar might be called the lex Iulia.
This practice demonstrates an impor-
tant motivation for undertaking proj-
ects. Competition for the preservation
and/or enhancement of public prestige
was an important concern for the
Roman elite. Attaching one’s name to
an important piece of public infrastruc-
ture would positively enhance the
personal prestige of an individual and
his or her descendants.
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 9
The delivery of both publicly and
privately funded projects was an
important means of both establishing
and maintaining social status among
members of the leading families—
initially in Italy, but increasingly under
the Empire in many parts of the Roman
world.
The public projects built under the
auspices of the emperor himself
enhanced his prestige and also overtly
advertised the beneficial nature of his
rule. In the case of the curatores
viarum, although their principal duties
were overseeing the maintenance and
construction of roads, the builder was
always identified as the emperor on the
surviving milestones and inscriptions
(Eck, 2003). More broadly, this principle
is demonstrated by the fact that such
projects were frequently “advertised” to
the public on coinage carrying the
emperor’s image. In turn, with most
public offices tacitly or overtly overseen
by the emperor, the success or failure in
any office had very real consequences
for the future opportunities for
advancement of the official in question.
In this sense, “project success” can be
seen to be viewed by the Romans more in
terms of long-term success in which suc-
cess of the firm (family) and the potential
for opening up future ventures occurs.
These days, many project managers tend
to be mainly judged based on “iron trian-
gle” measures of project efficiency. There
is less emphasis on how the project out-
come contributes to customer benefits,
long-term benefits delivered by the proj-
ect, its contribution to business sustain-
ability (Shenhar, Dvir, Levy, & Maltz,
2001), or even how vanguard projects
can establish a firm on an innovative
new business trajectory (Brady & Davies,
2004). There are some interesting paral-
lels with the value propositions for
projects back then and the kinds of argu-
ments made in a “business case” today.
Decision Making and
Accountability
The position of the curator aquarum
was established by a decree of the senate
in 11 BCE (Frontin. Aq. 2.99), but the
curator was nominated by the emperor
and was intended to act as the emperor’s
administrative agent. Responsibility for
decision making rested with the official
in charge. The curator was responsible
for determining the division of the nec-
essary work and overseeing the tender
process for any contractors as required.
This person bore personal responsibility
for all the decisions and could be liable
for prosecution after the term of office
had been completed if it was believed
that the curator had acted improperly or
illegally. This is quite clearly reflected in
Frontinus’ belief that there should be
“one head and many hands.” This relates
to the concept of a project manager
being the single point of contact for proj-
ect management matters (Project
Management Institute [PMI], 2004).
Frontinus described a close work-
ing relationship between himself and
the emperor (Rodgers, 2004). As an
imperial appointee and also a member
of the consilium principis (the inner
circle of senior men advising the
emperor) (Crook, 1975, p. 53), such a
relationship was not unexpected. The
consilium principis was an advisory
body to the emperor that eventually
assumed an important role in the gov-
ernance of the empire and typically
consisted of a small number of both
family members and close allies of the
emperor (Crook, 1975) who had an
influence on imperial decision making.
This also relates to the role of “project
champion,” the person who provides
high-level political support for proj-
ects, and a project sponsor who may
champion a project but also provides
support at a high level of corporate
leadership to support adequate
resourcing for the project (Englund &
Bucero, 2006; Helm & Remington,
2005; Kloppenborg, Tesch, Manolis, &
Heitkamp, 2006). Furthermore, this
focus on political relationships links to
the practice of stakeholder engage-
ment for those stakeholders that have
critical and influential impact on
the provision of resources and political
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
support (Bourne, 2005; Bourne &
Walker, 2003, 2005).
Labor and Outsourcing
One of the primary duties of a curator
was overseeing the distribution of con-
struction work to private contracts
(Eck, 2003). When originally established
in 11 BCE, the curator aquarum had
240 state-owned slaves at his disposal;
this number was increased to 460 by
the emperor Claudius in the mid-first
century CE (Eck, 2003). While these
slaves were used for incidental mainte-
nance and for ensuring the daily water
supply, all large construction projects
were given to private contractors
(Rodgers, 2004, p. 265f), which was the
standard Roman state practice at
the time. Roman magistrates typically
had access to a staff of publicly owned
slaves (Mommsen, 1887, p. 320f) and
advisors. Outsourcing most mainte-
nance and construction work to private
companies was also normal. State offi-
cials were regularly responsible for
awarding contracts and then ensuring
that they were fulfilled according to the
terms agreed upon. This has a modern
equivalent in the project management
and procurement literature (Bröchner,
2006; Fill & Visser, 2000; Quinn &
Hilmer, 1994; Walker, Stark, Arlt, &
Rowlinson, 2008).
One such example of the process
for tendering public contracts is
provided by an inscription, which pre-
serves a public contract for the main-
tenance of the Via Caecilia (one of the
great highways of Roman Italy) during a
period between 90 and 80 BCE (ILS,
p. 5799). The inscription records that
the urban quaestor had engaged a
number of contractors to complete sec-
tions of the project. The quaestor and
each of the individual contractors are
named as personally responsible for
the completion of each task. The dis-
tance and the nature of the work are
specified for each contractor, with a
specific cost assigned for each. The
rationale for making this inscription
was that it served as a public statement
9
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 10
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
of what had been contracted, because
this was part of the process of ensuring
public accountability. The project man-
agement literature provides many
examples of the need for accountabili-
ty, transparency, and governance to
assign responsibilities to parties (PMI,
2004) and to administer contracts
(Winch, 2001).
Knowledge Transfer
As Frontinus alludes to, the former
holders of the position of curator had
not undertaken comparable research
on the operation of the aqueduct
system. Roman officials were neither
expected to have formal training nor
needed to provide evidence for their
competency to perform a task. Under
the Republic, campaigning for office
was a serious political activity; however,
from the period of Augustus onward,
the emperor exercised control of public
office through the “nomination” of can-
didates who were then duly elected.
This said, it should also be noted that
incoming curators did have access to
both the pool of state-owned slaves
and specialists, such as engineers and
clerical assistants (Frontin. Aq. 2.100).
These individuals would have had
longer-term experience with manage-
ment of the aqueduct system and likely
had a role in ensuring knowledge trans-
fer. The roles of knowledge transfer,
organizational learning, and project
learning are seen as important contem-
porary considerations for project man-
agers (Manu & Walker, 2006; Maqsood,
2006; Reich, 2007; Sense, 2003).
Legal Frameworks
There were a number of sources of
Roman law that applied to an official
like Frontinus in 97 CE, and these
included imperial edicts, directives of
the senate (senatus consultum), laws,
judicial decisions, and customary prac-
tice. The position of curator aquarum
was created by a decree of the senate in
11 BCE (Frontinus, Aq. 2.99) and
through a law called the lex Quinctia
(Crawford, 1996; Frontinus, Aq. 2.128).
10 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Frontinus recoded a copy of the decree
in his text, thereby preserving a record
of the powers and duties of the curator
(Frontinus, Aq. 2.100), which parallels
the modern concepts of project corpo-
rate governance (Müller, 2009; Winch,
2001).
Misappropriation of funds, inaccu-
rate accounting, or incompetence
could be grounds for prosecution.
During the Republic, prosecution for
mismanagement was a real possibility,
and under the emperors, failure to dis-
charge your responsibilities to the
expected standard could end a man’s
career. Again, this has its contemporary
links to unethical behavior and gover-
nance structures aspects (Walker,
Segon, & Rowlinson, 2008).
To conclude this section, we have
shown a number of select project man-
agement processes and roles that
exemplify project management and
have provided both evidence of the
Frontinus Roman and contemporary
parallels.
Discussion
Due to scope limitations, this article
cannot provide endless examples of
project management practices and role
behaviors from both eras under study.
The limit to this exploration is stated by
the following research questions:
1. Have the best project management
practices for initiating, funding, and
implementing infrastructure projects
changed fundamentally over the past
2,000 years?
2. If so, in what ways?
3. What implications does this have
for current project management
practices?
These questions were addressed by
using a single case study example (an
exceptional individual who could be
described as fulfilling the roles of project
manager, project champion, and project
sponsor), which represents the best
available evidence of project manage-
ment best practices from around 2,000
years ago, and citations from current
examples of the best project manage-
ment practices. It must be stressed that
Frontinus provides an exemplar
of project management during the
Roman period. Similarly, citations of
contemporary literature are provided to
highlight the better or best practices,
rather than what often occurs today.
There are important similarities as well
as differences between the historical
case and modern approaches.
The historical context provided in
this article suggests that the prevailing
project management culture of the
time was highly hierarchical. The
Roman Empire survived for many cen-
turies, and communication technology
was primitive when compared with
today’s facilities and approaches.
Communication channels were radical-
ly different from today, in which the
Internet shapes our notions of the
times to send, respond to, and receive
messages, as well as generating and
transmitting project information. In
Roman times, giving and receiving
orders and being influenced by those
with the power to influence your fami-
ly’s (most especially, your descendants’)
reputation, vulnerability, and potential
for advancement were of a different
order of importance (literally vital to
“life”) than is the case today.
However, by acknowledging this
caveat, we can suggest some compar-
isons and draw conclusions. In many
ways, little has fundamentally changed
in project management roles and
approaches, and yet the changes in the
use of tools and techniques have been
extensive. There has been no evidence
of sophisticated planning, budgeting,
financing instruments, and project con-
trol techniques and tools used during
the Roman era compared with those
currently used. There appears to be vast
changes in the availability of project
management tools and techniques
between those suggested by the histori-
cal record of the Roman era under
consideration when compared with the
literature and practices of today. In
Roman times, it was important to “get
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 11
Frontinus’ Era Practices
1. Project funding is through “public
purse,” private venture capital, pri-
vate capital raising, and war booty.
2. Decision making follows a well-
recognized hierarchy from the
Emperor to Frontinus to those
delivering projects. Frontinus uses a
panel of expert advisors to support
in his decision making.
3. Labor during the time of Frontinus
was almost always outsourced.
Contractors’ failure to deliver prom-
ised project outcomes had potential-
ly severe consequences—death or
retribution on the contractor for lit-
erally generations. Slave labor was
also used.
Contemporary Practices
Funding is through government spend-
ing; the financial market “industry”; joint
capital raising between organizational
entities, including public, private, and
partnership-type initiatives; allocation
of funding priorities using a portfolio or
program management approach; and
raising funds through business mergers
and acquisitions.
Recent literature extols the virtues of
program and portfolio management
(PMI, 2006a, 2006b) and stresses the
need to align project decision making in
terms of resourcing with strategic goals
in mind (Archer & Ghasemzadeh, 1999;
Morris & Jamieson, 2004; Norrie, 2008).
Outsourcing is the preferred option
when it makes sense to do so from a
practical or strategic point of view
(Auguste, Hao, Singer, & Wiegand, 2002;
Barthélemy, 2001; Domberger, 1998;
Lobez, 1999; Walker, Stark et al., 2008).
Slave labor is banned in developed
nations, even though many people
today work in conditions comparable
with those of the slaves during Roman
times. The current literature on
work–life balance suggests that much
could be improved in this area, and
modern workers act at times as if they
are slaves to their work (Lingard, 2003;
Lingard & Francis, 2005a, 2005b).
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Explanation of Changes
A cynic may observe that little has
changed. The label on the process may
have changed. War reparations may not
be a common way of funding projects,
but the reallocation of resources
through a merger-and-acquisition exer-
cise would inevitably lead to “liberating”
resources for projects.
The main change is contemporary
expectations of transparency and gover-
nance. A cynic could point to political
intervention that defies logic—see, for
example, Flyvbjerg’s work (Flyvbjerg,
Holm, & Buhl, 2002; Flyvbjerg,
Rothengatter, & Bruzelius, 2003), where
today’s economy with “the truth” and
use of unrealistic estimates is not in
effect very different from decisions
made by the Imperial Fiat in Roman
times.
Current literature stresses alignment
with corporate goals through a strategy
process that is often based on a pre-
scriptive school of strategy (Mintzberg,
Ahlstrand, & Lampel, 1998; Walker,
Arlt, & Norrie, 2008).
The role of a project management office
(PMO) (Handler & Magee, 1999; Hobbs
& Aubry, 2007; Kerzner, 2003; Müller,
2009) often provides the same kind of
advisors used in Frontinus’ time.
The outsourcing or firm-internal delivery
choice may be made with more consid-
eration today. The decision is more likely
linked to a rationale today than what
appears to have been the case in the
time of Frontinus.
Work–life balance literature does imply
that much project work involves an inor-
dinate amount of time and energy com-
mitment to project delivery to the extent
that the physical punishment of slaves
has been replaced by more subtle
career and job security tools (e.g., long
hours of work). Many employers today,
as in Roman times, have the power to
financially destroy a person’s life.
Exploitation of migrant labor is also con-
sidered a problem today in the context
of project management (Green, 2006).
(Continues on next page)
11
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 12
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
Frontinus’ Era Practices
4. Knowledge transfer during the time of
Frontinus was rare and almost wholly
explicit, when it existed at all.
Craftsmen transferred knowledge to
their clans and close associates, but
there was no formal or recognized
system for this. Frontinus’ decision to
create a manual that might be of use
to others in his post was unusual.
5. Legal frameworks that concerned
Frontinus related to avoiding corrup-
tion and incompetence.
Table 1: Comparison between the Roman case study exemplar of select best practices and the current common best practices.
things done”; today, there is a heavy
focus on optimization and efficiency.
The advent of cheap and ubiquitous
computers is as unimagined in the
Roman era as was the case only two
decades ago. Computer technology has
allowed not only the development of
highly intricate planning and simula-
tions to take place (time, cost, and
financial modeling), but also for design
modeling that provides visualization
and simulation modeling through
building information models (BIMs)
(Aranda-Mena, Crawford, & Chevez,
2009). These enable a far greater ability
to model alternative design to optimize
costs and time, for example, than was
conceivable until recently.
Table 1, therefore, primarily focuses
on processes that can be compared
with no evidence of the sophisticated
design optimization tools and monitor-
ing and control tools available until
recently.
The story that emerges from the
historical record and the discussion as
outlined above suggests several main
behavioral differences that are appar-
ent between the Frontinus and con-
temporary eras. One major difference is
the attitude toward authority, and the
12 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Contemporary Practices
The contemporary literature suggests a
keen interest in knowledge work and
innovation diffusion, with knowledge
being seen as a key asset and an impor-
tant aspect of project management
(Reich, 2007; Walker & Maqsood, 2008).
Although concern exists about corrup-
tion and mismanagement, these are
currently seen through a corporate gov-
ernance lens (Müller, 2009).
other is the attitude toward project
delivery performance, as shown in
Table 2.
Conclusion
This article seeks to answer three ques-
tions relating to changes in project
management best practices from
almost 2,000 years ago until today. The
study of a famous Roman “accidental
project manager” has been compared
with contemporary literature that out-
lines the current best practices in proj-
ect management.
The discussion in this article pro-
vides evidence to support the conclu-
sion that many project management
processes that were written about by
Frontinus share common goals with
those of today. In that sense, little has
changed; however, in terms of how
these processes are enacted, the
changes have been radical and signifi-
cant. Many of the changes relating to
how project management processes are
undertaken over time can be seen as
primarily caused by technological
changes with the greater use of tools for
optimization, planning, and monitoring
for control. An additional change can be
seen by shifts in the power balance
Explanation of Changes
The best project management practices
today stress designing-in systems to
share and transfer created knowledge
through projects so that all parties can
continuously improve their project per-
formance.
Today, stress is put on designing a sys-
tem that flags the potential problems
of corruption and the poor management
of resources. There is a greater acknow-
ledgment of systems failing rather than
individual culpability, although this
does not mean that individual acts of
corruption are not considered potential
problems.
between parties and a cultural change,
in which parties do not feel obliged to
protect family honor and reputation.
The implications for project man-
agement practice have been provided.
A main implication is that followers
choose to be led these days, so that
leadership style and the design of pro-
curement systems to maximize and
facilitate commitment at the affective
“want to” level (Meyer & Allen, 1991) are
essential, and this is because of a con-
temporary focus on effective dispute
resolution. Not even a sound gover-
nance system that provides for penal-
ties is as effective as not resorting to
legal and contractual remedies to solve
disputes or to attempt forcing
improved performance. That said, a
sound governance system should be
used to make the system fair and
encourage commitment and discour-
age exploitation by any party, as well as
making performance and decision
making transparent so that emerging
problems can be dealt with before they
become serious impediments to proj-
ect delivery. The combination of out-
sourcing and insourcing should not be
an automatic given but linked to strate-
gic project delivery logic. In Frontinus’
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 13
Frontinus’ Era Practices
The project manager, sponsor, or
champion was given the right to act in
a highly authoritarian way, and this
was accepted as legitimate. As long as
that behavior did not cause a riot or
mismanagement, resulting in famine,
plague, or an uprising, then it would be
supported by the power of the land.
Project performance was required
regardless of cost to the contractor.
Once a contract was agreed on for the
project delivery, then the contractor
would complete it at the agreed-on
terms. Asking for more money after
agreeing to do the work was not an
option.
Table 2: Implications for project management practice based on the Roman case study exemplar of select best practices and current common best
practices.
time, the response was to tender for
project work and then ruthlessly apply
sanctions, and failure carried potential-
ly life-destroying repercussions. The
consequences of failure for the contrac-
tor could be financial ruin, which, for
the Romans, could be as extreme as
having to sell yourself into slavery to
pay your debts. For the project manag-
er, failure could invite accusations of
corrupt behavior, legal prosecution,
Contemporary Practices
Contemporary governance arrange-
ments are rooted in a legal framework in
most countries in a way in which “fair-
ness” lies at the root of legitimacy rather
than some form of decree from an
emperor, king, or political leader. This
governance regime is always open to
challenge and revision if deemed to be
unfair or biased.
Contractors who take on project work
that they are unable to complete will
declare insolvency or will leverage this
possibility to gain more resources from
a client. Project time and cost overruns
are common. Although every contractor
has an intention to complete the project
as promised, it is not guaranteed. A legal
system supports negotiation and a pos-
sibility for the contractor to abandon
projects.
loss of future public offices, or enduring
disgrace to one’s own family. This
approach is not feasible or realistic
today.
This leads to a question about the
future trends in project management,
based on this historical comparison.
First, it must be acknowledged that in
terms of project management tools and
techniques, changes were glacial until
only a matter of decades ago. Morris
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Implication of Changes
Rome at the time of Frontinus was
(to the common people who undertook
the project delivery work, as well as its
design), in essence, a dictatorship.
Contractors and artisans were under
threat of not only personal ruin, but also
public disgrace that could have multi-
generational consequences. Centuries
of political change, particularly over the
last century, have totally changed the
political balance so that “fairness” now
trumps “institutional power.”
Followers now, to a large extent, choose
to follow rather than be forced to follow
a leader.
A client who is most likely to engineer
success in a project will acknowledge
the existence of power imbalances act-
ing in both directions through inherent
client power and contractor power. This
translates into a system of governance,
systems of dispute resolution, systems
of joint problem solving, and knowledge
sharing.
A best practice system allows trans-
parency of project performance so that
both the contractor and client can
detect early-warning signals and
address these so that project success is
more likely.
Contractor motivation is far more short-
term now than was the case in the time
of Frontinus, so that clients need to har-
ness the contractor’s desire to perform
well rather than demand performance.
(1994) provides a good history of proj-
ect management and shows that the
most commonly recognized project
management techniques appeared
during the twentieth century and, prior
to that, had not changed much from
the time of Frontinus. The major and
radical change seems to have occurred
as strategic orientation changes (Morris
& Pinto, 2004), as well as in the procure-
ment approach (Masterman, 2002;
13
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 14
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
Rowlinson & McDermott, 1999; Walker &
Hampson, 2003; Walker & Rowlinson,
2008; Winch, 2003). These approaches
stress leadership that enhances com-
mitment, better dispute resolution
processes, and shared client–contractor,
co-knowledge generation in facilitating
better ways to deliver projects. Thus,
the future lies with moving from coer-
cion toward genuine shared values that
result in co-commitment and more bal-
anced reward and sanction systems to
encourage and facilitate this process.
The project management loss for
some clients (implied by Frontinus’ era)
is one of performance commit-
ment, albeit from a highly normative
(loyalty) or continuance (need to do so
to survive or not lose out) perspective
(Meyer & Allen, 1991). Some clients will
regret and mourn their loss of power to
compel contractors to deliver projects
that have occurred over the centuries.
That said, one of the attractive features
of project management approaches in
the time of Frontinus was their simplic-
ity. Today, dealing with complexity and
an array of stakeholder expectations is
a serious problem that needs to be
acknowledged and remedied.
We started writing this article as an
interesting exercise to see just how
much evidence there was to better
understand project management from
the perspective of somebody who
would have been considered a project
manager many centuries ago.
Frontinus proved a good candidate
because of his remarkable zeal in
ensuring that the lessons learned could
be shared and passed down to his suc-
cessors. Aside from this being an
admirable project management quality,
it left a useful historical record. The his-
torical evidence suggests that he wasn’t
a bad client (or client-side) project
manager; rather, he worked with a sys-
tem that automatically believed it was
acceptable for a client and project
manager hiring labor and contractors
to have and use the institutional power
that the culture of the time allowed.
Frontinus’ desire for a form of organiza-
14 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
tional learning was very cutting edge
compared with that used today, while
modern technology appears to be a
defining difference between his era and
ours. This technology and its ability to
further democratize joint decision
making between the client and project
team may further shape the future. ■
References
Aranda-Mena, G., Crawford, J., &
Chevez, A. (2009). Building informa-
tion modelling demystified: Does it
make business sense to adopt BIM?
International Journal of Managing
Projects in Business, 2(3), 419–433.
Archer, N. P., & Ghasemzadeh, F.
(1999). An integrated framework for
project portfolio selection.
International Journal of Project
Management, 17(4), 207–216.
Auguste, B. G., Hao, Y., Singer, M., &
Wiegand, M. (2002). The other side of
outsourcing. The McKinsey Quarterly,
1, 52–64.
Badian, E. (1996). Cura(tio), curator. In
S. Hornblower & A. Spawforth (Eds.),
The Oxford classical dictionary (p. 413).
Oxford, UK: Oxford University Press.
Barthélemy, J. (2001). The hidden cost
of IT outsourcing. Sloan Management
Review, 42(3), 60–69.
Bourne, L. (2005). Project relationship
management and the stakeholder circle
(Unpublished doctoral dissertation).
RMIT University, Graduate School of
Business, Melbourne, Australia.
Bourne, L., & Walker, D. H. T. (2003).
Tapping into the power lines: A 3rd
dimension of project management
beyond leading and managing. Paper
presented at the 17th World Congress
on Project Management, Moscow,
Russia.
Bourne, L., & Walker, D. H. T. (2005).
Visualising and mapping stakeholder
influence. Management Decision, 43(5),
649–660.
Brady, T., & Davies, A. (2004). Building
project capabilities: From exploratory
to exploitative learning. Organization
Studies, 25(9), 1601–1621.
Bröchner, J. (2006). Outsourcing. In
D. L. R. Leiringer (Ed.), Commercial
management of projects defining the
discipline (pp. 193–206). Abingdon,
UK: Blackwell.
Bruun, C. (2007). Why did Frontinus
write the De Aquaeductu? Journal
of Roman Archaeology, 20, 460–466.
Bruun, C. (2008). Classical influences
on Rome’s water administration in the
early modern period in L’eau Comme
Patrimoine. Québec: Les Presses De
L’Université Laval.
Crawford, M. (1996). Roman statutes.
London: Bulletin of the Institute of
Classical Studies.
Crook, J. (1975). Consilium principis:
Imperial councils and counsellors from
Augustus to Diocletian. New York: Arno
Press.
Crouch, D. (1993). Water management
in ancient Greek cities. Oxford, UK:
Oxford University Press.
Dessau, H. (1902). Inscriptiones
Latinae Selectae. Berlin: Weidmann.
(Abbreviated to ILS.)
Domberger, S. (1998). The contracting
organization: A strategic guide to out-
sourcing. Oxford, UK: Oxford
University Press.
Eck, W. (2003). Cura, curators. In Brill’s
new pauly: Encyclopaedia of the
ancient world. Leiden/Boston: Brill.
Englund, R. L., & Bucero, A. (2006).
Project sponsorship: Achieving man-
agement commitment for project suc-
cess. San Francisco, CA: Jossey-Bass.
Evans, H. B. (1993). In Tiburtium
usum: Special arrangements in the
Roman water system (Frontinus, Aq.
6.5). American Journal of Archaeology,
97(3), 447–455.
Evans, H. B. (1994). Water distribution
in ancient Rome: The evidence of
Frontinus. Ann Arbor, MI: The
University of Michigan Press.
Fill, C., & Visser, E. (2000). The out-
sourcing dilemma: A composite
approach to the make or buy.
Management Decision, 38(1), 43–50.
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 15
Flyvbjerg, B., Holm, M. S., & Buhl, S.
(2002). Underestimating costs in pub-
lic works projects: Error or lie? Journal
of the American Planning Association,
68(3), 279–295.
Flyvbjerg, B., Rothengatter, W., &
Bruzelius, N. (2003). Megaprojects and
risk: An anatomy of ambition. New
York: Cambridge University Press.
Frontinus, S. (2003). Stratagems, aque-
ducts of Rome (C. E. Bennett, Trans.,
M. B. McElwain, Ed.). Cambridge, MA:
Harvard University Press.
Graham, R. J. (1992). A survival guide
for the accidental project manager.
Proceedings of the Annual Project
Management Institute Symposium
(pp. 355–361).
Green, S. (2006). The management of
projects in the construction industry:
Context, discourse and self-identity. In
D. Hodgson & S. Cicmil (Eds.), Making
projects critical (pp. 232–251). Basing-
stoke, UK: Palgrave MacMillan.
Handler, T. J., & Magee, F. (1999).
Multiple styles for implementing a
project office. Stamford, CT: Gartner
Group.
Helm, J., & Remington, K. (2005).
Effective project sponsorship an evalu-
ation of the role of the executive spon-
sor in complex infrastructure projects
by senior project managers. Project
Management Journal, 36(3), 51–61.
Hobbs, B., & Aubry, M. (2007). A multi-
phase research program investigating
project management offices (PMOs):
The results of phase 1. Project
Management Journal, 38(1), 74–86.
Hunt, A. S., & Edgar, C. C. (Trans.).
(1932–1941). Select papyri. London:
Heinemann.
Huttl, W. (1973). Antoninus Pius. New
York: Arno Press. (Original work pub-
lished 1933)
Kerzner, H. (2003). Strategic planning
for a project office. Project Management
Journal, 34(2), 13–25.
Kloppenborg, T. J., Tesch, D., Manolis,
C., & Heitkamp, M. (2006). An empiri-
cal investigation of the sponsor’s role
in project initiation. Project
Management Journal, 37(3), 16–25.
Lingard, H. (2003). The impact of indi-
vidual and job characteristics on
“burnout” among civil engineers in
Australia and the implications for
employee turnover. Construction
Management & Economics, 21(1),
69–80.
Lingard, H., & Francis, V. (2005a). The
decline of the “traditional” family:
Work-life benefits as a means of pro-
moting a diverse workforce in the con-
struction industry of Australia.
Construction Management and
Economics, 23(10), 1045–1057
Lingard, H., & Francis, V. (2005b). Does
work-family conflict mediate the rela-
tionship between job schedule
demands and burnout in male con-
struction professionals and managers?
Construction Management &
Economics, 23(7), 733–745.
Livy, T. (1959–2004). Ab urbe condita
(B. O. Foster & Alfred Schlesinger,
Trans.; 14 vols.). London: Harvard
University Press.
Lobez, S. (1999). The brave new world
of contracting out, privatisation and
outsourcing. The Law Report—Radio
National. ABC Radio. Retrieved from
http://www.abc.net.au/rn/lawreport/
stories/1999/55464.htm
Manu, C., & Walker, D. H. T. (2006).
Making sense of knowledge transfer
and social capital generation for a
Pacific island aid infrastructure proj-
ect. The Learning Organization, 13(5),
475–494.
Maqsood, T. (2006). The role of knowl-
edge management in supporting inno-
vation and learning in construction
(Unpublished doctoral dissertation).
RMIT University, School of Business
Information Technology, Melbourne,
Australia.
Masterman, J. W. E. (2002). An intro-
duction to building procurement sys-
tems (2nd ed.). London: Spon.
Meyer, J. P., & Allen, N. J. (1991). A
three-component conceptualization of
organizational commitment. Human
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Resource Management Review, 1(1),
61–89.
Mintzberg, H., Ahlstrand, B. W., &
Lampel, J. (1998). Strategy safari: The
complete guide through the wilds of
strategic management. London:
Financial Times/Prentice Hall.
Mommsen, T. (1887). Römisches
Staatsrecht (Vol. 1). Leipzig3.
Mommsen, T., Dessau, H., &
Hirschfeld, O. (Eds.). (1869–2000).
Corpus inscriptionum Latinarum.
Berlin: G. Reimer. (Abbreviated to CIL).
Morris, P. W. G. (1994). The manage-
ment of projects: A new model. London:
Thomas Telford.
Morris, P. W. G., & Hough, G. H. (1993).
The anatomy of major projects: A study
of the reality of project management.
London: Wiley.
Morris, P. W. G., & Jamieson, A. (2004).
Translating corporate strategy into
project strategy. Newtown Square, PA:
Project Management Institute.
Morris, P. W. G., & Pinto, J. K. (Eds.).
(2004). The Wiley guide to managing
projects. New York: Wiley.
Müller, R. (2009). Project governance.
Farnam, Surrey, UK: Gower.
Norrie, J. (2008). Breaking through the
project fog: How smart organizations
achieve success by creating, selecting
and executing on-strategy projects.
Toronto: Wiley.
Peachin, M. (2004). Frontinus and the
curae of the curator aquarum.
Heidelberg: Franz Steiner Verlag.
Pinto, J. K., & Kharbanda, O. P. (1995).
Lessons for an accidental profession.
Business Horizons, 38(2), 41–50.
Project Management Institute (PMI).
(2004). A guide to the project manage-
ment body of knowledge (3rd ed.).
Newtown Square, PA: Author.
Project Management Institute (PMI).
(2006a). The standard for portfolio
management. Newtown Square, PA:
Author.
Project Management Institute (PMI).
(2006b). The standard for program
15
04-16PMJ0808.qxd 8/8/11 12:16 PM Page 16
Frontinus—A Project Manager From the Roman Empire Era
PAPERS
management. Newtown Square, PA:
Author.
Quinn, J. B., & Hilmer, F. G. (1994).
Strategic outsourcing. Sloan
Management Review, 35(4), 43–56.
Reich, B. H. (2007). Managing knowl-
edge and learning in IT projects: A
conceptual framework and guidelines
for practice. Project Management
Journal, 38(2), 5–17.
Ridley, R. T. (1987). History of Rome: A
documented analysis. Rome: L’erma di
Bretschneider.
Rodgers, R. H. (2004). Frontinus de
aquaeductu urbis Romae. Cambridge,
UK: Cambridge University Press.
Rowlinson, S., & McDermott, P. (1999).
Procurement systems: A guide to best
practice in construction. London:
E&FN Spon.
Sense, A. J. (2003). Learning generators:
Project teams re-conceptualized. Project
Management Journal, 34(3), 4–12.
Shenhar, A. J., Dvir, D., Levy, O., &
Maltz, A. C. (2001). Project success: A
multidimensional strategic concept.
Long Range Planning, 34(6), 699–725.
Suetonius. (1979). The twelve Caesars
(M. Grant, Trans.). London: Penguin
Books.
Turner, J. R., & Cochrane, R. A. (1993).
The goals and methods matrix: Coping
with projects with ill-defined goals
and/or methods of achieving them.
International Journal of Project
Management, 11(2), 93–102.
Walker, D. H. T., Arlt, M., & Norrie, J.
(2008). The role of business strategy in
PM procurement. In D. H. T. Walker &
S. Rowlinson (Eds.), Procurement sys-
tems: A cross industry project manage-
ment perspective (pp. 140–176).
Abingdon, UK: Taylor & Francis.
Walker, D. H. T., & Hampson, K. D.
(2003). Procurement strategies:
16 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
A relationship based approach. Oxford,
UK: Blackwell.
Walker, D. H. T., & Maqsood, T. (2008).
Procurement innovation and organisa-
tional learning. In D. H. T. Walker &
S. Rowlinson (Eds.), Procurement sys-
tems: A cross industry project manage-
ment perspective (pp. 246–276).
Abingdon, UK: Taylor & Francis.
Walker, D. H. T., & Rowlinson, S. (Eds.).
(2008). Procurement systems: A cross
industry project management perspec-
tive. Abingdon, UK: Taylor & Francis.
Walker, D. H. T., Segon, M., &
Rowlinson, S. (2008). Business ethics
and corporate citizenship. In D. H. T.
Walker & S. Rowlinson (Eds.),
Procurement systems: A cross industry
project management perspective
(pp. 101–139). Abingdon, UK: Taylor &
Francis.
Walker, D. H. T., Stark, J., Arlt, M., &
Rowlinson, S. (2008). Introduction and
procurement fundamentals. In D. H. T.
Walker & S. Rowlinson (Eds.),
Procurement systems: A cross industry
project management perspective
(pp. 1–31). Abingdon, UK: Taylor &
Francis.
Ward-Perkins, J. B. (1937). The career
of Sex. Julius Frontinus. The Classical
Quarterly, 31(2), 102–105.
Winch, G. M. (2001). Governing the
project process: A conceptual frame-
work. Construction Management and
Economics, 19(8), 799–808.
Winch, G. M. (2003). Managing con-
struction projects. Oxford, UK:
Blackwell.
Derek Walker is professor of project manage-
ment and director of research at the School of
Property, Construction and Project Management,
RMIT University. He worked in various project
management roles in the United Kingdom,
Canada, and Australia for 16 years before com-
mencing his academic career in 1986. He
obtained a master of science from the
University of Aston (Birmingham) in 1978, and a
PhD in 1995 from RMIT University (Melbourne).
He has written over 200 peer-reviewed papers
and book chapters. His most recent books
include Early Warning Signs in Complex Projects
(2010, Project Management Institute), which he
coauthored with O.J. Klakegg, T. Williams,
B. Andersen, and O.M. Magnussen, and
Procurement Systems—A Cross Industry Project
Management Perspective, Series Procurement
Systems—A Cross Industry Project Management
Perspective (2008,Taylor & Francis), which
he coedited with S. Rowlinson. His research
interests center on innovation diffusion of infor-
mation and communication technologies, knowl-
edge management, project management, and
project procurement systems. He also teaches
in the Master of Project Management (MPM)
academic program at RMIT. He is editor of the
International Journal of Managing Projects in
Business for Emerald Insight
(http://info.emeraldinsight.com/products
/journals/journals.htm?PHPSESSID⫽j0bm25095
pn370h1fvdobdsti4&id⫽ijmpb) and is a mem-
ber of the editorial board of Project Management
Journal, The Learning Organization, Construction
Innovation, and several other journals.
Christopher J. Dart, BA(Hons), DipEd, PhD, is a
Roman historian specializing in the social, politi-
cal, and institutional history of the Roman world.
He is a fellow of the School of Historical and
Philosophical Studies at the University of
Melbourne. He has published articles on aspects
of the Social War, Roman citizenship, land in
Italy, and the Roman navy. He has also con-
tributed a chapter to Impact of Empire, four
entries for the Wiley-Blackwell Encyclopedia of
War, and a chapter in the forthcoming Wiley-
Blackwell, A Companion to the Flavian Age of
Imperial Rome.
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 17
PAPERS
Translation and Convergence in
Projects: An Organizational
Perspective on Project Success
Neil Alderman, Newcastle University Business School, Newcastle upon Tyne, United Kingdom
Chris Ivory, Newcastle University Business School, Newcastle upon Tyne, United Kingdom
ABSTRACT ■
A range of theories (actor-network theory,
multinodality, and sense making) are drawn
together into a single model of project manage-
ment processes in order to discuss project suc-
cess and failure. It is argued that success and
failure can be characterized in terms of a con-
tinuum between project convergence and
divergence. The causes of divergence and con-
vergence are discussed with reference to the
above theories using four illustrative case
studies.
KEYWORDS: actor-network theory; multi-
nodality; sense making; project success; project
failure; case studies
Project Management Journal, Vol. 42, No. 5, 17–30
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20261
INTRODUCTION ■
he increasing complexity of project management has led to a debate
T about the way in which projects are currently managed and to the
search for new concepts and theories through which to understand
and support the project management function. This has given rise to
a number of initiatives, such as the present “Making Projects Critical” series
of workshops (Hodgson & Cicmil, 2006) and the Engineering and Physical
Sciences Research Council (EPSRC) “Rethinking Project Management”
research network (Winter & Smith, 2006), that seek alternative perspectives
to the conventional understanding of projects and project management as
embodied in the standard bodies of knowledge (Association of Project
Management, 2006; Project Management Institute, 2004).
This article presents some of the new thinking in this context. The article
focuses on the complex social and political aspects of managing projects and
identifies theories and concepts that are believed to be relevant to under-
standing and managing those projects (Alderman, Ivory, McLoughlin, &
Vaughan, in press). The key difficulty with complex projects is that those
managing them will often be “feeling their way” toward a solution rather than
following a reliable blueprint or project plan. Constructing a building to a
detailed specification using known technologies requires traditional plan-
ning and work breakdown (and even then there is likely to be an extensive
snagging list). On the other hand, delivering an exhibition experience to mark
the millennium, or a government building to capture the spirit of a country
for a diverse and demanding client, or a new airport terminal deploying
untried technology to serve the needs of two distinct organizations, is quite a
different matter. In these cases, project managers move from a situation that
is complicated to one that is genuinely complex. The management problems
multiply when one considers that implementing the solution must be done in
the context of suppliers, consultants, and partners who may themselves be
“feeling their way” toward what is required of them. This requires new mod-
els of projects that account for the more elusive, less easily articulated, and
largely tacit skills of project managers. To create those models, this article
draws on the work of actor-network theorists, the principles of sense making,
and the notions of organic and mechanistic styles of organization.
Projects as Actor-Networks
Attempts to engage in complex project activities involve considerable man-
agement and organizational challenges in terms of the building and main-
taining of extended project networks. The idea of managing as an actor-
network building-and-maintaining activity introduces a more nuanced way
of thinking through the problems faced by project managers. It makes it
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 17
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 18
Translation and Convergence in Projects
PAPERS
clear that rather than simply monitor-
ing the execution of packages of work
agreed at the outset of the project to
ensure adherence to quality, time, and
cost objectives, the role of the project
manager (and others, human and non-
human, that hold influence within the
project) is primarily one of developing
and managing relationships across an
extended network of actors—human
and nonhuman. The managerial com-
petencies required to do this might
include the ability to assess the likely
motivations and barriers to action of a
wide range of actors in different techni-
cal and organizational settings and the
ability to translate that knowledge into
effective influence over those actors.
Actor-network theory, or ANT, (Callon,
1980; Latour, 1996; Law, 1992) address-
es precisely these issues.
Actor-network theory is ostensibly a
theory of innovation that has developed
out of a desire to trace the interrelations
between human and nonhuman (e.g.,
technological) actors that make possi-
ble the accomplishment of stability (be
that the temporary stability of projects
or the longer-term stability of “society”).
Although actor-network theory is not
itself a theory of projects, its interest in
emerging artifacts (innovation) means
that its subject matter tends to derive
from projects. Callon’s (1986) study of
the failure of the proposed electric car
system in France in the 1970s, Law and
Callon’s (1992) study of the failed TSR2
fighter aircraft in the 1960s in the United
Kingdom, and Latour’s (1996) study of
the failed French transport system,
ARAMIS, are now classic studies of
fledgling project networks.
Actor-network theory proposes a
model of coordination in the pursuit of
technological goals. The actor-network
approach “. . . rests on the idea that
innovation and the strategies that
shape it may be described in a network
vocabulary that emphasizes the inter-
related and heterogeneous character of
all its components, whether social or
technical” (Bijker & Law, 1992, p. 18).
Heterogeneous actor-networks are
18 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
built by the active enrollment (transla-
tion) of “actants” (human and nonhu-
man actors) into a single network. The
work of translation is performed using
intermediaries that include money,
contracts, specifications, schedules,
talk, and prototypes, which are
deployed to encourage other necessary
actors to join the network and to con-
trol them once they are in place.
Critically, network builders must con-
tinually assure other actors of the bene-
fits of their involvement in the network.
Intermediaries persuade and inform by
carrying the necessary information to
bring actors into line with one another.
Convergence and Divergence
A particular feature of actor-networks is
that they can be convergent or diver-
gent (Law & Callon, 1992). In convergent
projects, the understanding of interme-
diaries among actors is shared, with the
result that they have predictable trans-
lation effects. Actors in convergent
projects do not resist translation and
such translations are, therefore, effi-
cient. Convergent project networks typ-
ically have clear and agreed “obligatory
points of passage”1 (Law & Callon, 1992,
p. 31) through which all other actors,
translations, and intermediaries must
pass.
In weak and divergent projects,
actors do not all share a common
understanding of the intermediaries
circulating the network and many will
fail to recognize the legitimacy of an
organization or institution regarded by
others as an obligatory point of passage
or center of control. When this hap-
pens, they will resist the roles the net-
work assigns to them and will respond
to instructions unpredictably. As a
result, key actors may begin to pursue
their interests elsewhere. These net-
works are inefficient and will require
plenty of “backstage” work (cf.
Buchanan & Boddy, 1992) to keep them
on track. They may survive to reach
1Also referred to as “obligatory crossing points” (Latour,
1996, p. 43) and “centres of control” (Latour, 1990).
their original goals, but if they grow too
divergent, they will become vulnerable
to collapse. Collapse occurs when
important actors cease to be mobilized
by the network’s intermediaries; they
no longer perceive their interests to be
served by the project and withdraw. As
Latour puts it, in a situation surely
familiar to many an overstressed proj-
ect manager:
The full difficulty of innovation
becomes apparent when we recog-
nize that it brings together, in one
place, on a joint undertaking, a
number of interested people, a good
half of whom are prepared to jump
ship, and an array of things, most of
which are about to break down.
(Latour, 1996, p. 58)
A network approach to projects pro-
vides a useful descriptive framework—a
single vocabulary for framing and dis-
cussing projects. The usefulness of
actor-network theory, and what sets it
apart from other approaches to projects,
is that it focuses on the efficiency of net-
work translations rather than other
ostensibly more subjective measures of
success (Linde & Linderoth, 2006)—that
is, the effectiveness of project manage-
ment in building networks to bring
about change, the direction of change
not withstanding. An effective project is
one in which network translations result
in actor convergence around stable
goals—goals that are, from ANT’s per-
spective, held stable by the actor-
network (Lee & Hassard, 1999).
Multinodality and Networks
Actor-network theory is part of a post-
modern social science (though it also
has roots in interactionism and rela-
tivism) that sees concrete reality as
“emerging” out of a multitude of inter-
actions within and between localities.
Thus:
. . . the image that we have got to
discard is that of the social oil refin-
ery. Society is not a lot of social
products moving round in structur-
al pipes and containers that were
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 19
put in place beforehand. Instead,
the social world is a remarkable
emergent phenomenon: in its
processes, it shapes its own flows.
(Law, 1994, p. 15)
Nevertheless, the larger part of lived
project experience is of repeatedly hav-
ing to accommodate already existing
organizations, technologies, and bod-
ies of knowledge—existing pipes and
containers. Action at one locality, noted
Latour (2007), is always conditioned by
action that has occurred at other previ-
ous localities. In the case of complex
projects, the pipes and containers that
condition action at other localities key
to the project may need to be reshaped
(translated) to accommodate new proj-
ect objectives—a process that they may
well resist. To describe these potential
pockets of resistance in a project con-
text, it is helpful to borrow the notion of
multinodality from Wynne (1988).
The concept of multinodality draws
attention to the open-textured and dis-
persed nature of most technologies,
particularly to their distribution in dif-
ferent locations. Wynne observes that
technologies are rarely the unitary
stand-alone objects we imagine them
to be. Rather, they are fragmented and
dispersed across distant and imperfect-
ly understood contexts—never more so
than when they are part of extended
supply chains. Attempts to build
extended project networks comprising
multiple organizations, geographical
locations, and “business cultures”
(obdurate self-reproducing pipes and
containers, in ANT terms) result in a
multitude of uncertainties and imper-
fect understandings. Different nodes,
which have their own entangled reward
systems and operating procedures that
may not be entirely appreciated by
project managers and others at the out-
set of the project, are included in the
network with unpredictable conse-
quences. We use the notion of multin-
odality to account for what we see as
the inevitably “brownfield” nature of
projects as they emerge in the context
of multiple pre-existing nodes, in the
sense that they are built on what is
already there. This is unproblematic
when those organizations are already
well aligned with the aims of the new
project, but in many complex projects
this will not be the case.
Achieving alignment in the context
of multinodal project networks
requires issues of localized sense mak-
ing (Weick, 2001) to be addressed.
Project participants engaging in sense
making (making sense of client
requirements, interpreting design
briefs, finding solutions to problems,
and so on) can do so from the perspec-
tive of existing ways of working and
thinking that may be at odds with the
requirements of the project center. In
the context of dispersed sense making,
it is not always easy for actors operat-
ing from distant nodes to accurately
assess what is required of them.
Specifications, particularly, though by
no means exclusively, those that deal
with broad performance parameters
rather than technical details, are not a
foolproof guide to what the customer
actually wants.
The concept of sense making as
espoused by Weick (1995) and others
captures the problem. Sense making is
a group accomplishment that con-
strains and directs thinking and makes
the apprehension of new phenomena
by group members sometimes difficult.
Sense-making perspectives have a long
history in the study of management
and organizations. The origins of this
approach to the study of organizations
rests primarily in the work of Karl Weick
(1979, 1993, 2001), Wiley (1988), and
Gephart (1993). Insights derived from
the concept have only latterly been
applied to projects and project man-
agement (Thomas, 2000).
An understanding of projects from a
sense-making perspective focuses far
more on the processes of organizing
projects rather than on the structure of
projects or the capabilities and
resources required to execute them. In
this perspective, more concern is
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
placed on the social aspects of project
management:
. . . the deliberate social interaction
occurring between humans working
together to accomplish a certain
task. . . . Thus a sense making focus
on project management directs us
to look at the processes of action
and interaction that enable individ-
uals to make sense of organizational
activities and how they interact to
effect the emergent projects.
Researchers are directed to explore
ways to facilitate the inter-subjec-
tive sense making to reduce com-
munication failures and confusion.
(Thomas, 2000, p. 42)
Sense making may appear as a
counter to the mainstream under-
standing of project management,
which has a focus on tools and tech-
niques in the narrower view and a focus
on the contingent relationship between
the initiating business context and the
different means by which projects
might be delivered in the broader view.
However, Thomas (2000), at least,
argues that sense making adds the
insight that both project initiation and
delivery are socially negotiated phe-
nomena and that the project itself is an
emergent entity and not “given” at the
start of the process or as something
composed of external components
(e.g., technology), which act independ-
ently of the sense-making process. This
is a vital insight.
Conventional views of project man-
agement see managing projects suc-
cessfully in terms of gaining access to
the right information, while uncertain-
ty, or weak management, is seen in
terms of a lack of information. However,
the sense-making perspective invites
us to view information itself as ambigu-
ous and equivocal and as filtered and
reconstructed through different
“frames of reference” (Weick, 1995). In
this view, the role of the project manag-
er, rather than being one of responding
to unambiguous inputs, is one of
attempting to deal effectively with
19
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 20
Translation and Convergence in Projects
PAPERS
ambiguity—to build and exert influ-
ence over other actors without reliable
intermediaries.
What the sense-making approach
highlights in the context of project-
based forms of organizing—especially
where these take on the properties of
complex projects—is that different
groups and communities do not neces-
sarily view the projects they are working
on in the same terms as one another.
Localized sense making (conditioned, for
example, by locally adopted measures of
success and reward) can thus disrupt the
ability of actors in that node to act in uni-
son with other nodes in the project.
Sense making can make a strong
contribution to an understanding of the
translation process in actor-networks.
The concept of sense making draws
attention to the inherently inter-subjec-
tive nature of interpreting reality and its
objects (which can include intermedi-
aries such as specifications, project
schedules, and contracts) and the con-
sequences for building and maintaining
project networks. Specifications, how-
ever clearly written from the perspec-
tive of one group, will be subject to
variable interpretation by actors work-
ing with alternative sense-making
frames. As projects grow more complex,
the project network expands and more
actors are enrolled into those networks,
differences of understanding will also
be drawn into the network. The result
will be further unanticipated transla-
tions and outcomes.
Organizational Styles in the
Context of Complexity
Our central proposition, based on ideas
from actor-network theory, is that suc-
cessful projects will be those that, in
network terms, are convergent. We also
suggest that convergence is created not
just by a convergence of interests (i.e.,
political convergence), but also by a
convergence of sense making around
what the end goals of the project are
(cognitive convergence). A dogged
focus on a stable set of goals can be
crippling for an organization (Kaynes,
20 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
2005), but it is essential for projects.
While actor-network theorists are keen
to point out that projects all too readily
fragment into multiple trajectories (e.g.,
Law & Callon, 1992), it is precisely the
job of keeping projects on a single tra-
jectory that project managers must
achieve. Failure to do so, even if it is not
the undoing of the project, is at the very
least a source of great inefficiency.
Effective project management will
therefore be associated with conver-
gence (i.e., the project’s various nodes
will have achieved convergence around
a commonly understood set of goals).
Convergence is desirable because it
ensures efficiency and unified respon-
siveness to challenges. Convergence in
projects is akin to what Burns and Stalker
(1961) referred to as the organic organi-
zational form. Organic organizations
thrive in uncertain environments
because they are able to respond without
fragmenting to unstable, shifting
demands. Organic organizations achieve
this by encouraging close interaction and
communication across the organization
(vertically, horizontally, and diagonally)
and by allowing, on the basis that every-
one knows what they should be doing,
the devolvement of decision making
across the organization. In organic
organizations, the authority to act
emerges from the possession of expertise
relevant to a particular task or problem,
rather than from position in a hierarchy.
Close and ongoing communication
means that workers and managers have
repeated opportunities to mold their
understanding around what the organi-
zation is trying to achieve; at the same
time, they are made aware, and make
others aware, of any changes that are
occurring in the organization to which
they or others might need to adjust. Such
interaction also provides managers with
opportunities to increase their own
understanding of the issues facing dis-
tant parts of the organization.
Organic management is efficient
and effective because it distributes the
demands of decision making to where
those decisions are best made. Although
Burns and Stalker (1991) do note the
prodigious use of committee meetings
to facilitate “catching up,” this is
arguably preferable to concentrated
centralized systems of management
and decision making that “lock out”
important actors.
The alternative to organic organiza-
tion is mechanistic organization.
Mechanistic organization, argue Burns
and Stalker (1991), emerges in response
to stable, long-run demand. As a conse-
quence of this stability, mechanistic
organizations focus on control for effi-
ciency rather than responsiveness.
Workers and managers focus on their
specialist roles and loyalty is local (e.g.,
to departments) rather than to the
organization as a whole. Workers and
managers have little knowledge of, or
interest in, decisions taken elsewhere in
the organization, and are isolated from
strategic decision making. This is a
highly efficient and effective means of
management, so long as demand is sta-
ble. Communication within the organi-
zation can pare down to the purely
quantitative (how many widgets, by
when). However, if there is a sudden
shift in technology or markets, such
organizations struggle to respond.
The delivery of complex projects is
best achieved through fluid organic
organizational forms. However, the cre-
ation of organic forms emerges out of
the work of translating actors into a sin-
gle convergent network. Multinodality
in projects implies that project man-
agers will often have to work hard to
gain an awareness of the sense-making
styles that are likely to be manifest in
more distant parts of the project net-
work if they are to be successful conver-
gent network builders.
The notions of translation, conver-
gence, node, sense making, and organ-
ic organization provide the possibility
of shedding an alternative light on the
interpretation of project success. In
the next section, we attempt to apply
these ideas to a reinterpretation of a
number of high-profile projects that
have been widely recognized as either
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 21
successful or as having failed in some
way (paradoxically, sometimes both).
The material for these cases is all drawn
from public domain documentation
and sources, rather than reflecting orig-
inal empirical research. The projects
considered are the Millennium Dome
in London, Heathrow Airport’s
Terminal 5, the Scottish Parliament
Building in Edinburgh, and the Eden
Project in Cornwall. All were multimil-
lion-pound projects and all involved
considerable complexity.
Case Studies
The case studies presented are construc-
ted from official documents, existing
case studies available in the academic
literature, contemporary press reports,
and transcripts of government commit-
tee hearings. The construction and
interpretation of the case studies has
been completed by the authors to illus-
trate the ideas presented earlier.
The Millennium Dome
The Millennium Dome and its associat-
ed exhibition were planned as the cen-
terpiece of the UK millennium celebra-
tions of 2000. The Dome opened its
doors on December 31, 1999, and
closed them a year later. The aims of the
project were not just to create a land-
mark building, but also to create a
“world profile for the celebration of the
millennium” that would “involve,
engage and transform visitors and par-
ticipants” and to do so on time and
within budget (National Audit Office
[NAO], 2000, p. 16). The project suc-
ceeded in creating a landmark building
but failed to deliver against these latter
aims, running over budget and failing
to attract the visitors required by the
business plan. Here, we argue that the
project should have been conceived as
an extended actor-network that failed
to converge around a single agreed-
upon set of outputs.
From its earliest conception, the
Millennium Dome project was under-
mined by divergent views and a lack of
clarity regarding what it was meant
to deliver. The Dome was originally
conceived of by the outgoing Conserva-
tive government but was taken on by the
Labour government in 1997. For the
Conservatives, the project was about
“selling ourselves and our country”
(Heseltine, cited in McGuigan &
Gilmore, 2002, p. 4). For Labour repre-
sentatives, the project needed less of a
business focus and more of a reflection
of the British “spirit of confidence and
adventure” (Blair, cited in McGuigan &
Gilmore, 2002). Ultimately, the exhibi-
tion failed to reflect either vision con-
sistently, leaving visitors confused as to
what the exhibition was about and the
press unable to print favorable reviews
(McGuigan & Gilmore, 2002).
The Dome also suffered to some
degree from the influence of ideology in
its execution. In keeping with the polit-
ical focus of the day, the intention had
been to place control of the project in
private hands. However, it proved
impossible to attract a private organiza-
tion willing to shoulder the level of risk
involved (NAO, 2000), and The New
Millennium Experience Company
(NMEC) was subsequently set up as a
proxy for private control. The company,
financed with lottery funding, had a
single shareholder in the form of a
Minister, Lord Falconer, answerable to
Parliament for the performance of the
NMEC. The project was allocated a net
budget of £399m (NAO, 2000).
The project had two streams of
activity, both run by the NMEC: the cre-
ation of a suitable building and coordi-
nation of the attraction it would house.
The building, designed by the Richard
Rogers Partnership and engineers Buro
Happold, was state of the art and a great
success; it has gone on to become a
major London landmark, currently as
the O2 Arena. It was handed over within
the 15 months specified and under
budget at £43 million.
The attraction, which the Dome
housed, did not fare so well. The open-
ing night was regarded by the press as a
fiasco of poor planning (in particular,
the public transport to the Dome), and
the attraction itself did little subse-
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
quently to win journalists over
(McGuigan, 2003, pp. 670, 675). It was
variously described in the press as
“vain, vapid and patronising” (Nutt,
2002). Visitor figures, though perhaps
influenced by the press, bore this out.
While the Dome needed 11 million vis-
itors to break even, ultimately only 4.5
million paying visitors came to the
exhibition throughout the year (Nutt,
2002), and the project required a fur-
ther four injections of National Lottery
money amounting to £179m (NAO,
2000).
The failure of the attraction had its
roots in the structure and focus of the
project (NAO, 2000) and in the failure of
the project to articulate and control the
role that zone sponsors played in shap-
ing the attraction (McGuigan &
Gilmore, 2002). The National Audit
Office notes that the management of
the project was focused intensively on
capital delivery and insufficiently on
the quality of the attraction or its tech-
nical operational requirements. With
respect to this latter issue, there was, for
example, no single team responsible for
maintenance (resulting in numerous
extended breakdowns) and a string of
operational failures (e.g., the long
queue for the Body Zone despite much
lower than expected visitor numbers).
There was a lack of experience in these
matters within the project (NAO, 2000),
also reflecting this lack of focus.
If operations were undermined by a
lack of operations focus, then the exhi-
bition itself was a victim of further
divergence regarding what the project
was meant to be about. Taken together,
the exhibition zones provided a con-
fused array of ideas that made impossi-
ble the delivery of a “wow” factor (Nutt,
2002). This outcome can be traced back
to a failure to create a consistent vision
for the service delivery aspect of the
project. For instance, the project’s orig-
inal director, Jennie Page, kept with
Labour’s vision in her treatment of the
exhibition as something other than a
sponsor-dominated “logo-land.” Her
replacement, Disneyland Paris’s P.Y.
21
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 22
Translation and Convergence in Projects
PAPERS
Gerbeau, was more than happy to see
sponsorship come to the fore in shap-
ing the experience—not least in the
form of clear and visible company logos
and PR messages (McGuigan &
Gilmore, 2002).
The varied and uncoordinated
nature of the private sector’s involve-
ment in the Dome created a confused
message ranging from a commentary
on national identity to an unrestrained
promotion of private interests. Thus,
while some companies, such as M&S
(the Self Portrait Zone), took a back seat
in terms of their zone’s content, others
ensured that their brand and influence
were predominant (such as
Manpower’s much-disliked Work
Zone). Other sponsors had a less
straightforward relationship with their
zone, such as Marconi, which saw an
opportunity to rebrand itself, and BAE
Systems, which sought to frame itself as
a promoter of engineering education.
Ultimately, the variable visibility of
corporate interests mixed uncomfort-
ably with the zone’s simultaneous focus
on education and the social commen-
tary of works displayed elsewhere, such
as the much-praised “Boy” and Peter
Gabriel’s show depicting the negative
effects of industrialization. Arguably,
this lack of project convergence around
a clearly articulated set of themes con-
tributed strongly to the weak impact of
the attraction (McGuigan & Gilmore,
2002). The attraction’s failure, therefore,
can be justifiably framed in terms of
NMEC’s failure to anticipate and con-
trol the shaping effects of its multiple
nodes (i.e., corporate sponsors).
The net result was that visitors, and
the press, were unclear as to what sense
they should take from the Dome
(McGuigan & Gilmore, 2002). While
around 86% of visitors reported being
satisfied with the attraction (NAO,
2000), it has been suggested that this
response reflects a dogged determina-
tion to enjoy the event despite press
criticism (McGuigan & Gilmore, 2002).
Opening night technical failures, along
with a somewhat flat exhibition,
22 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
The project map shows competing areas of convergence. While this is not enough to destabilize
the project it is enough to weaken its impact. No clear obligatory point of passage emerges – the
‘millennium experience’ never becomes a single believable object
“Spirit of confidence and
adventure” discourse
Designer-led
Sponsored work
NMEC under
Jennie Page
‘Critical’ Dome as
installations construction
Figure 1: Millennium Dome project.
ensured that the press, key to the pro-
ject’s success, were never on board.
In characterizing the event’s failure,
it is clear that a lack of focus on opera-
tions (as opposed to the completion of
“the project” as defined by the building)
and a lack of convergence around a
clear vision of what the project was sup-
posed to be resulted from a failure to
tackle the project’s multiple and diver-
gent nodes. In network terms, there was
a divergent, weak, and disaggregated
network, split between a construction
phase and a service phase and split by
the presence of alternative or compet-
ing discourses (Figure 1). In Burns and
Stalker’s terms, there was a project
organization that failed to crystallize
into an organic whole both through a
lack of management effort to create
opportunities for that to happen and as
a consequence of the varied and diver-
gent interests of the private sector.
The Eden Project
The Eden Project is the culmination of
one man’s extraordinary vision for a
project that would “promote the under-
standing and responsible management
“Selling ourselves
and our country” discourse
Corporate-focused
installations
Millennium NMEC under
Experience P.Y. Gerbeau
Dome as ‘Non-critical’
experience Installations
of the vital relationship between plants
and people and resources leading to a
sustainable future for all” (Eden Project
Mission, quoted in Prance, 2002). The
brainchild of Tim Smit, an entrepreneur
and the man behind the rediscovered
Lost Gardens of Heligan, which became
one of the leading tourist attractions in
Cornwall, the Eden Project consists of a
series of gigantic geodesic glasshouse
structures situated within the crater of a
disused china clay pit that house a series
of representations of different ecological
habitats from around the world.
The project was at the cutting edge
of architectural design and construction
technologies and required the building
of a complex partnership of funders,
commercial interests, architects, biolo-
gists, educators, and others to bring the
project to fruition. That it came togeth-
er at all speaks volumes for the network-
ing skills and persuasive powers of
the inspirational Smit. In his telling
of the story of the Eden Project, Smit
places great emphasis on the network-
ing activity necessary to build support for
the project, referring to having to make
“dozens of presentations throughout
17-30PMJ0808.qxd 8/8/11 12:17 PM
Smit and the site forms a
clear obligatory point of
passage. The project
appears ‘real’ and acts to
translate key players without
effort from Smit. Social
networking maintains
convergence as the project
develops.
Buy-in: Show-case
talent
Contractor
Buy-in:
demonstrable
local benefit
Public, local
authorities/planners
EU commission
Figure 2: The Eden Project.
1995, lunching until we dropped and
drinking for Britain, creating a back-
ground of support” (Smit, 2001). It is
easy to see the actor-network in action
here in a very conscious attempt at
enrollment and network building.
Achieving translation, of potential
funders in particular, involved numer-
ous intermediaries—the initial design
sketches, models of the glasshouse
structures, and other preliminary
items—but perhaps the most impor-
tant intermediary was the very site
itself. Smit recounts the visit of a group
of officials from the European
Commission who were enrolled in the
project through a site visit that involved
a hair-raising ride through the mud in a
four-wheel-drive vehicle (Smit, 2001).
Later, interest and support from anoth-
er crucial set of stakeholders, the pay-
ing public, was stimulated by inviting
people to view the progress of the proj-
ect from the vantage point of the visitor
center, and many returned subsequent-
ly to witness the completed project. The
site became a guarantee of the “realness”
Page 23
Thus, it can be argued that Smit
instinctively perceived the need to
build a convergent and organic project
Eden Project organization, a project in which every-
Site one had a stake and not just a role,
Cornwall
while at the same time recognizing the
Tangibility tireless work required to achieve this.
Buy-in: Professional
objectives served Smit similarly recognized the need
Project vision: to build and maintain external support
Biologists and
challenging structure, for the project—a “global” network to
jobs, education, educators
local tourism resource, use Law and Callon’s term (1992, p. 21).
sustainability The project required national bodies to
Buy-in:
Professional be brought on board, particularly those
challenge
Buy-in:
Architect
being asked to provide the funding for
Visitor
Strong the project. What was central to achiev-
revenue
influence
stream
London ing this was mobilizing the underlying
vision for the project. While this helped
Smit and core Banks and
project team financiers local actors to converge around the proj-
ect aims, it also inspired confidence in
Social networking the project’s stability and apparent con-
vergence among potential investors.
This, arguably, is where Smit’s strength
as an entrepreneur, innovator, and
visionary leader (Mullins, 2007) was crit-
ical. Under such circumstances, holding
of the project—the likelihood of com- the network together was a continual
pletion and other actors’ commitment, process and at various points during the
for the financiers, and the observable project considerable effort from Smit
benefits as a local resource for local and his team was necessary to keep fun-
people. ders on board and key actors aligned
Project success also required trans- around the project vision. In early 2000,
lation of local stakeholders through the the project needed additional financing,
securing of support from local resi- and considerable political maneuvering
dents, local authorities, and develop- was required to persuade the banks to
ment agencies. As Smit puts it: “[a] provide further loans in a context where
mountain of paperwork, a design team future viability had to, to some extent, be
from heaven and some up-country big taken on trust. Smit talks about a period
cheeses count for nothing in Cornwall when it was necessary to decamp from
without local support” (2001, p. 103). Cornwall to London to negotiate with
Achieving this required Smit and his the key project partners (Smit, 2001, p.
partners to: 223ff). Without such deliberate activity
to maintain the convergence in the proj-
trust in the democratic process and ect network, the Eden Project might well
not simply pay lip-service to it. This have gone the way of many other such
is hard work, requiring endless talk- endeavors.
ing and numberless meetings, but
The crucial feature of the vision he
there is no short cut to creating a
created for the Eden Project was that it
constituency of support . . . without
their [the local district council] sup-
served the interests of different parties
port the project would not have in different ways, while still retaining
happened. If your local community the overarching attributes of environ-
won’t back you, everyone else has an mental education and sustainability
exit. (Smit, 2001, pp. 61–63) (Figure 2). It made sense to the different
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 23
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 24
Translation and Convergence in Projects
PAPERS
stakeholders, viewed through their par-
ticular cognitive frames. For the local
development agency, it represented a
regeneration opportunity in a severely
depressed part of Cornwall following
the decline of the tin and china clay
industries. For the banks, it represented
a viable investment vehicle given the
convincing arguments for visitor num-
bers Smit was able to make. For the
architects, it represented the opportu-
nity to apply their interests in geodesic
designs, to showcase environmentally
sensitive design principles, and to
cement their reputation as architects.
For the construction companies, it was
an opportunity to showcase their capa-
bilities and to be associated with a proj-
ect that had the potential to break new
ground. Indeed, the Eden Project was
awarded the accolade of “Project of the
Decade” in 2007 at the Construction
News Quality in Construction Awards.
As Smit (2001, p. 159) says: “Eden was
never about plants and architecture, it
was always about harnessing people to
a dream and exploring what they are
capable of.” We would add that, once
work began, Eden formed a cluster of
tangible benefits and as such became,
alongside Smit, a tireless actor in the
work of translation.
Heathrow Terminal 5
Our interpretation of the project to
open a fifth terminal (T5) at Heathrow
Airport stresses again the importance
of project stability and convergence
around a stable frame. Critically, these
frames tell project participants which
trade-offs and risks are acceptable and
which are not. In the case of T5, it was
clear that what appeared to be a stable
frame around which a project network
had coalesced (the desire to create a
smooth passenger experience as the
terminal opened and British Airways
[BA] flights were migrated in) was in
fact in conflict with other demands.
These, as we shall argue, related to the
organizational prestige of the airport
owner, BAA Airports Limited (BAA), and
the broader operating requirements of
24 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
BA. These requirements destabilized
the project by prompting an ill-advised
decision to open the inadequately test-
ed terminal, leading to disastrous PR
for both organizations when the bag-
gage handling system failed. The even-
tual result of the failure was not only
measured in terms of short-haul UK
flights cancelled or the 28,000 bags that
were placed in temporary storage, but
also in terms of intense political embar-
rassment for those involved, particular-
ly for senior staff at BAA.
The building of a new terminal at
Heathrow Airport was a project of
national prestige and importance,
designed to ensure that Heathrow
cemented its place as one of the world’s
premier airports. The terminal’s con-
struction was a complex project
designed to handle 30 million passen-
gers per year through the provision of
60 new aircraft stands. The £4.3 billion
project involved 13 km of bored tun-
nels, two new terminal buildings, a new
spur road linking to the M25, a new air-
traffic control tower, a 4,000-space mul-
tistory car park, a 600-bed hotel and a
host of other buildings. Planning for the
project was begun in 1989 and con-
struction began in 2002. The terminal
opened slightly ahead of time on March
27, 2008, three days ahead of schedule,
and was delivered to cost (Brady &
Davies, 2010b). Within a month of
opening,, the terminal was functioning
beyond expectations at a level it was
not anticipated to reach until three
months into its operation (House of
Commons Transport Committee
[HCTC], 2008).
From the perspective of many, how-
ever, the most notable output of the T5
project was its disastrous first day. The
opening was described by one MP as
a “national embarrassment”: “You are a
very large organization, a foreign-owned
organization, and you made a fool out
of this country” (HCTC, 2008, p. 20).
The opening was also savaged in the
press. The project’s main failing
occurred in the baggage handling sys-
tem, which was overwhelmed by a
number of otherwise minor failures.
Security staff, arriving earlier and in
greater numbers than the system
expected, were not able to get into the
car parks. Baggage handlers, not only
late for work, were also insufficiently
familiar with the equipment. This unfa-
miliarity slowed the unloading rate. The
integrated monitoring system, recog-
nizing the potential for a “logjam,” did
what it was programmed to do and
refused to accept any more check-ins.
Software designed to read BA baggage
labels did not recognize transfer bag-
gage from other airlines—an unantici-
pated occurrence. Short-haul BA flights
were cancelled to take pressure off the
system, and 400 volunteers and man-
agers had to work around the clock to
fix things.
Brady and Davies (2010b) argued
that the failure of the baggage han-
dling system constitutes what Perrow
(1984) called a “normal accident”: an
accident that stems from the multilin-
earity and unpredictability of highly
complex systems. The difference with
this example, however, is that the
problems were predicted (though not
in their specific form) by the baggage
handlers’ union.
The outward confidence displayed
by BAA managers in the technology and
their own achievements prior to the
opening of the terminal (Brady & Davies,
2010b) was viewed as arrogance and
complacency by MPs and the press.
“Surely a company faced with real com-
petition would be less likely to make
basic and complacent mistakes such as
leaving staff without an overflow car
park on the most important day for
Heathrow for a decade,” complained the
then Shadow Transport Minister (Villias,
reported on theyworkforyou.com). This
confidence was all the more surprising
given that no airport has achieved trou-
ble-free start-up of baggage handling
systems, and that BAA was well aware of
this fact from its own research.
Brady and Davies (2010b) also
explained the failure as one of a lack of
integration in the final stages of the
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 25
Reputation
Systemic airport for project
requirements delivery
Hard to ignore
Open o
n time
Delay BAA
Downplayed Downplayed
Union concerns
about training
Previous
research suggesting
caution
Technological
Uncertainty
Figure 3: Terminal 5 project.
project’s delivery. Colin Mathews (BAA,
CEO) stated: “however well the airport
operator and the airline operator, BA,
are working, it is also vital that the two
are absolutely integrated. . . . Around
about or just prior to the opening of T5
it seems that that togetherness deterio-
rated.” He also reported to the commit-
tee that, given his time again, he “would
focus resolutely and determinedly on
keeping British Airways and BAA in the
same room tightly together” (Select
Committee on Transport, 2008). BAA, in
effect, took its eye off the ball, but it is
not clear why.
Certainly up until just prior to the
opening of T5, BAA’s project manage-
ment had been exemplary. They had for
some time been developing an “inte-
grated teams” approach to construc-
tion and applied this rigorously to the
T5 project (HCTC, 2008). Integrated
teams were based around partnering-
style arrangements with contractors
and designers to develop teams that
would work together on particular
aspects of projects over five-year peri-
ods, moving from project to project and
learning to work more effectively
(Brady & Davies, 2010a; Ivory, 2002).
Technological
hubris
Approaching
Physical
Infrastructure in flight
place season
Good communication
until the 11th hour
BA In the example
divergence is an ever
present threat as
competing objectives
(functioning terminal/
terminal delivered
Passenger
punctually) lead to risky
experience
decisions being taken.
Diverging objectives not
lack of communication
cause the failure. BAA
is left to make the
decision to open and
‘carry the can’.
BAA also encouraged co-location of
contractor and supplier staff to their
project sites and even took responsibil-
ity for career development and training.
All of this was designed to encourage
the sense that BAA was the employer
(Ivory, 2002). In T5, BAA, following the
lessons gleaned from its own research
into failed projects, also elected to take
on the lion’s share of the financial risks
of the project.
BAA was thus well versed in the
advantages of working closely with
partners and developing strong com-
munication, group working, and trust.
Yet this seemed to evaporate as opening
day approached. Mathews was keen to
stress his regret over this deterioration
in “togetherness” but did not explain
why the deterioration occurred. The
explanation may lie in another aspect
of complex technology systems—their
ability to carry contradictions.
Law (2000) has shown how tight
integration through the centralization
of control in complex technology sys-
tems may not solve operational con-
flicts. Complex systems carry conflicts
such as those between safe operation
and efficient operation, which can lead
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
to catastrophic failures. Failures can
occur as those within the system,
forced to continually work within the
compromises, begin to make poor and
overly risky decisions to keep the sys-
tem functioning. As argued in Ivory and
Alderman (2005), this observation can
usefully be applied to projects. The T5
project had a similar problem with con-
flicting objectives, although these con-
flicts were not evident at the outset. The
reluctance to delay the opening,
despite the potential operating prob-
lems that BA and BAA were aware of,
came from the top of BA, the main
stakeholder in the terminal: “In reality
the idea of delaying things by a month
was not necessarily an option that was
available to us. I think, in reality, what
we would have been considering was a
delay of a season, which is March to the
end of October” (Chief Executive BA,
HCTC, 2008). T5 was not a project in
isolation, but part of a transport system
with its own rhythms—in this case, cre-
ating pressure to open before the main
traveling season. Further pressure to
open on time came from the fact that
T5 was also part of a larger program of
projects surrounding the moderniza-
tion and growth of Heathrow. The late
opening of T5 would have meant delays
and extra costs for that program. T5 was
also a highly visible exemplar of BAA’s
competence as a project managing
organization, and BAA was under pres-
sure from its political enemies on the
right, many of whom (such as Villias)
saw the breakup of BAA as essential for
competitiveness. This was not a time to
hesitate. T5 was thus bound up in what
Suchman (1994) referred to as a “web of
effects,” a web from which it could not
really escape. Although throughout the
HCTC hearing BAA repeatedly referred
to the passenger as being at the heart of
what the project was about, this focus
was not strong enough to resist the
influence of these contrary demands:
the perceived reputational and finan-
cial damage of not opening on time
simply trumped the perceived risks of
so doing (Figure 3).
25
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 26
Translation and Convergence in Projects
PAPERS
The Scottish Parliament Building
The new Scottish Parliament Building
at Holyrood in Edinburgh, prompted by
the result of the devolution referendum
in September 1979, achieved consider-
able notoriety in both political and
public circles as a project bedevilled by
both time and cost overruns on a mas-
sive scale. Three years late, the original
estimate of a build cost of between £40
million and £50 million (Fraser, 2004)
had risen by an order of magnitude to
£431 million by the time the parliament
opened its doors to Scottish ministers
in September 2004 (“Holyrood Opens
for Business,” 2004). Yet long after the
debacle concerning the escalating costs
of the project and criticisms over its
management, the building itself won
the Stirling Prize for 2005 from the
Royal Institute of British Architects, and
by November 2004 had exceeded
100,000 visitors (Scottish Parliament,
2009) and completed a process of
regeneration of part of the Old Town of
Edinburgh (Scottish Parliament, 1998).
In retrospect, what the project achieved
was a landmark building for Scotland’s
Parliament.
The Scottish Parliament Building
was championed by the then Secretary
of State for Scotland, Donald Dewar.
The White Paper of July 24, 1997, made
it clear that this was to be a landmark
building “of such a quality, durability
and civic importance as to reflect the
Parliament’s status and operational
needs” (Scottish Parliament, 1998, p. 2)
and this was encapsulated in the design
brief issued to prospective design
teams. It seems almost certain that
these aspirations had a significant
influence on the eventual selection of
the Spanish architect Enric Miralles,
famous for his work in Barcelona,
Spain, and Utrecht, Holland, who, in
the words of Donald Dewar at the time
of the announcement, “impressed the
panel with his energy, imagination and
creative approach to designing a
Parliament building within the World
Heritage site at Holyrood” (Scottish
Parliament, 2009).
26 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Miralles subsequently came to have
a significant influence over the project,
in particular through his unwillingness
to compromise on quality. The intro-
duction to Lord Fraser’s inquiry report
records a handwritten note by Ian
McAndie, a partner at cost consultants
Davis, Langdon & Everest, from March
1999: “Nobody tells Enric to think about
economy with any seriousness” (Fraser,
2004, p. 8). Miralles was clearly a poten-
tially disruptive node within the project
network, whose way of working was not
consistent with the needs of a client
with a strict timetable and what subse-
quently transpired to be a vastly
overoptimistic budget.
The inquiry conducted by Lord
Fraser devoted most of its attention to
the conventional project management
approach to managing a complex
undertaking like this one. In particular,
Lord Fraser questioned the form of
contract adopted, Construction
Management, which in his view left the
client open to far too much risk in
terms of cost. It also focused on the
conventional triumvirate of time, cost,
and quality, concluding that quality
and completion were both preferred
over cost. What is clear is that the
desired quality and iconic statement of
the building could never have been
achieved within the original budget.
On the other hand, if this was the pri-
mary objective, the cost overruns
should not have been considered prob-
lematic. Either such a landmark build-
ing was worth paying for or it was not.
An actor-network perspective, how-
ever, suggests other factors also had
a significant impact on the project.
The choice of architect was clearly
controversial and led to a number of
allegations of excess, such as the widely
quoted reception desk that cost £88,000
alone (Design Build Network, 2009). In
fact, the design contract went not to
Enric Miralles alone, but to a joint ven-
ture between his architectural practice,
EMBT, and the Edinburgh architects
RMJM. The main interface with the
project occurred through RMJM in
Edinburgh, and the conceptual design
work took place in Barcelona. For the
project manager appointed, this dislo-
cation between cities proved difficult to
manage.
The evidence given to the Inquiry
makes it clear that the architectural
joint venture experienced difficulty in
making the arrangement work, owing
to a clash of personal and organization-
al styles: “there is an entirely different
cultural approach to the delivery of
buildings between Spain and the
United Kingdom. Enric himself had a
particular way of designing that was
less structured than one might find in a
major practice in the United Kingdom,
and those cultural differences create
operational tensions” (Fisher, quoted in
Fraser, 2004). It is also clear that the
design brief issued to the competing
design teams failed in its role as an
intermediary, in that Miralles chose to
ignore a number of the key require-
ments outlined in the brief—notably,
adherence to budget.
For the appointed project manager,
Bill Armstrong, this cultural difference
proved an impediment that his conven-
tional project management experience
was ill equipped to handle. The Inquiry
report states that the project manager
employed a highly structured approach
to project management and attempted
to impose that on other members of the
project team. In a conventional UK
construction context, this would have
been understood by architects and
contractors alike. However, it was not
appreciated by the Spanish architecture
practice and by Miralles in particular.
With regard to the communication
problems that were evident between
the project manager and the architects,
the following exchange is highlighted:
Mr. Campbell QC: I am trying to find
out, Mr. Armstrong, how much dia-
logue there was between the appoint-
ed designer, who succeeded in a com-
petition in July 1998, and you, the
Project Manager, charged with evolv-
ing the brief for the building, which
that designer was going to design.
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 27
UK design
team
Strong
influence
Limited
Secretary of High influence
state
impact
Scottish
Iconic building
Parliament
Limited
influence
Isolated
from
criticism
Project manager
Figure 4: The Scottish Parliament.
Mr. Armstrong: Very little.
Mr. Campbell QC: Looking back on
it, do you think that was the right
way to go about it?
Mr. Armstrong: It was not my
choice.
Mr. Campbell QC: That was not
what I asked you.
Mr. Armstrong: I think that is my
answer. (Fraser, 2004)
The project manager appears to
have been ill equipped to deal with the
issue of aligning the architect with the
client’s timescale and budget require-
ments. His strong-arm project manage-
ment approach is reflected in the
evidence of the civil servant Robert
Gordon, according to whom the project
manager “was taking a pretty firm line
with EMBT/RMJM and was sending
them increasingly strong letters. Now I
think that has a significant part to play
in robust project management, but I
was a bit concerned that he did not
seem to have a backup strategy and
that the proposition he was making was
that we would have to go for the
nuclear option of sacking the Design
Team, or at least sacking the EMBT part
The Spanish architect grabs the
initiative and never lets go – costs
rise. Scarce skills and lock-in
make the architect’s position
unassailable. The UK design team
Spanish is held in the architect’s thrall. The
project manager is powerless to
design team
influence and takes the flack for
failing to control costs. Parliament
Strong is allowed to escape public
influence scrutiny as a consequence
Higher cost
Project focus
Low impact
Lower cost
Press and public
criticism re.cost
High impact
of it if we did not get responses” (Fraser,
2004). The project sponsor, the civil ser-
vant Barbara Doig, under questioning,
expressed the position thus:
Mrs. Doig: Well, project managers
are replaceable.
Mr. Campbell QC: But architects are
not?
Mrs. Doig: The architect in this case
was not.
When he subsequently resigned,
the project manager reliably predicted
the financial chaos and delays that fol-
lowed. He understood the implications
of the actions of an uncontrollable proj-
ect node but appeared to lack the lever-
age to manage the situation, which
reflected the very different framing and
sense-making approaches of the archi-
tect and the project manager.
Of course, the tribulations of the
project should not be ascribed to a fail-
ure to align the chosen architect with the
goals of the project. Indeed, arguably
the architect was aligned with the proj-
ect vision, which was itself incompatible
with the more conventional economic
and temporal constraints placed on it by
a client concerned more with political
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
considerations than with project man-
agement implications. But as with many
politically motivated projects, the lack
of realism in the original budget may
well have reflected the desire and need
to build political support if the project
was ever to get off the ground (cf.
Flyvbjerg, Bruzelius, & Rothengatter,
2003), rather than to rely on conven-
tional economic arguments that could
have led to a solution within budget
and on time but which failed to provide
the landmark iconic emblem of a new
Parliament that “reflected the aspira-
tions of Scotland as a nation” (Scottish
Parliament, 1998).
This was an ostensibly divergent
network in which the two primary
nodes, the architect(s) and the project
manager, both tried to construct them-
selves as the obligatory points of pas-
sage for the project as a whole (Figure 4).
Both continued to function and both
tried to force the project through
entirely different “frames”—cost and
time on the one hand and quality on
the other. But this divergence, paradox-
ically, was the source of the project’s
stability. So long as it had a project
management structure, which was
apparently seeking to “gain control”
and “rein in costs,” the project’s poten-
tial enemies (the press, members of the
Scottish Parliament, public opinion)
were held in check while the project
drew on more and more resources. The
client, then, likely saw the design team
as the obligatory point of passage
rather than its own project manager.
The project remained stable so long as
everyone played their roles. The project
manager, realizing he was caught in the
project’s web, and without a “nuclear
option,” felt compelled to resign.
Discussion
Our reinterpretation of the four cases
through the lenses of actor-network
theory, sense making, and organiza-
tional structure reveals the role that
translation plays in achieving conver-
gence and, hence, relative stability for
the project. The successful translation
27
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 28
Translation and Convergence in Projects
PAPERS
Project Vision
Millennium Dome Weak and inconsistent
Eden Project Clear and shared
Terminal 5 Focused and shared, but
with inherent contradiction
Scottish Parliament Strong, but contradictory
Table 1: Case summary.
of actors in distant nodes underpins
success, while failure to do so exposes
the project to the effects of decisions
and actions potentially at variance with
the needs of the project (as defined by
the project management team, project
sponsor, or client). It is also clear that
conventional mechanisms for exchang-
ing knowledge, such as design briefs,
contracts, and the like, are not up to the
task of translation, as competing
frames override the intentions of those
issuing them. The process of transla-
tion needs active, often face-to-face,
management. Management styles that
bring project actors together, both in
physical and in conceptual space, are
required.
In Table 1, we summarize the four
case studies in terms of our interpreta-
tion of the strength of the project
vision, the organizational characteris-
tics of the project, and the nature of the
network, whether convergent or diver-
gent and in terms of the perceived
outcomes. It is clear from this that out-
comes are highly contingent, but that
weaknesses in one aspect of the project
can be overcome through expenditure
of effort elsewhere. Thus, a strong
vision for the Scottish Parliament
building produced the iconic structure
requested in the brief, albeit at substan-
tial cost and despite a divergent net-
work. Here a mechanistic organization
worked to the project’s advantage. On
the other hand, last-minute divergence
in the Terminal 5 network led to initial
failure, but the groundwork had been
done to ensure ultimate success. The
Millennium Dome exhibited both a
weak vision and a divergent network,
and the mechanistic organization was
28 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Organization
Mechanistic
Organic
Organic on the surface—
actually mechanistic
Mechanistic
unable to compensate. It is tempting to
conclude that the strong shared vision,
organic organization, and convergent
network of the Eden Project provides
the recipe for success, but it is clear that
this was only obtained through contin-
ual and substantial effort on the part of
the main protagonists.
Managing Complexity
If we accept that divergence is the
enemy of effective project completion,
then we can begin to formulate some
tentative ideas regarding the approach-
es managers might take to encourage
convergence:
1. Clear, consistent, and stable vision
from the outset. While visions might
change over time, management
should not allow visions to fragment
into competing versions of what the
project is about (e.g., the Dome).
While complete convergence around
a single vision might be impossible
(arguably the Eden Project is a
notable exception), the project vision
should provide a relatively stable
narrative that frames how these com-
peting demands should be ordered in
terms of priority. Changes in focus
can be disastrous, as the T5 case
showed. Questions around good
project management would concern
an examination of the circumstances
under which maintaining a stable
vision is possible.
2. Encouragement for convergent,
organic organizations. Convergent
networks are analogous to Burns and
Stalker’s (1961) description of the
organic organization. Organic organi-
zational forms, in contrast to mecha-
nistic forms, stress the importance of
Outcome Network
Failure Divergent
Success Convergent
Initial failure Convergent then
(ultimate success) diverged
Success at a cost Divergent
communication and coordinated
responsiveness to changing
demands. This is something that
BAA’s integrated teams have sought
to achieve. One of the critical aspects
of organic organizations, and what
allows them to function so effectively
even in unstable environments, is
the shared and unswerving focus of
its managers on the goals of the
organization. Regular and frequent
meetings, as Burns and Stalker note,
are essential in order to maintain
that shared focus.
3. Identifying and acting on likely
points of divergence. Once there is a
clearly definable vision of what the
project is about, then project nodes
should be considered in terms of
their likely divergence and what
might be done about this. BAA has
sought a form of administrative verti-
cal integration through integrated
teams to prevent nodes forming.
Others have reached out to distant
nodes using visual media to reshape
how they think about the project, or
have acted to bring those making
decisions at a distance literally to the
project (as with the Eden Project). In
network theory, this is referred to as
“control at a distance”; it is the key
role of the mobile network interme-
diary.
Achieving convergence, we should
stress, is a continual process. A conver-
gent project does not reach an end state
but has to be continually “managed” in
order to hold the project network in
alignment and to prevent countervail-
ing tendencies toward divergence.
Convergence is thus an inherently
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 29
unstable achievement that requires
ongoing management vigilance and
intervention (i.e., network building).
Conclusion
In this article, we have suggested that
concepts and propositions from a
number of areas of theoretical develop-
ment in the social sciences offer the
potential to inform project manage-
ment reform in ways that could shed
light on managing complex projects.
While a growing number of contribu-
tions in the literature apply one or
another of these perspectives, this arti-
cle suggests that a combination of these
ideas can provide a richer picture of the
operation of complex projects. It is sug-
gested that different actors have to be
enrolled (or translated) into the project
network, but that this only results in
genuine convergence when sense mak-
ing between those actors is brought
into alignment. It follows that the sense
that is made of new requirements and
knowledge needs to be clearly articulat-
ed and then re-articulated throughout
the life of the project. This article has
outlined a number of means for achiev-
ing this.
Acknowledgments
This article develops ideas first present-
ed at the European Academy of
Management Conference (EURAM) in
Liverpool in May 2009, and we
acknowledge the contributions of Ian
McLoughlin and Roger Vaughan to that
original formulation. Our thanks also
go to the participants at EURAM for
their comments and questions.
Particular thanks are also due to Tim
Brady for discussions about the
Heathrow Terminal 5 project and for
supplying the prepublication papers
referred to here. ■
References
Alderman, N., Ivory, C. J., McLoughlin,
I. P., & Vaughan, R. (in press).
Managing complex projects: networks,
knowledge and integration. London:
Routledge.
Association of Project Management
(APM). (2006). Body of knowledge.
Buckinghamshire, UK: Author.
Bijker, W., & Law, J. (1992). Do tech-
nologies have trajectories? In W. Bijker &
J. Law (Eds.), Shaping
technology/building society: Studies in
sociotechnical change (17–20).
Cambridge, MA: MIT Press.
Brady, T., & Davies, A. (2010a).
Learning to deliver a mega-project:
The case of Heathrow Terminal 5. In N.
Caldwell & M. Howard (Eds.),
Procuring complex performance: Cases
of product-service innovation (pp.
174–195). New York: Routledge.
Brady, T., & Davies, A. (2010b). From
hero to hubris: Reconsidering the proj-
ect management of Heathrow’s
Terminal 5. International Journal of
Project Management, 28(2), 151–157.
Buchanan, D., & Boddy, D. (1992). The
expertise of the change agent: Public
performance and backstage activity.
London: Prentice Hall.
Burns, T., & Stalker, G. M. (1961). The
management of innovation. London:
Tavistock.
Callon, M. (1980). Struggles and nego-
tiations to define what is problematic
and what is not: The sociology of trans-
lation. In K. D. Knorr-Cetina, R. Krohn,
& R. Whitely (Eds.), The social process
of scientific investigation (pp. 197–221).
Dordrecht, the Netherlands, and
Boston, MA: Reidel.
Callon, M. (1986). The sociology of an
actor-network: The case of the electric
vehicle. In M. Callon, J. Law, & A. Rip
(Eds.), Mapping the dynamics of science
and technology (pp. 119–134). London:
Macmillan Press.
Design Build Network. (2009). Scottish
Parliament Building, Edinburgh,
United Kingdom. Retrieved from
http://www.designbuild-network
.com/projects/scottparliament/
Flyvbjerg, B., Bruzelius, N., &
Rothengatter, W. (2003). Megaprojects
and risk: An anatomy of ambition.
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Cambridge, UK: Cambridge University
Press.
Fraser, P. (2004). The Holyrood inquiry.
Scottish Parliament Corporate Body,
Paper 205. Edinburgh: Scottish
Parliament.
Gephart, R. P. (1993). The textual
approach: Risk and blame in disaster
sense making. Academy of
Management Journal, 36, 1465–1514.
Hodgson, D., & Cicmil, S. (Eds.).
(2006). Making projects critical.
Basingstoke, UK: Palgrave Macmillan.
Holyrood opens for business. (2004).
BBC. Retrieved from
http://news.bbc.co.uk/go/pr/fr/-
/1/hi/scotland/3633104.stm
House of Commons Transport
Committee (HCTC). (2008). The open-
ing of Heathrow Terminal 5, twelfth
report of Session 2007–2008. Report,
together with formal minutes, oral and
written evidence (ordered by the
House of Commons to be printed
October 22, 2008).
Ivory, C. J. (2002). Innovation and dif-
fusion in the UK construction industry
(Unpublished doctoral thesis).
University of Manchester, Manchester,
UK.
Ivory, C. J., & Alderman, N. (2005). Can
project management learn anything
from studies of failure in complex sys-
tems? Project Management Journal,
36(3), 5–16.
Kaynes, C. (2005). The destructive pur-
suit of idealized goals. Organization
Dynamics, 34(4), 391–401.
Latour, B. (1990). Drawing things
together. In M. Lynch & S. Woolgar
(Eds.), Representation in scientific prac-
tice (pp. 19–68). Cambridge, MA: MIT
Press.
Latour, B. (1996). Aramis or the love of
technology (C. Porter, Trans.).
Cambridge, MA: Harvard University
Press.
Latour, B. (2007). Reassembling the
social: An introduction to actor-net-
work theory. New York: Oxford
University Press.
29
17-30PMJ0808.qxd 8/8/11 12:17 PM Page 30
Translation and Convergence in Projects
PAPERS
Law, J. (1992). Notes on the theory of
the actor-network: Ordering, strategy,
and heterogeneity. Systemic Practice
and Action Research, 5(4), 379–393.
Law, J. (1994). Organizing modernity.
Oxford, UK: Blackwell.
Law, J. (2000). Ladbroke Grove, or how
to think about failing systems.
Lancaster, UK: Centre for Science
Studies, Lancaster University.
Retrieved from
http://www.comp.lancs.ac.uk
/sociology/papers/law-ladbroke-grove
-failing-systems.pdf
Law, J., & Callon, M. (1992). The life
and death of an aircraft: A network
analysis of technical changes. In
W. Bijker & J. Law (Eds.), Shaping tech-
nology/building society: Studies in
sociotechnical change (pp. 21–52).
Cambridge, MA: MIT Press.
Lee, N., & Hassard, J. (1999).
Organization unbound: Actor network
theory, research strategy and institu-
tional flexibility, Organization, 6(3),
391–404.
Linde, A., & Linderoth, H. C. J. (2006).
An actor network theory perspective
on IT projects. In D. Hodgson & S.
Cicmil (Eds.), Making projects critical
(pp. 155–170). Basingstoke, UK:
Palgrave Macmillan.
McGuigan, J. (2003). The social con-
struction of a cultural disaster: New
Labour’s millennium experience.
Cultural Studies, 17(5), 669–690.
McGuigan, J., & Gilmore, A. (2002).
The Millennium Dome: Sponsoring,
meaning and visiting. International
Journal of Cultural Policy, 8(1),
1–20.
Mullins, L. J. (2007). Management and
organizational behaviour (8th ed.).
Harlow, UK: FT, Prentice Hall.
National Audit Office (NAO). (2000).
The Millennium Dome. Retrieved from
http://www.nao.org.uk/publications
/9900/the_millennium_dome.aspx
30 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Nutt, P. (2002). Why decisions fail:
Avoiding the blunders and traps that
lead to debacles. San Francisco, CA:
Berrett-Koehler.
Perrow, C. (1984). Normal accidents:
Living with high risk technologies.
Princeton, NJ: Princeton University
Press.
Prance, G. T. (2002). A paradise for eco-
nomic botanists: The Eden Project.
Economic Botany, 56(3), 226–230.
Project Management Institute. (2004).
A guide to the project management
body of knowledge (PMBOK ® guide).
Newtown Square, PA: Author.
Scottish Parliament. (1998). The
Scottish Parliament Building user brief,
part 1. Edinburgh: Author.
Scottish Parliament. (2009). Holyrood
Building, project history. Retrieved
from http://www.scottish.parliament
.uk/vli/holyrood/projHistory/
Select Committee on Transport.
(2008). Minutes of evidence.
Examination of witnesses (question
numbers 280–299).
Smit, T. (2001). Eden. London: Corgi
Books.
Suchman, L. (1994). Working relations
of technology production and use.
Computer Supported Co-operative
Work, 2, 21–39.
Thomas, J. (2000). Making sense of
project management. In R. A. Lundin &
F. Hartman (Eds.), Projects as business
constituents and guiding motives
(pp. 25–43). Boston: Kluwer Academic
Press.
Weick, K. E. (1979). The social psychol-
ogy of organizing (2nd ed.). London:
McGraw-Hill.
Weick, K. E. (1993). Sensemaking in
organizations: Small structures with
large consequences. In J. K. Murnighan
(Ed.), Social psychology in organiza-
tions: Advances in theory and research
(pp. 10–37). New York: Prentice Hall.
Weick, K. E. (1995). Sense making in
organizations. Thousand Oaks, CA:
Sage.
Weick, K. E. (2001). Making sense of the
organization. London: Blackwell.
Wiley, N. (1988). The micro-macro
problem in social theory. Sociological
Theory, 6, 254–261.
Winter, M., & Smith, C. (2006).
Rethinking project management.
EPSRC Network 2004–2006 final report.
Retrieved from http://www.ronrosen
head.co.uk/wp-content/uploads
/2008/05/rethinking-project-
management1.pdf
Wynne, B. (1988). Unruly technology:
Practical rules, impractical discourses
and public understanding. Social
Studies of Science, 18(1), 147–167.
Neil Alderman is a senior lecturer at Newcastle
University Business School. His background is
as a geographer. His research interests include
the management of complex projects, the man-
agement of product development projects, par-
ticularly in engineer-to-order companies, and
the process of innovation in large-scale projects.
He is a member of the British Academy of
Management and the European Academy of
Management, and a fellow of the Royal
Geographical Society (with the Institute of
British Geographers).
Chris Ivory is a senior lecturer at Newcastle
University Business School. His background is
as a social scientist. His research interests
include innovation and technology manage-
ment, history of technology, critical manage-
ment approaches to project management, and
the management of complex projects. He is a
member of the British Academy of Management
and the European Academy of Management. He
is also an Advance Institute of Management
(AIM) scholar.
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 31

PAPERS
The Relationship Among Systems
Engineers’ Capacity for Engineering
Systems Thinking, Project Types,
and Project Success
Moti Frank, HIT—Holon Institute of Technology, Faculty of Management of Technology,
Holon, Israel
Arik Sadeh, HIT—Holon Institute of Technology, Faculty of Management of Technology,
Holon, Israel
Sharon Ashkenasi, IMI—Israel Military Industries, Rocket System Division,
Ramat Hasharon, Israel

ABSTRACT ■
In recent years, systems engineering and Project
Management Bodies of Knowledge have been rapidly
growing. However, despite the vast amount of literature
available on systems engineering and project manage-
ment, about two-thirds of all projects still fail. A review of
both project management and systems engineering pub-
lications reveals that most of these works focus on
processes. We suggest focusing on people—project man-
agers and systems engineers. One of our previous studies
dealt with project managers; this article focuses on sys-
tems engineers. This article presents findings of a study
aimed at exploring the relationship among systems engi-
neers’ capacity for engineering systems thinking (CEST),
project types, and project success. The instrument used
in this study was a self-report questionnaire, composed
of three parts. The first part assessed the participants’
CEST, the second part assessed several measures of proj-
ect success, and the third part assessed four dimensions
of project type. The simple random sampling method was
used, and the sample included 114 senior systems engi-
neers who were randomly selected from the sampling
frame. The study findings show that there is a statistical-
ly significant correlation between CEST and project suc-
cess. The extent of the project’s novelty, complexity, and
technological uncertainty are moderator variables that
affect this correlation.
KEYWORDS: systems thinking; capacity for
engineering systems thinking (CEST); systems
engineering; project success; project types
Project Management Journal, Vol. 42, No. 5, 31–41
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20252
INTRODUCTION ■
ccording to the Standish Group report (2009), 68% of all projects
A failed. Forty-four percent of the projects were late, had an over-
planned budget, and/or had fewer than the required features and
functions. In addition, 24% were cancelled prior to completion or
delivery and never used. Only 32% of all projects succeeded—that is, were
delivered on time, remained within the planned budget, and had the
required features and functions.
Numerous studies have been conducted in an attempt to answer the fol-
lowing question: What causes projects to fail? Many reasons have been found.
We present only three examples. In a survey conducted among 256 UK compa-
nies, it was found that 32% of information technology (IT) projects failed due to
poor project management, 20% due to a lack of communication, 17% due
to the failure to properly define objectives and requirements, 17% due to
unfamiliar project scope or complexity, and 14% due to the inability to cope
with new technology (KPMG, 2001). According to another survey (ProjTech,
2003), the main reasons for project failure were incorrect requirements,
insufficient planning, poor risk mitigation, and use of incorrect technical
solutions. In a study conducted by Standing, Guilfoyle, Chad, and Love
(2006), it was found that the top five reasons for IT project failure were lack
of user support and involvement, lack of properly defined project scope,
lack of executive management support and commitment, imprecisely
defined objectives, and poor project management and leadership.
On the other hand, many studies try to identify what causes projects
to succeed. The search for factors that lead to better project performance
and success spans many years of research. A literature review (e.g., Chua,
Kog, & Loh, 1999; Dvir, Raz, & Shenhar, 2003; Holland & Light, 1999; Nah &
Lau, 2001; Pinto & Slevin, 1988) reveals that the top ten critical success fac-
tors to ensuring project success are clearly defined objectives and require-
ments, top management support and involvement, proper planning,
vendor and customer involvement and partnership, appropriate staff
selection and training, the existence of the required technology, customer
and end-user satisfaction, good control, monitoring and feedback, and
high levels of communication and proper risk management. A Guide to the
Project Management Body of Knowledge (PMBOK® Guide) (2008) provides

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 31

31-41PMJ0808.qxd 8/8/11 2:25 PM Page 32
Engineering Systems Thinking, Project Types, and Project Success
PAPERS
general guidelines for better project
management.
Systems engineering is an interdis-
ciplinary field of engineering that
mainly, but not only, relates to design and
management of complex engineering
projects. Systems engineering overlaps
with both technical and human-
centered disciplines, such as electrical
engineering, mechanical engineering,
computer science, control engineering,
industrial engineering, organizational
studies, and project management. Many
definitions for the term systems engi-
neering can be found in the literature,
including several official definitions
(e.g., International Council on Systems
Engineering, 2004, 2010; National
Aeronautics and Space Administration,
2007).
The systems engineering and proj-
ect management bodies of knowledge
have experienced rapid growth in
recent years. A huge number of scho-
larly books and papers have been
published, many tools are offered by
various vendors, and an impressive
number of conferences related to sys-
tems engineering are held every year.
Yet, despite the vast amount of project
management and systems engineering
literature available, about two-thirds of
all projects still fail (Standish Group,
2009).
Upon reviewing both project man-
agement and systems engineering
standards, papers, books, conference
proceedings, and tool manuals, it
appears that most of this material
focuses on processes. For example, ISO
15288, IEEE 1220, EIA 632, CMMI, the
INCOSE Handbook, and the PMBOK®
Guide (Project Management Institute,
2008) are all process-centered. The
common systems engineering and
project management tools offer better
ways to manage processes. We suggest
focusing, instead, on people—project
managers and systems engineers. In
their research, Dvir, Sadeh, and
Malach-Pines (2006) deal with project
managers; in this article, we focus on
systems engineers.
32 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Findings regarding the competen-
cies of successful systems engineers
have been reported in the systems engi-
neering literature (i.e., Arnold, 2006;
Derro & Williams, 2009; Frank, 2006;
International Council of Systems
Engineering, United Kingdom Chapter
[INCOSE UK], 2010; Jet Propulsion
Laboratory, 2006). However, most of
these works do not distinguish among
different types of projects or attempt to
match the competencies of successful
systems engineers to specific types of
projects and project performance or suc-
cess. In this article, we present findings of
a study aimed at exploring the relation-
ship among systems engineers’ capacity
for engineering systems thinking (CEST),
project types, and project success. Since
we deal here with three components—
(1) capacity for engineering systems
thinking (CEST), (2) project types, and
(3) project success—we will begin by
explaining these terms.
Capacity for Engineering Systems
Thinking
Systems thinking, according to Senge
(1994), is a discipline for seeing wholes.
Engineering systems thinking is a major
high-order thinking skill that enables
individuals to successfully perform sys-
tems engineering tasks. To successfully
perform systems engineering roles, sys-
tems engineers need a systems view or
a high capacity for engineering systems
thinking. It was found that this ability is
a consistent personality trait, and that it
can be used to distinguish between
individual engineers. Systems engi-
neers with high CEST are more capable
of (1) analyzing customers’ needs and
requirements, (2) developing the con-
cept of operation, (3) conceptualizing
the solution, (4) generating a logical
solution (functional analysis) and
a physical solution (architecture syn-
thesis), (5) using simulations and
optimization, and (6) implementing
systems design considerations and
conducting trade studies wherein it is
necessary to generate several alterna-
tive solutions.
In organizations and projects, there
are many different kinds of job posi-
tions that may be included in the sys-
tems engineering category. Different
positions require different competen-
cies, characteristics, abilities, traits, and
attributes. Despite this fact, it was
found that a set of core characteristics,
abilities, traits, and attributes does in
fact exist, and is required of all systems
engineers, independent of their specif-
ic position. Fourteen cognitive charac-
teristics, twelve capabilities, nine
behavioral competencies, and three
items related to education, background,
and knowledge were found (Frank,
2006). A tool for assessing the CEST of
systems engineers was built based on
these findings (Frank, 2010). This tool
was used in the study presented later in
this article for assessing the CEST of the
study participants.
Project Classification
One of the common misconceptions
regarding projects is that all projects are
the same, and similar tools can be used
for all project activities. In reality, proj-
ects differ in many ways. Indeed, sever-
al authors have criticized the universal,
“one-size-fits-all” idea and recom-
mended a more contingent approach
to the study of projects. Because proj-
ects can be seen as temporary organi-
zations within organizations, in order
to understand project classification, it
is advised to first refer to organization
theories (Dvir et al., 2006).
Classical contingency theory asserts
that different external conditions might
require different organizational charac-
teristics, and that the effectiveness of
the organization is contingent upon the
amount of congruence or goodness of
fit between structural and environmen-
tal variables (Drazin & Van de Ven, 1985;
Lawrence & Lorsch, 1967; Pennings,
1992). While correlations of structural
and environmental attributes have
been studied extensively when the
organization is the unit of analysis,
these have been investigated far less
within the context of projects. Project
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 33
management literature has often
ignored the importance of project con-
tingencies. Any search for a framework
for categorizing projects must address
the case of projects that are temporary,
part of an organization and its culture,
and performing new tasks that have not
been done before. In addition, such a
framework should be context-free and
independent of any particular industry
or organization (Dvir et al., 2006).
Shenhar and Dvir (2007) identified
four dimensions to distinguish among
projects: novelty, technology/uncertainty,
complexity, and pace. Together, these
four dimensions create the NTCP
Model (novelty, technology/uncertain-
ty, complexity, and pace) and form a
context-free framework for selecting
the proper management style.
1. Novelty: This dimension refers to how
new the product is to its potential
users. There are three levels in this
dimension: derivative projects pro-
duce new products that present only
modest improvements relative to
older products; platform projects
produce a new generation of prod-
ucts; and breakthrough projects
demand the highest level of innova-
tion management.
2. Technology/Uncertainty : Different
projects present, at the outset, differ-
ent levels of uncertainty (mainly tech-
nological uncertainty), and project
execution can be seen as a process
aimed at uncertainty reduction.
Uncertainty determines, among other
things, the length and timing of
front-end activities, how well and
how fast one can define and finalize
product requirements and design, the
degree of detail and extent of plan-
ning accuracy, and the level of con-
tingency resources.
3. Complexity: Project complexity
depends on product scope, number
and variety of elements, and the inter-
connection among them. The level of
complexity will determine the organi-
zation and the process, as well as the
formality with which the project will
be managed.
4. Pace: This dimension involves the
urgency and criticality of time goals.
The same goal with different time
constraints may require different
project structures and different man-
agement attention.
This NTCP model can guide project
managers and systems engineers in
selecting their project management
style during project initiation, recruit-
ing team members, structure, process-
es, and tools. A profile can be portrayed
for each project. The shape produced
is like a diamond (in fact, this model is
sometimes called the diamond model).
For example, the diamond profile of a
project for developing a platform sys-
tem that is high-tech and time-critical
Technology
Array System Assembly
Complexity
Regular
Fast/
Competitive
Time-Critical
Blitz
Source. Dvir et al. (2006).
Figure 1: The NTCP framework.
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
is depicted in Figure 1. This model was
used in the study presented later in this
article for project classification.
Assessment of Project Success
According to Dvir et al. (2006), most
projects are conceived with a business
perspective in mind, and often with a
goal that focuses on better results and
organizational performance—more
profits, additional growth, and an
improved market position. Ironically,
however, when project managers, sys-
tems engineers, and project teams are
engaged in day-to-day project execu-
tion, they are typically not focusing on
the business aspects. Their attention,
rather, is operational, and their mind-
set is on “getting the job done.” Most
Super-High
Tech
High-Tech
Medium-Tech
Low-Tech
Novelty
Derivative Platform Breakthrough
Pace
33
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 34
Engineering Systems Thinking, Project Types, and Project Success
PAPERS
project managers and systems engi-
neers see their job as being successfully
completed when they finish the project
on time, within budget, and according
to specifications. This operational
mindset is clearly reflected in the proj-
ect management literature, which has
traditionally used time, budget, and
performance as the main indicators of
project success. Any of these measures,
however, even when taken together, are
incomplete and may be misleading.
They may count as successful projects
that met time and budget constraints
but did not meet customer needs and
requirements, or projects that experi-
enced great difficulties in the commer-
cialization process of the final product.
Several prior studies have suggested
adding new elements to the assessment
of project success, such as stakehold-
ers’ satisfaction (Baker, Murphy, &
Fisher, 1988); efficiency of the imple-
mentation process and the perceived
value of the project (Pinto & Mantel,
1990); technical performance, efficien-
cy of execution, managerial and organi-
zational implications, personal growth,
and business performance (Freeman &
Beale, 1992); financial performance, the
creation of new opportunities for new
products and markets, and market
impact (Cooper & Kleinschmidt, 1987);
and meeting design goals, benefit to the
end-user, benefit to the developing
organization, and benefit to the
defense and to both the firm and
national infrastructure (Sadeh, Dvir, &
Shenhar, 2000).
Method
The Instrument
The instrument is a self-report ques-
tionnaire composed of three parts. The
first part (A) assessed systems engi-
neers’ capacity for engineering systems
thinking, the second part (B) assessed
project success, and the third part
(C) identified project type.
Part A: Assessing CEST
The selection process for systems engi-
neering positions should reliably predict
34 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
those employees who can succeed, and
reject those who are likely to fail. Out of
the employees who can succeed as sys-
tems engineers, it is necessary to choose
those who have the highest chance of
succeeding. Since no selection process
is perfect, two types of errors are possi-
ble: (1) choosing candidates that fail after
they have been placed and (2) rejecting
candidates who might have succeeded.
These errors have an influence on both
the organization and the individual.
From the organization’s point of view,
rejection of candidates who could have
succeeded in systems engineering
positions can be critical, especially
under conditions of an ever-increasing
shortage of systems engineers. Like-
wise, placing engineers in systems
engineering positions in which they
later fail is also an expensive error, tak-
ing into consideration the necessary
training that has been invested and the
subsequent damage that might be
caused to the projects in which they are
involved.
It was found that the threshold con-
dition for success in a systems engineer-
ing position is the will or desire to become
a systems engineer. People may want a
position for any number of reasons, both
external (salary, work conditions, bonus-
es, etc.) and internal (a challenge, satis-
faction, etc.), but it was found that one of
the main reasons is interest in the posi-
tion. In addition, one must possess the
ability to take a systems view (or, in other
words, the engineer needs to possess a
high level of engineering systems think-
ing skills). Thus, the three components
discussed here—success in a systems
engineering position, an interest in
systems engineering positions, and
the capacity for engineering systems
thinking—are all interconnected and
interrelated. The will and interest to be a
systems engineer basically means the
desire and interest to be involved with
job positions that require CEST. Frank
(2010) introduced a tool for assessing
engineers’ interest regarding systems
engineering positions and provided
results from three studies aimed at
examining its reliability and validity.
Interest inventory is a very common tool
that is frequently used to help people
choose a profession. It is also used as a
selection tool (to determine whether a
certain individual is suitable for a cer-
tain role) in the recruiting process
(Anastasi, 1988). This tool was used
in the current study and served as Part A
of the study’s instrument.
Usually, the items in interest inven-
tories deal with preferences, specifical-
ly likes and dislikes regarding a diverse
group of activities, jobs, professions, or
personality types. Likewise, the items
included in Part A of the instrument
discussed in this article refer to ranges
of likes and dislikes regarding systems
engineering activities (i.e., leading inte-
gration teams, conducting systems
analyses, etc.), various disciplines and
knowledge required from systems engi-
neers (interdisciplinary knowledge,
deep and detailed knowledge, etc.), sys-
tems engineering activities (i.e., leading
and participating in design reviews,
dealing with the whole system, etc.),
and types of people involved in projects
(i.e., customers, stakeholders, etc.).
Sample items of the tool (Part A of the
questionnaire used in the current
study) are presented in Frank (2010).
In its present version, the tool (Part A
of the questionnaire in the current
study) is composed of 40 pairs of state-
ments. For each pair, the examinee has
to choose between the two statements,
based on preference. The examinee
checks answer “A” if the first statement
is preferred, answer “B” if the second
statement is preferred, or answer “C” if
none of the above or both of the above
are preferred. In order to improve the
questionnaire’s reliability, questionnaire
items were reorganized, so in some
cases “A” represented the systems think-
ing answer, and in other cases “B” repre-
sented the systems thinking answer.
Each “A” answer received 2.5 points,
while each “B” answer received no
points. Thus, the range of the score in
this part for each participant was 0–100.
To simplify the statistical analyses, we
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 35
divided the subjects’ scores into three
groups: group 1: 0–59 (low CEST), group
2: 60–79 (medium CEST), and group 3:
80–100 (high CEST). Table 1 presents
the mean score of each group. A statisti-
cally significant difference among the
three groups was found in analysis of
variance (ANOVA) and post-hoc tests.
Part B: Assessing Project Success
Project success was measured along
four dimensions representing different
points of view that were validated in
previous research on defense projects
by Lipovetsky, Tishler, Dvir, and
Shenhar (1997) (see Table 2):
1. Meeting planning goals (project effi-
ciency),
CEST Group Mean
1 46.94
2 72.28
3 84.67
Total 76.80
Table 1: CEST scores in the current study.
Success Dimensions
Meeting design goals
Benefit to the end-user
Benefit to the developing
organization
Benefit to the community,
and national infrastructure
Table 2: Success dimensions and measures.
2. Customer benefits (success from the
customer’s point of view),
3. Benefits to the developing organiza-
tion, and
4. Benefit to the community and
national infrastructure.
Shenhar and Dvir (2007) added a
fifth dimension—benefit to the project
team. Based on these five dimensions,
they composed a reliable and valid tool for
assessing project success. Part B of the
questionnaire was based on this tool. This
part was composed of 28 items (Likert 1–5
scale), divided into five groups: meeting
design goals (items 1–4, the mean score
marked as Efficiency), benefit to the cus-
tomer and end-user (items 5–9, the mean
N SD
9 9.745
45 4.909
60 5.094
114 11.902
Success Measures
Functional specifications
Technical specifications
Schedule goals
Budget goals
Meeting acquisition goals
Answering the operational need
Product entered service
Reached the end-user on time
Product had a substantial time for use
Meaningful improvement of user operational level
User is satisfied with product
Relatively high profit
Opened a new market
Created a new product line
Developed a new technological capability
Increased positive reputation
Contributed to critical subjects
Maintaining a flow of updated generations
Decreasing dependence on outside sources
Contribution to other projects
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
score marked as Customer), benefit to the
project team (items 10–16, the mean score
marked as Team), benefit to the develop-
ing organization (items 17–20, the mean
score marked as Business), and benefit to
the national infrastructure (items 21–28,
the mean score marked as Future). The
overall success of a given project is the
mean of all the items’ scores.
Part C: Identifying Project Type
The NTCP model (Shenhar & Dvir, 2007)
for classification, portraying the project
and building a specific profile for each
project in the sample was used in this
study. The four dimensions in the classi-
fication framework—novelty, technolo-
gy, complexity, and pace—are described
by four ordinal variables; each dimen-
sion included at least three different
project types (see Figure 1). Part C of the
questionnaire was based on this model
and was found to be reliable and valid by
Dvir et al. (2006). This part was com-
posed of four items according to the four
dimensions of the NTCP model. For
each dimension, the respondents had to
choose the answer that best describes
the project they are referring to. For
example, item 15 refers to novelty and
has three answers—derivative, platform,
and breakthrough. To simplify the statis-
tical analyses, we scored the answers.
For example, the answer “derivative” got
one point, the answer “platform” got two
points, and the answer “breakthrough”
got three points. Then, we summed the
scores of the four items and divided
the results into three groups. The highest
score was given to a “breakthrough—
super-high-tech—array (system of sys-
tems)—blitz” project.
Participants
The study population included all sen-
ior systems engineers employed in the
“high-tech—electronics—systems”
industry in Israel. It was impossible to
survey the entire population because
the high-tech population is very
dynamic and also because this type of
survey would be very costly.
Consequently, we determined a
sampling frame that enabled us to
35
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 36
Engineering Systems Thinking, Project Types, and Project Success
PAPERS
identify every single senior systems
engineer included in it. The sampling
frame included all senior systems engi-
neers employed in the 16 largest high-
tech electronics system companies in
Israel. It is well known that a study’s
sampling frame must be representative
of the population; this is a question
beyond the scope of statistical theory,
requiring the judgment of experts in
the particular field under examination.
In our case, according to data received
from the Manufacturers Association of
Israel, the sampling frame includes
roughly 90 % of the high-tech electrical
engineers in Israel. Thus, no subjective
judgment of experts was needed.
We used the simple random sam-
pling method: the sample size consist-
ed of 114 senior systems engineers who
were randomly selected from the sam-
pling frame (sampling error 9.18%, p ⱕ
0.05). About 40% of the survey’s partici-
pants were from the defense industry.
Projects
The projects that were involved in the
study can be classified, according to the
NTCP model, as follows:
• Novelty: Fifty-four subjects were
engaged in platform projects, 30 in
derivative projects, and 30 in break-
through projects.
• Technology: Eleven subjects were
engaged in super-high-tech projects,
65 in high-tech projects, 26 in medi-
um-tech projects, and 12 in low-tech
projects. We can see that about 67 per-
cent (two-thirds) of the subjects were
Efficiency
Pearson Correlation 0.249**
Sig. (2-tailed) 0.008
N 114
Note. Efficiency—meeting design goals (Items 1–4 of Part B). Customer—benefit to the customer and end user (Items 5–9 in Part B). Team—benefit to the project team
(Items 10–16 in Part B). Business—business benefits to the developing organization (Items 17–20 in Part B). Future—benefit to the organization and national infrastruc-
ture (Items 21–28 in Part B). PR_Succ—mean score of all Part B items.
** Indicates significance of 1% or less.
Table 3: Correlations between CEST and success measures.
36 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
engaged in high-tech and above proj-
ects.
• Complexity: Forty-four subjects were
engaged in array projects, 60 in sys-
tem projects, and 10 in assembly proj-
ects.
• Pace: Three subjects were engaged in
blitz projects, 23 in time-critical proj-
ects, 41 in fast-competitive projects,
and 47 in regular projects.
The duration of the projects exam-
ined in the current study was in the
range of 6 months to 3 years, and the
budget was $200K—$200M (average
$28.7M).
Procedure
The survey was conducted in two
stages: a pilot survey and a main survey.
Thirty-six senior systems engineers
participated in the pilot study. The find-
ings of the pilot study were used to
revise and improve the questionnaire.
Confidentiality at all stages was prom-
ised and enforced. After the question-
naires were collected, the projects they
described were analyzed according to
the NCTP model.
Results
Table 3 presents the correlations
between the subjects’ capacity for engi-
neering systems thinking (CEST) and
the projects’ five success criteria (see the
Method/The Instrument/Part B section).
Four correlations were found to be
statistically significant. The findings
indicate that there is a positive signifi-
cant correlation between subjects’
Customer Team
0.065 0.050
0.503 0.601
109 114
CEST and project success in four
dimensions—overall success, meeting
design goals, benefit to the developing
organization, and benefit to the nation-
al infrastructure. The success indicators
of customer and team satisfaction were
also positively, but not significantly,
correlated with CEST. We will discuss
these results in the Discussion section.
An ANOVA test was performed in
order to examine whether the project
type (according to the NTCP model) is a
moderator variable (Baron & Kenny,
1986; Frazier, Tix, & Barron, 2004) that
affects the correlation between the sub-
jects’ CEST and project success. The idea
was to test whether the variable project
type dominates the significant correla-
tion between the dependent variable—
project success (PR_Succ)—and the inde-
pendent variable—CEST (strengthens or
weakens the correlation). The results are
presented in Table 4.
We can see that there is a statistical-
ly significant difference between the
three CEST groups. In other words, we
see again that there is a positive signifi-
cant correlation between subjects’
CEST and project success. The project
type does not significantly affect the
correlation between the subjects’ CEST
and project success (p ⫽ 0.739 ⬎ 0.05;
p ⫽ 0.730 ⬎ 0.05).
However, in order to test whether
there is a specific dimension (novelty,
technology, complexity, and pace) that
affects the correlation between the sub-
jects’ CEST and project success, four
additional two-way ANOVA tests were
Business Future PR_Succ
0.338** 0.305** 0.310**
0.000 0.001 0.001
105 114 114
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 37

Source Type III Sum of Squares df Mean Square F Sig.

Corrected Model 1.055 8 0.132 1.315 0.244
Intercept 568.808 1 568.808 5673.199 0.000
CEST 0.739 2 0.369 3.684 0.028
Project Type 0.061 2 0.030 0.303 0.739
CEST * Project Type 0.204 4 0.051 0.508 0.730
Error 10.528 105 0.100
Total 1,238.831 114
Corrected Total 11.583 113
Table 4: Two-way ANOVA: Examination of the effects of CEST and project type (dependent variable-project success).

Source Type III Sum of Squares df Mean Square F Sig.

Corrected Model 4.145 8 0.518 3.073 0.004
Intercept 350.906 1 350.906 2080.982 0.000
CEST 0.739 2 0.369 3.684 0.028
Novelty 1.062 2 0.531 3.149 0.047
SE_Grade_Cat * Novelty 1.739 4 0.435 2.579 0.042
Error 16.862 100 0.169
Total 1,246.606 109
Corrected Total 21.008 108
Table 5: Two-way ANOVA: Examination of the effects of CEST and novelty (dependent variable—project success).

performed—one test for each dimen-
sion. Table 5 presents the results for the
novelty dimension.
We can see that there is a statistical-
ly significant difference (p ⫽ 0.047 ⬍
0.05) between the three novelty groups
(derivative, platform, breakthrough). The
variable novelty does significantly affect
the correlation between the subjects’
CEST and project success; there is a sig-
nificant interaction between the two
variables (p ⫽ 0.042 ⬍ 0.05). Post-hoc
tests revealed that the more innovative
the project, the higher the correlation
between the subjects’ CEST and project
success. In other words, successful sys-
tems engineers (systems engineers with
high CEST) are needed most in plat-
form projects (projects that produce a
new generation of products) and break-
through projects (radical innovative
projects).
Similar results were obtained when
an ANOVA test, with complexity as an
independent variable, was run. It was
found that the more complex the proj-
ect, the higher the correlation between
CEST and project success. This implies
that organizations whose core business
is complex projects should employ sys-
tems engineers with a high level of
CEST. In other tests, a significant corre-
lation between the level of technologi-
cal uncertainty and project success was
found. One of the main characteristics
of successful systems engineers is “tol-
erance for ambiguity and uncertainty”
(Frank, 2006). Therefore, organizations
whose core business is high-tech and
super-high-tech projects should nomi-
nate systems engineers with a high
level of CEST for technical manage-
ment of these projects.
No significant correlation was found
between CEST and the satisfaction level
of the projects’ teams and between
CEST and the satisfaction level of the
customer and end-users. Organizations
that pursue project-team and customer
satisfaction should nominate project
managers who are committed to suc-
cess in these measures.
Discussion
The current study combined cognitive
aspects and measures with research
issues from the fields of systems

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 37

31-41PMJ0808.qxd 8/8/11 2:25 PM Page 38
Engineering Systems Thinking, Project Types, and Project Success
PAPERS
engineering and project management.
Based on the findings of previous stud-
ies, it was hypothesized that there is a
positive correlation between the capac-
ity for engineering systems thinking of
systems engineers employed in a given
project and the level of success of that
project. In order to test this hypothesis,
the study examined the relationships
among project profiles, project success,
and the CEST of 114 systems engineers.
The findings of this study clearly show
that there is a significant correlation
between CEST and project success, and
that the extent of the project’s novelty
(derivative, platform, or breakthrough)
is a moderator variable that affects this
correlation. The more innovative the
project is, the higher the correlation
between the subjects’ CEST and project
success. In other words, successful sys-
tems engineers (systems engineers with
high CEST) are needed most in plat-
form projects (projects that produce a
new generation of products) and break-
through projects (radical innovative
projects).
When interpreting these findings,
two major cautionary measures should
be considered. First, the findings of the
current study show that the coefficient
of determination, R2, is relatively low.
This means that the prediction of proj-
ect success can be only minimally
based on CEST. In other words, only a
low percentage of the variation in proj-
ect success can be explained by CEST.
The remaining percentage should be
explained by other variables. Of course,
this finding makes sense, as many other
variables might explain project success,
including the personality of the project
manger (Dvir, Sadeh, & Malach-Pines,
2006), the competencies of the project
manager (Boston University, 2010;
Edum-Fotwe & McCaffer, 2000), other
competencies relating to the project’s
systems engineers (Frank, 2006), and
all critical success factors (Chua et al.,
1999; Dvir et al., 2003; Holland & Light,
1999; Nah & Lau, 2001; Pinto & Slevin,
1988). Second, we must bear in mind that
correlation does not imply causation.
38 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Correlation is a necessary but not suf-
ficient condition for causation. The
significant correlation between CEST
and project success does not automat-
ically imply that CEST causes project
success.
In any case, a significant correlation
between CEST and project success does
exist and, because correlation is neces-
sary for causation, it is clear beyond all
doubt that, with regard to systems engi-
neering job positions, organizations
should select engineers who possess a
capacity for engineering systems think-
ing and create a supportive environ-
ment for enabling systems thinking
development in engineers. Before dis-
cussing the best ways to create such a
supportive environment, however, we
must first discuss whether the engi-
neering systems thinking capability is
acquired or innate. A direct answer
is not possible at this stage, because in
order to cope with this question, one
should probably run controlled in vitro
experiments, and maybe even neuro-
physiological brain research studies.
However, research shows that CEST is
presumably a combination of innate tal-
ent and acquired experience. Davidz and
Nightingale (2008) refer to a “wide
and varied background” in the “individ-
ual characteristics that enable systems
thinking development.” Frampton,
Thom, and Carroll (2006) found that
successful IT architects have broad
experience in all facets of the software
development life cycle. They found that
more than ten years of significant expe-
rience was usually required to perform
the role.
Frank (2006) found that successful
systems engineers usually execute a
wide range of jobs, which enable them
to become acquainted with systems
and technologies, learn from others’
experiences, be involved in systems-
related issues, work with senior systems
engineers, and develop a capacity for
engineering systems thinking. Engineers
who have some innate potential can
acquire or improve their CEST through
the following processes: accumulating
experience and performing varied engi-
neering and systems engineering job
positions, working together with success-
ful systems engineers and learning from
their experience and self-learning, and
participating in systems engineering
educational programs. Systems think-
ing may also be acquired or improved
by learning the general systems theory
principles and systems thinking princi-
ples (Kim, 1995; O’Connor & McDermott,
1997; Richmond, 2000; Senge, 1994;
Waring, 1996), analyzing already devel-
oped systems (including design consid-
erations), and studying selected topics
in various engineering disciplines. In
another study, Frank and Elata (2005)
found that freshman engineering stu-
dents may develop approaches and
strategies related to systems engineer-
ing and systems thinking. These results
also imply that systems thinking may
be developed through learning and
experience. Frank and Kordova (2009)
introduced an engineering manage-
ment course aimed at developing sys-
tems thinking capabilities through
active learning in a project-based
learning environment. The study find-
ings have shown that the final project
contributed to the development of
CEST among learners. Perhaps this is
additional evidence that supports the
notion that CEST may be improved and
acquired through learning.
To conclude, previous studies show
that CEST can be developed through
experience and learning. Therefore,
organizations should create a support-
ive environment for enabling systems
thinking development in engineers and
managers. Engineers and managers
with a high CEST may lead to better
performance in general, and especially
in regard to meeting design goals, over-
all project success, and making a con-
tribution to the organization and
national infrastructure.
Summary
The systems engineering and project
management literature has been rapid-
ly growing in recent years. A huge
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 39
number of scholarly books and papers
have been published, many tools are
offered by various vendors, and an
impressive number of conferences
related to systems engineering and
project management are held every
year. Yet, despite the huge bodies of
knowledge related to systems engineer-
ing and project management, about
two-thirds of all projects still fail.
A review of both project management
and systems engineering standards,
papers, books, conference proceedings,
and tool manuals clearly shows that
most of these sources focus on process-
es. We suggest focusing, instead, on
people. Dvir et al. (2006) dealt with proj-
ect managers; in this article, we focused
on systems engineers. Findings regard-
ing the competencies of successful sys-
tems engineers have been reported in
the systems engineering literature.
However, most of the works do not
distinguish among different types of
projects or attempt to match the com-
petencies of successful systems engi-
neers to specific types of projects and
project performance or success. This
article presents the findings of a study
aimed at exploring the relationship
among systems engineers’ capacity for
engineering systems thinking, project
types, and project success.
The instrument used in this study
was a self-report questionnaire com-
posed of three parts. The first part
assessed the capacity for engineering
systems thinking of the participants
and was based on a reliable and valid
tool for assessing CEST and engineers’
interest regarding systems engineering
positions (Frank, 2010). The second
part assessed project success and was
based on reliable and valid findings of a
previous study that identified five suc-
cess dimensions: meeting design goals,
benefit to the customer and end-user,
benefit to the project team, benefit to
the developing organization, and bene-
fit to the national infrastructure. The
third part assessed project type and was
based on the reliable and valid NTCP
model (Shenhar & Dvir, 2007). This
model enables portraying a project
profile in a four-axis diagram format—
novelty, technology, complexity, and
pace.
The population in this study included
all senior systems engineers employed
in the high-tech electronics systems
industry in Israel. The sampling frame
included all senior systems engineers
employed in the 16 largest high-tech
electronics systems companies in
Israel. The simple random sampling
method was used, and the sample size
was 114 senior systems engineers ran-
domly selected from the sampling
frame.
The study findings show that there
is a statistically significant correlation
between CEST and project success.
The extent of the project’s novelty,
complexity, and technological uncer-
tainty are moderator variables that
affect this correlation. The more inno-
vative, complex, or technologically
uncertain the project is, the higher the
correlation between the subjects’
CEST and project success. Therefore, it
is recommended that for systems
engineering job positions—especially
those in more innovative, complex, and
technologically uncertain projects—
organizations should select engineers
that possess a capacity for engineering
systems thinking and create a support-
ive environment to enable and
encourage systems thinking develop-
ment in engineers. It was found that
CEST may be improved and acquired
through learning and experience;
hence, it is assumed that CEST is a
combination of innate talent and
acquired experience. The correlations
obtained in this study are statistically
significant on the one hand but rela-
tively low on the other hand. Of course,
this finding makes sense, as many
other variables might explain project
success. However, a series of addition-
al and more extensive tests must be
conducted in future studies among
other cultures, sectors, and organiza-
tions with a larger number of partici-
pants. It is suggested to consider the
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
work presented in this article as a
trigger for initiating a strand of studies
aimed at exploring the relationship
between processes and personal com-
petencies; this is vitally important to
the field of project management. ■
References
Anastasi, A. (1988). Psychological test-
ing (6th ed.). New York: Macmillan.
Arnold, E. P. (2006). Defining, finding,
and hiring real systems engineers.
Proceedings of 16th Annual Symposium
of the International Council on Systems
Engineering (Orlando, FL). Seattle, WA:
INCOSE. Retrieved from https://www
.incose.org/ipub/06/031_1041.pdf
(access to INCOSE members only)
Baker, N., Murphy, D., & Fisher, D.
(1988). Factors affecting project suc-
cess. In D. I. Cleland & W. R. King
(Eds.), Handbook of project manage-
ment (pp. 902–919). New York: Van
Nostrand Reinhold.
Baron, R. M., & Kenny, D. A. (1986).
The moderator-mediator variable dis-
tinction in social psychological
research: Conceptual, strategic and
statistical considerations. Journal of
Personality and Social Psychology, 51,
1173–1182.
Boston University. (2010). Project
management competency model.
Retrieved from http://www.butrain
.com/mdp/CompModel.asp
Chua, D. K., Kog, Y. C., & Loh, P. K.
(1999). Critical success factors for dif-
ferent project objectives. Journal of
Construction Engineering and
Management, 125(3), 142–150.
Cooper, R. G., & Kleinschmidt, E. J.
(1987). New products: What separates
winners from losers? Journal of Product
Innovation Management, 4, 169–184.
Davidz, H. L., & Nightingale, D. J.
(2008). Enabling systems thinking to
accelerate the development of senior
systems engineers. Systems Engineering,
11(1), 1–14.
Derro, M. E., & Williams, C. R. (2009).
Behavioral competencies of highly
39
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 40
Engineering Systems Thinking, Project Types, and Project Success
PAPERS
regarded systems engineers at NASA.
Proceedings of Aerospace Conference
(pp. 1–17). Los Alamitos, CA: IEEE
Publications Office. doi:10.1109
/AERO.2009.4839712
Drazin, R., & Van de Ven, A. H. (1985).
Alternative forms of fit in contingency
theory. Administrative Science
Quarterly, 30, 514–539.
Dvir, D., Raz, T., & Shenhar, A. (2003).
An empirical analysis of the relation-
ship between project planning and
project success. International Journal
of Project Management, 21(2), 89–95.
Dvir, D., Sadeh, A., & Malach-Pines, A.
(2006). Projects and projects man-
agers: The relationship between proj-
ect managers’ personality, projects
types, and project success. Project
Management Journal, 37(5), 36–48.
Edum-Fotwe, E. T., & McCaffer, R.
(2000). Developing project manage-
ment competency. International
Journal of Project Management, 18,
111–124.
Frampton, K., Thom, J. A., & Carroll, J.
(2006). Enhancing IT architect capabil-
ities: Experiences within a university
subject. Paper presented at the
Australasian Conference on
Information Systems (ACIS2006),
Adelaide, South Australia.
Frank, M. (2006). Knowledge, abilities,
cognitive characteristics and behav-
ioral competences of engineers with
high capacity for engineering systems
thinking (CEST). Systems Engineering,
9(2), 91–103.
Frank, M. (2010). Assessing the interest
for systems engineering positions and
other engineering positions’ required
capacity for engineering systems
thinking (CEST). Systems Engineering,
13(2), 161–174.
Frank, M., & Elata, D. (2005).
Developing the capacity for engineer-
ing systems thinking (CEST) of fresh-
man engineering students. Systems
Engineering, 8(2), 187–195.
Frank, M., & Kordova, S. (2009).
Developing the capacity for engineer-
ing systems thinking (CEST) of senior
40 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
engineering management students:
Learning in a project-based learning
(PBL) environment. In R.S. Kalawsky,
J. O’Brien, T. Goonetilleke, & C. Grocott
(Eds.), Proceedings of the 7th Annual
Conference on Systems Engineering
Research (CSER 2009), Loughborough,
Leicestershire, UK. Loughborough
University, Research School of Systems
Engineering.
Frazier, P. A., Tix, A. P., & Barron, K. E.
(2004). Testing moderator and media-
tor effects in counseling psychology
research. Journal of Counseling
Psychology, 51, 115–134.
Freeman, M., & Beale P. (1992).
Measuring project success. Project
Management Journal, 23(1), 8–17.
Holland, C. R., & Light, B. (1999). A
critical success factors model for ERP
implementation. IEEE Transaction on
Software Engineering, 16(3), 30–36.
International Council on Systems
Engineering (INCOSE). (2004). Systems
engineering handbook (Version 2a).
San Diego, CA: Author.
International Council on Systems
Engineering (INCOSE). (2010). Systems
engineering handbook (Version 3.2).
San Diego, CA: Author.
International Council on Systems
Engineering, United Kingdom Chapter
(INCOSE UK). (2010). Systems engi-
neering competencies framework.
Retrieved from http://www.incose.org
/ProductsPubs/products/competen-
ciesframework.aspx
Jet Propulsion Laboratory (JPL). (2006).
Advancing the practice of systems engi-
neering at JPL. Retrieved from
http://trs-new.jpl.nasa.gov/dspace
/bitstream/2014/38979/1/05–3271.pdf
Kim, D. H. (1995). Systems thinking
tools. Waltham, MA: Pegasus.
KPMG. (2001). Project risk manage-
ment. Retrieved from http://www.us
.kpmg.com/microsite/attachments
/CapacitySheet-ProjectRisk Manage-
ment.pdf
Lawrence, P. R., & Lorsch, J.W. (1967).
Organization and environment:
Managing differentiation and integration.
Boston, MA: Harvard Business Press.
Lipovetsky, S., Tishler, A., Dvir, D., &
Shenhar, A. (1997). The relative impor-
tance of defense projects success
dimensions. R&D Management, 27(2),
97–106.
Nah, F. F., & Lau, J. L. (2001). Critical
factors for successful implementation
of enterprise systems. Business Process
Management Journal, 7(3), 285–296.
National Aeronautics and Space
Administration (NASA). (2007). Systems
engineering handbook. Retrieved from
http://education.ksc.nasa.gov
/esmdspacegrant/Documents
/NASA.pdf
O’Connor, J., & McDermott, I. (1997).
The art of systems thinking. San
Francisco, CA: Thorsons.
Pennings, J. M. (1992). Structural con-
tingency theory: A reappraisal. In B.
Staw & I. L. Cummings (Eds.), Research
in organizational behavior (Vol. 14,
pp. 267–309). Greenwich, CT: JAI Press.
Pinto, J. K., & Mantel, S. J. (1990). The
causes of project failure. IEEE
Transactions on Engineering
Management, 37 (4), 269–276.
Pinto, J. K., & Slevin, D. P. (1988).
Project success: Definitions and mea-
surement techniques. Project
Management Journal, 19(3), 67–73.
Project Management Institute (PMI).
(2008). A guide to the project manage-
ment body of knowledge (PMBOK®
guide; 4th ed.). Newtown Square, PA:
Author.
ProjTech. (2003). Reasons projects fail.
Retrieved from http://www
.projtechinc.com/methodology.htm
Richmond, B. (2000). The “thinking” in
systems thinking. Waltham, MA:
Pegasus.
Sadeh, A., Dvir, D., & Shenhar, A.
(2000). The role of contract type in the
success of R&D defense projects under
increasing uncertainty. Project
Management Journal, 31(3), 14–22.
Senge, P. M. (1994). The fifth discipline:
The art and practice of the learning
organization. New York: Doubleday.
31-41PMJ0808.qxd 8/8/11 2:25 PM Page 41
Shenhar, A. J., & Dvir, D. (2007).
Reinventing project management: The
diamond approach to successful growth
and innovation. Boston, MA: Harvard
Business School Press.
Standing, C., Guilfoyle, A., Chad, L., &
Love, P. E. (2006). The attribution of
success and failure in IT projects.
Industrial Management and Data
Systems, 106(8), 1148–1165.
Standish Group. (2009). Chaos sum-
mary 2009: The ten laws of chaos.
Retrieved from http://www1
.standishgroup.com/newsroom
/chaos_2009.php
Waring, A. (1996). Practical systems
thinking. Boston, MA: Thomson
Business Press.
Moti Frank earned his BSc in electrical engineer-
ing in 1981 from the Technion, Israel Institute of
Technology, and worked for more than 20 years
as an electronics and systems engineer in the
high-tech industry and Israeli Air Force. After he
was released, he earned his MSc in 1996 and
PhD in industrial engineering and management
and education in technology and science in
1999, both from the Technion. Currently, he is a
professor of systems engineering and project
management in the Holon Institute of Technology
and is a visiting faculty at the department of
systems engineering and operation research at
George Mason University in Fairfax, Virginia. His
research interests are systems engineering,
systems thinking, and project management.
Arik Sadeh earned his PhD from Texas A&M
University in 1986. He worked for an American
high-tech solar energy company in financial and
business planning of huge-scale projects. He
held a research position in the department of
statistics and operations research of the
Agricultural Research Organization (ARO). Since
1995, he has been a senior member on the aca-
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
demic staff at the Holon Institute of Technology.
He is the head of BSc studies in management of
technology. He conducts research projects in
the disciplines of risk, project, and operations
management; ethics and e-commerce; econom-
ics; and finance in the area of management of
technology.
Sharon Ashkenasi earned his BSc in technology
management (project management track) in
2007 and MSc in technology management
in 2009, both from the Holon Institute of
Technology. His master’s project, under the
supervision of Professor Moti Frank and Dr. Arik
Sadeh, dealt with the relationship among sys-
tems engineers’ capacity for engineering
systems thinking (CEST), project types, and
project success. Since 2002, he has been with
Israel Military Industries, dealing with project
planning and control of research and develop-
ment projects. Since 2007, he has been a project
manager working on the development of an
interdisciplinary system.
41
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 42

PAPERS
Exploring PMOs Through Community
of Practice Theory
Monique Aubry, School of Business and Management, Department of Business and
Technology, Université du Québec à Montréal, Montreal, Quebec, Canada
Ralf Müller, Umeå School of Business, Sweden Department of Business Administration,
Umeå University, Umeå, Sweden; BI Norwegian Business School, Department of Leadership
and Organizational Behaviour, Oslo, Norway
Johannes Glückler, Institute of Geography, University of Heidelberg, Heidelberg, Germany

ABSTRACT ■
This article explores project management
offices (PMOs) through community of practice
theory. Preliminary results from a national
health care case study are used to confirm the
legitimacy of this approach. Today’s knowledge-
based economy calls for mechanisms to share
knowledge. The issue of making more with less
is at stake in order to reuse good practices,
support innovative practice, and prevent the
reinvention of the wheel. Members of these com-
munities are at the heart of the learning process.
The originality of this research is that it sheds
light on PMOs in a new theoretical perspective
within the field of knowledge management.
KEYWORDS: community of practice theory;
PMO; community of PMOs; learning; project
management practice.
Project Management Journal, Vol. 42, No. 5, 42–56
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20259
INTRODUCTION ■
nowledge management is recognized as an important issue for
K organizations to succeed in a highly competitive environment.
Today’s knowledge-based economy calls for mechanisms to share
knowledge. This is particularly true in the context of international-
ization of business where services or products are developed, managed, or
supported in multiple countries. This is also true for national companies
that compete in a global market. The issue of making more with less is at
stake in order to reuse good practices, support innovative practice, and pre-
vent the reinvention of the wheel (Glückler, 2008). For project-based organi-
zations, this represents a major challenge, since projects are temporary
organizations (Turner & Müller, 2003). Moreover, projects and project man-
agement have come to play a central role in international economic growth
(Bredillet, 2007; Bredillet, Ruiz, & Yatim, 2008). Therefore, project-based
organizations should be highly concerned about knowledge management.
One promising approach is to explore the role of project management offices
(PMOs) and communities of PMOs as a locus of learning.
From the project management literature, knowledge management can
be presented based on its level of analysis: project or organizational level.
Research undertaken at the project level has explored as the main issue the
transfer of knowledge from one project to the other. Different perspectives
have been taken, including postproject reviews (Williams, 2007), social prac-
tices (Bresnen, Edelman, Newell, Scarbrough, & Swan, 2003; Sense &
Badham, 2008), and quality management (Kotnour, 2000). At the organiza-
tional level, Bredillet (2004) proposed an overview on knowledge manage-
ment, organizational learning, and learning organizations. Other research
has drawn attention to particular perspectives such as human resource
management (Bellini & Canonico, 2008; Keegan & Turner, 2001) and the role
of non-financial capital (Arthur, DeFillippi, & Jones, 2001). Some authors
have looked at knowledge sharing between industries (Fernie, Green, Weller,
& Newcombe, 2003), while others have examined the methods to capture
and validate relevant knowledge (Abril & Müller, 2009).
Based on the PMO definition, many entities fall under the categorization
that leads to the coexistence of multiple competing PMOs, particularly in
large organizations. PMOs are not autonomous or isolated units within an
organization but they are frequently intertwined with other PMOs in the
same corporation. This is in line with results from a recent research showing
an increase in the interdependencies between PMOs after a PMO structural
change (Aubry, Müller, Hobbs, & Blomquist, 2009).

42 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

42-56PMJ0808.qxd 8/8/11 12:20 PM Page 43
Parallel to this, governance has
become an emerging topic. After a
number of corporate scandals, guide-
lines for corporate governance, such as
Sarbanes-Oxley Act (SOX), the Higgs
report, or Basel II, were developed in
order to protect investors. The aim is to
reduce risk through transparency of
business conduct and extended report-
ing requirements. Project management
and its governance is a subset of corpo-
rate governance (Crawford & Cooke-
Davies, 2005; Müller, 2009). PMOs are
part of project governance, independ-
ent of their specific role, mandate, or
location within the organization.
Altogether, these entities form what has
been defined in organizational project
management as “a new sphere of man-
agement where dynamic structures in
the firm are articulated as means to
implement corporate objectives
through projects in order to maximize
value” (Aubry, Hobbs, & Thuillier, 2007,
p. 332).
What we now observe in large
organizations is the creation of com-
munities of PMOs aimed at learning
and sharing knowledge in the manage-
ment of projects. These communities
form one pattern of organizational
project management. The community
of PMOs consists of internal networks of
PMOs that cross organizational bound-
aries. Networks can be formed implicit-
ly or explicitly in order to create value
by sharing knowledge in the manage-
ment of projects.
In this article, we borrow from the
theory of community of practice (CoP)
(Lave & Wenger, 1991) to explore the
PMOs’ social networks as communities
of practice. This approach offers the
opportunity to build not only on
the grouping role of PMOs around mul-
tiple projects but also on the practice of
project management and the practi-
tioners. This phenomenon of commu-
nity of practice has already been
acknowledged within the field of proj-
ect management researches. A rapid
look at the publications from the three
specialized academic journals shows
that since 2002, 40 articles on the topic
have been published. Interestingly, the
Project Management Association of
Japan introduced the management of a
community of practice as part of the
project and program management
(Project Management Association of
Japan, 2008). However, none of these
articles addresses the role of the PMOs
in the making and sharing of knowledge
on project management practices.
Following what has been said earli-
er on the current organizational con-
text, the main objective of this research
is to provide an understanding of PMOs
as communities of practice. This leads
to the research question “What are
communities of PMOs?” and its sub-
questions:
• How can communities of PMOs be
described?
• Do PMOs interact and if so, why?
• What are the related project gover-
nance mechanisms?
• What links PMOs and project man-
agement governance?
• Why are communities of PMOs
formed?
Missing Links in PMO
Performance
The review of the literature is presented
in three major themes related to the
research question: project manage-
ment office, communities of practice,
and governance.
How Do Project Management Offices
Support the Circulation of
Knowledge?
Past research on PMOs mainly looked
at one instance at a time. Research has
shown an extreme variety of PMO
structure, mandate, and function
(Hobbs & Aubry, 2007). More impor-
tantly, this variation cannot be
explained easily and, for the moment, a
reliable typology has yet to be devel-
oped (Hobbs & Aubry, 2008). Recent
research confirmed temporality as a
dimension of the PMO and that this
temporality could be better understood
within the external and internal
dynamics of the organization. Results
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
confirm that external and internal
factors and idiosyncrasies drive the
transformation of one PMO to the next.
The temporality dimension reflects an
organizational ambidexterity (Gibson &
Birkinshaw, 2004) between transforma-
tion and sustainability. Both coexist in
the sense that sustainability should be
understood within the transformation
process.
A descriptive PMO model has
recently been proposed to make sense
of the variety of configurations that are
found in reality (Hobbs & Aubry, 2010).
This model includes two main groups
of elements to describe the PMO: struc-
tural characteristics and roles or func-
tions within the PMO mandate.
Organizational knowledge manage-
ment refers to one specific function
part of the PMO model. It includes such
activities as:
• Monitor and control the performance
of the PMO.
• Manage archives of project documen-
tation.
• Conduct postproject reviews or post-
mortems.
• Conduct project audits.
• Implement and manage a database of
lessons learned.
• Implement and manage a risk data-
base.
The organizational knowledge
management function is one of the
least important when compared with
others (Hobbs & Aubry, 2007). This low
result should be looked at in the light of
other research undertaken on knowl-
edge management at the project level.
Williams (2008), for example, showed
that project team documentation on
lessons learned was poorly done. Often,
members of a team are dispatched to a
new project prior to the closing of the
current project. It is well acknowledged
that lessons learned are a good means
to transfer knowledge, but it is usually
not performed.
However, there is another perspec-
tive when looking at knowledge man-
agement in the context of the PMO.
43
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 44
Exploring PMOs Through Community of Practice Theory
PAPERS
Seminal work from Nonaka and
Takeuchi (1995) proposed a framework
based on the distinction between
explicit knowledge (e.g., documents,
patents, statutes) and implicit knowl-
edge. Implicit knowledge refers to the
individual know-how as a capability or
competence to solve problems. This
knowledge is difficult to articulate or
explain and, therefore, hard to transfer
in the pure sense of duplication
(Gertler, 2003; Nonaka & von Krogh,
2009). Within projects, explicit knowl-
edge can often be related to the project
life cycle (Project Management
Institute, 2008). However, tacit knowl-
edge is created as learning (Kotnour,
1999), focusing on the active actor
being responsible for its own progres-
sion instead of focusing on the object of
knowledge ( J. S. Brown & Duguid,
2001). In other words, “people do not
simply learn about, they also learn to
be” (Bruner, 1996, as cited in J. S. Brown
& Duguid, 2001, p. 200). Learning in
action (rather than after the fact) puts
the practice at the front.
The basic definition of a PMO refers
to the relation with multiple projects
and, as such, a PMO is involved directly
or indirectly in the practice of the man-
agement of unique projects or in the
practice of one or multiple functions as
defined within the PMO model. The
new phenomenon of multiple PMOs
working together raises questions about
knowledge, learning, and practice in the
social networks of project managers.
Organizational Learning: A
Community of Practice Approach
Definition. A community is defined as a
group of people with common charac-
teristics or interests living together
within a larger society, while practice is
defined as the continuous exercise of a
profession (Merriam-Webster, 2007).
The community of practice theory was
introduced as a theory of learning from
studies of apprenticeship. The initial
thoughts on communities of practice
have emerged from a profound ques-
tioning on the learning process that is
44 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
the object of the seminal book from
Lave and Wenger (1991). These authors
proposed the concept of situated learn-
ing as a legitimate peripheral participa-
tion within a theoretical perspective of
social practice, which includes learn-
ing. They write, “We are, then, trying to
furnish the social world in a way that
begins to do justice to the structured
forms and relations in which legitimate
peripheral participation takes place.
Relational, historical conceptions have
emerged from this exercise, and this
decentering tendency is characteristic
of the means we have explored for
grasping ‘person,’ ‘activity,’ ‘knowing,’
and the ‘social world’” (Lave & Wenger,
1991, p. 122). The person is considered
as a practitioner involved as both a
member of a community and as an
agent of activity. The person dynami-
cally progresses (as does the communi-
ty) from a newcomer to becoming an
old-timer, leading to what can be seen
as a contradiction between achieving
continuity for the community of prac-
tice on one hand and the replacement
of old-timers on the other. Within the
situated learning activity, transformed
in legitimated peripheral participation,
newcomers move in a centripetal direc-
tion under their motivation to become
full practitioners. Knowing is a social
reality where participation is a way of
learning. It takes the form of “relations
among practitioners, their practices,
the artifacts of that practice, and the
social organization and political econo-
my of communities of practice” (Lave &
Wenger, 1991, p. 122).
Wenger and Snyder (2000) pro-
posed to define communities of prac-
tice as “groups of people informally
bound together by shared expertise and
passion for a joined enterprise” (p. 139).
Communities of practice are now enter-
ing the virtual mode, making use of
open communication technology such
as wikis, webinars, blogs, and the like.
For example, the Project Management
Institute recently launched eight com-
munities of practice through its website
(Project Management Institute, 2009).
Yet, a community of practice is
anchored in learning. It adopts an inte-
grative constructivist epistemology where
different types of knowledge (tacit,
explicit, individual, team/organizational)
are seen as inseparable and mutually
enabling (Bredillet, 2004). Bredillet
writes, “Thus knowledge can be seen as
an input of knowing, and knowing as an
aspect of our interaction with the social
and physical world, and therefore the
dynamic interaction of knowledge and
knowing can generate new knowledge
and new ways of knowing” (Bredillet,
2004, p. 1114). It is opposed to the more
traditional positivist epistemology that
assumes knowledge is something peo-
ple have.
Community of practice and other
types of groups. Distinction between
different types of groups is proposed by
Wenger and Snyder (2000, p. 142). The
PMO community of practice is distinct
from a formal work group from which
specific outcomes are expected, from a
project team from which deliverables
are expected within a specific budget
and period of time, and, lastly, from an
informal network formed loosely
between employees that share some
common interest. While this grouping
is useful to distinguish between differ-
ent groups encountered within the
organization, it misses major learning
fundamentals based upon the commu-
nity of practice theory. Bredillet (2004)
suggested a typology to distinguish a
community of practice and project
team based specifically on the learning
experience. Following Bredillet (2004),
members within a community of prac-
tice “learn by participating in the com-
munity and practicing their jobs”
(Bredillet, 2004, p. 1130). Conversely, in
a project team, “members practice their
jobs and learn by participating in the
project team. Project team is a place
where knowledge is created, where
members learn knowledge that is
embedded, and where knowledge is
utilized” (Bredillet, 2004, p. 1130).
Knowledge occurs in project teams as
well as within a community of practice.
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 45
Community of practice is an emer-
gent concept, and multiple forms are
found in reality. Scarbrough and Swan
(2008) argued for accepting diversity in
the forms of communities of practice.
They see the concept of the community
of practice as denoting not a discrete
social grouping but rather historically
specific expressions of the self-reinforcing
relationships between learning, identity,
group formation, and social practices.
They have shown that the project team
and community of practice represent
different sources of learning and that
they overlap, reinforce, and sometimes
conflict, depending on the relation
between project work and existing
social practices.
Managerial paradox. However, pre-
cisely with the wide diffusion of the
concept comes a sort of distortion of
the initial thoughts (Duguid, 2008a;
Lave, 2008). Duguid (2008a) pointed
out that the community of practice is
now an instrument of management:
“We also get a theory that appeals
strongly not only to business schools,
but also to management consultants: it
is instrumental, operational, and prom-
ises only beneficial results” (p. 7). Initial
thoughts on learning as improvisation
and autonomy are forgotten and
replaced with just the contrary: to fol-
low the rules and avoid any improvisa-
tion (Lave & Wenger, 1991; Wenger &
Snyder, 2000). Duguid (2008a) saw in
this managerial approach to the com-
munity of practice the traditional but
still strongly alive of the Taylorism
where control overcome any form of
improvisation and autonomy. In this
sense, the community of practice can
be said as being rapidly domesticated
(Duguid, 2008a, p. 7). Nevertheless,
Duguid (2008a) and Lave (2008) both
admitted that, as any other construct,
this one is following its own itinerary.
An example of managerial domesti-
cation of the community of practice is
given within Wenger and Snyder (2000).
They promoted communities of prac-
tice as a new managerial instrument to
reach business results such as helping
to drive strategy, starting new lines of
business, and so on. They defined com-
munities of practice as fundamentally
informal and self-organizing, and at the
same time, they benefit from cultiva-
tion. For these authors, cultivation
refers to supporting communities of
practice and sustaining them over time.
This is where the management paradox
comes in: on one side is the emerging
and self-organizing inherent character
of the community of practice and on
the other side the managerial involve-
ment in developing them and integrat-
ing them into the organization. In this
context, up to what point is a commu-
nity of practice not becoming a formal
working group?
One other dimension of this para-
dox relates to knowing what and know-
ing how. In community of practice
theory, codification of knowing what in
an artifact is possible. However, the
knowing how needs practice to make it
actionable (Duguid, 2008b). This para-
dox frequently takes the form of best
practices diffusion. Best practices refer
to explicit knowledge that can be trans-
ferred from one organization to the
next. But, what is critical in knowledge
is not so much the what but the how:
“[. . .] the explicit is worth relatively lit-
tle” (Duguid, 2008b, p. 81). To solve this
paradox, best practices should be re-
embedded within the community.
Managing Situated Learning: The
Governance Challenge
From an organization theory perspec-
tive, this development resembles the
time-paced evolution in relentlessly
shifting organizations, as described by
S. L. Brown and Eisenhardt (1997). This
theory migrates the well-established
theories of punctuated equilibrium
(such as agency theory and transaction
cost economics) into the dynamics of
today’s organizations and their markets
using the structural and communica-
tion approaches of successful compa-
nies. Results from this research show
that successful organizations use nei-
ther extremely mechanistic nor
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
extremely organic structures, but adapt
their structures to the projects’ needs,
combined with intensive communica-
tion across projects (also shown by
Turner & Müller, 2004). S. L. Brown and
Eisenhardt (1997) showed that process-
oriented project management approach-
es (i.e., those prioritizing process over
project outcome) are associated with
less successful organizations, whereas
outcome-oriented approaches are
associated with the more successful
organizations. This may serves as a
starting point to investigate the current
move from control-oriented PMOs to
project-outcome and results-oriented
PMOs, and the roles of PMO networks
in this type of project governance struc-
ture. The theoretical lens taken in the
present study is that of S. L. Brown and
Eisenhardt (1997), where organizations
continuously change and so do their
structures—PMO networks develop in
order to effectively and efficiently bal-
ance the changing needs for project
management governance within cor-
porations.
Recent work by Müller (2009) iden-
tified governance paradigms through
integration of governance theory and
organization theory. By overlaying the
shareholder versus stakeholder orien-
tation of an organization (Clarke, 2004),
with outcome control versus behavior
control (S. L. Brown & Eisenhardt, 1997;
Ouchi & Maguire, 1975), four project
governance paradigms were identified.
Table 1 shows the related paradigms.
The Conformist paradigm ensures
strict compliance with existing process-
es, rules, and policies in an attempt to
ensure lowest project costs in environ-
ments with a relatively homogeneous
set of projects. Here tactical PMOs
implement one particular project man-
agement methodology within the
organization. The Flexible Economist
paradigm aims for low project costs
through a well-informed selection of
project management methodologies
that ensure economic delivery by only
marginally compromising other suc-
cess criteria. PMOs working in these
45
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 46
Exploring PMOs Through Community of Practice Theory
PAPERS
Control Focus Shareholder Orientation
Outcome Flexible Economist
Behavior Conformist
Table 1: Four governance paradigms (Müller, 2009).
environments build a range of skills
and a toolbox for project managers to
use. Under the Versatile Artist para-
digm, the benefits are maximized by
balancing the diverse set of require-
ments arising from a number of differ-
ent stakeholders. PMOs support project
managers in the development of new or
tailoring of existing methodologies,
processes, or tools to balance econom-
ically the diversity of requirements.
Organizations subscribing to the Agile
Pragmatist paradigm maximize usabili-
ty and business value of a project’s
product through a time-phased
approach to product release of func-
tionality over a period of time. These
projects often use Agile/Scrum meth-
ods, with the sponsor prioritizing deliv-
erables by business value over a given
time frame. These organizations rarely
have PMOs, but if they do, the PMOs
perform tactical process improvement
activities (Müller, 2009).
Governance paradigms differ with-
in larger companies and are contingent
upon the idiosyncrasies of the different
organizations that make up the company.
The limits to project governance are set
by the corporate governance frame-
work and the legitimacy of actions
within the social context (Müller, 2009).
Communities of PMOs can thereby be
made up of PMOs with very different
charters.
Toward a Community of PMOs
Approach
This section proposes a conceptual
framework for the study of communi-
ties of PMOs within large organizations.
Within an organization, a community
of practice of PMOs can be defined as a
group of people (PMO managers or
46 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Stakeholder Orientation
Versatile Artist
Agile Pragmatist
employees) informally bound together
by shared expertise and passion for a
joint enterprise. In other words, it offers
a platform for learning to experienced
members and newcomers. It forms a
community in the sense that members
share a common interest and passion
for the success of projects. It is oriented
toward practice.
The raison d’être of any PMO, what-
ever its functions or structural character-
istics, is mainly associated with projects.
But what is a community and what is a
practice when considering the PMO as
a community of practice? The practice
of project management is at the heart of
a PMO’s community, but the PMO prac-
tices are specific and differ from the
project management practices. The for-
mer refers to the functions within the
PMO model (Hobbs & Aubry, 2010),
while the latter refers to managing a
single project as described in Bodies of
Knowledge (Association for Project
Management, 2000; Project Manage-
ment Institute, 2008). About half of all
PMOs do include project management
as their primary function (Hobbs &
Aubry, 2007). The object of learning in a
PMO community of practice may bear
on the management of a single project
or to a PMO’s specific set of functions.
Members of a PMO community are
the ones who believe in and have a pas-
sion for the project management prac-
tice. It may include people working
within the PMO as a manager or
employee, or people working within a
single project, including a project man-
ager, project controller, and others
involved in project work. Interest and
expertise surely differ when consider-
ing the management of a single project
versus PMO functions. This may lead to
the coexistence of multiple networks. It is
already acknowledged that each project
can be seen as a social network that
crosses the hierarchical boundaries of
the organization (Blackburn, 2002).
Adding to these project networks are
the ones related to a community of
practice. As PMOs show a wide variety
of configurations, communities of
PMOs might as well show this diversity
where practices will differ depending
on PMOs’ functions and characteris-
tics. By participating in project man-
agement governance, these PMOs form
either one or multiple networks.
Understanding these networks by
means of their relationships will shed
light on the global picture of organiza-
tional project management.
The suggested conceptual frame-
work for this research is proposed in
Figure 1. It is not expected that this
framework will cover the overall phe-
nomenon of communities of PMOs, but
it will be helpful in capturing basic
components from the review of the lit-
erature. The first phase of this research
is based upon case studies that will pro-
vide new data to enrich this model (see
the Methodology section).
Research Design
The network of PMOs is our unit of
analysis, as it represents a formal and
idiosyncratic articulation of project
management in multiproject organiza-
tions. Robustness in empirical research
design puts emphasis on mixed-
method approaches. This research
design combines the advantages of
case studies, qualitative and quantita-
tive methods, and social network analy-
sis. This approach offers the opportunity
to gain alternative access to empirical
observations. Triangulation (Jick, 1979)
will allow us to minimize method-spe-
cific biases in the analyses (Miles &
Huberman, 1994). In addition to the
descriptive results from the cases and
mixed methods, the subsequent social
network analysis will account for the
dynamics and structure of the phenom-
enon under investigation. The strategy
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 47

network “is a specific set of linkages

CONTEXT: PROJECT MANAGEMENT
GOVERNANCE
PMO COMMUNITY OF
PRACTICE
• Learning mechanisms
PMO Member
• PMO model • Master
• Newcomer
Figure 1: Conceptual framework for communities of PMOs.
to accomplish the goals for this
research includes three phases.
Phase 1: In-Depth Case Studies
The starting point to a better under-
standing of a complex phenomenon is
a case-based grounded theory
approach (Corbin & Strauss, 1990; Yin,
2003). We propose to describe four case
studies, each one being a large organi-
zation where there are multiple PMOs,
including interviews with 10–15 per-
sons from upper management to proj-
ect managers. As shown in Table 2, the
choice of the organizations accounted
for diversity in countries (North
America, Europe, and Asia), industries
(health care, manufacturers, telecom-
munications, banking), and financial
structures (private, public, and mutual).
Case #1
Geographical North America
location
Economic sector Health Care
Number of PMOs 11
investigated
Number of 21
interviews
Table 2: Case studies description.
• Practices related to PMO functions
• Practices related to management
of projects or programs
Other Unit
Globally, the research design provides a
strong mix of similarity and diversity
(Eisenhardt, 1989). The result will be a
rich description and a map of related
components of organizational project
management within their dynamic
context and in different cultural set-
tings. At the time of submitting this
article, one case study had been com-
pleted, and two were in progress.
Phase 2: Social Network Analysis
In phase 2, the selected corporate case
studies will be analyzed by means of a
social network analysis (SNA). The basic
approach of SNA is to construct topo-
logical networks and analyze the posi-
tions and roles of individual nodes, as
well as the overall structure of linkages
within the network. Generally, a social
Case #2 Case #3 Total
Europe Asia 3
Telecommunications Manufacturing 3 from empirical data in the two previous
7 5 23
7 10 38
among a defined set of persons, with the
additional property that the character-
istics of these linkages as a whole may
be used to interpret the social behavior
of the persons involved” (Mitchell, 1969,
p. 2). This methodology uses relational
information about the connections
between actors, projects, and organiza-
tions to assess the specific structures
and social opportunities that these
structures convey (cf. Scott, 2000;
Wasserman & Faust, 1994, for a detailed
introduction).
Within organization science,
methods of social network analysis
have been increasingly applied to
studies of knowledge management
and knowledge transfer within large
organizations (Reagans & McEvily,
2003; Tsai, 2001), informal governance
(Lazega, 2001; Lazega & Pattison,
2001), and the geography of innova-
tion (e.g., Almeida & Kogut, 1999;
Breschi, Lissoni, & Montobbio, 2007;
Powell, Koput, & Smith-Doerr, 1996;
Sorenson & Waguespack, 2005). Within
the project management field, research
based upon the social network analysis
is now produced using methods of
social network analysis (cf. Brookes,
Morton, Dainty, & Burns, 2006;
Manning, 2005; Mead, 2001; Pryke &
Pearson, 2006). So far, research into the
new realities of project management
and the highly interwoven webs of proj-
ect management offices have not been
the focus of network analysis. It is a
central tenet of this study that a more
profound examination of the relational
structures of projects and PMOs in
large organizations will benefit from
the application of SNA.
Phase 3: Synthesis and Validation
of Empirical Findings
This phase integrates results obtained
phases. By integrating the results, this
phase should offer the possibility of
finding revealing patterns across and
between organizations of the same
and different industries. The results will
be validated through a combination of

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 47

42-56PMJ0808.qxd 8/8/11 12:20 PM Page 48

PAPERS
Exploring PMOs Through Community of Practice Theory

focus groups consisting of managers of
organizations with similar PMO net-
works (or patterns), and subsequent
working sessions with senior managers
from diverse industries that will (a) val-
idate the cross-industry findings and
(b) foster cross-sectional learning of the
participants.
Data Collection and Data Analysis
Strategies
We used a multiple-case design, which
implies replication logic (Yin, 2003)
within which a case is treated as an
idiosyncratic expression of the phe-
nomenon under study. We gathered
information from several layers of the
management hierarchy and incorporat-
ed company- and industry-level forces
and circumstances. Data for the case
studies are collected through inter-
views, questionnaires, observations,
and reviews of existing documents.
Each case will be described and inter-
nally analyzed before cross-case analy-
sis takes place, following Eisenhardt
(1989).
Then, following Miles and
Huberman (1994) and Eisenhardt
(1989), we will do cross-case analysis to
develop the underlying concepts. While
this will be done without underlying
hypotheses, there will be a steady back
and forth between the cases and the
identified concepts in order to ensure
that the concepts are consistent with
the data (and valid).
The interviews done as part of the
case study will follow a grounded theo-
ry approach for each individual case. In
line with the abductive approach
described for the cross-case analysis,
the grounded theory approach will fol-
low the Strauss and Corbin (1998)
school. This implies an analysis after
each individual interview and a contin-
uous comparison approach to identify
commonalities, as well as ruling out
one-time events, thus ensuring a robust
theory.
In addition to interviews, question-
naires have been completed within the
SNA approach. Questions relate to
PMOs, projects within the mandate of
the PMO, and employees working on
these projects. Altogether, the data col-
lected will lead to the representation of
social networks.
Preliminary Results From
a Health Care Case Study
This section presents the results from a
health care case study through exam-

SNA Questionnaire
Total
Name of the Organization Number of Number of
Within the Healthcare Number of Projects Number of Projects
Network Interviewees Precisions Regarding the PMO Surveyed Employees in 2008
IT Department Within Ministry 2 No PMO as such; functions are 12 12 25
assumed within the financial
division
Personal Health Record Project 2 PMO including three units 6 9 18
IT Supplier 2 PMO 11 11 35
Regional Agency 01 2 PMO recognized externally as a 13 14 13
success but decision taken to
dismantle it
Regional Agency 02 1 Small number of people N/A N/A N/A
Regional Agency 03 2 PMO in a transitory situation N/A N/A N/A
Regional Agency 04 4 PMO within IT department but is 11 11 56
on the way to creation of a PMO
at the strategic level
Regional Agency 05 2 PMO in IT department 11 4 51
Local Level 01 2 PMO within IT department but 5 35 N/A
involved in business decisions
Local Level 02 2 PMO specialized in real estate N/A N/A N/A
Total 21
Table 3: List of participants from health care organizations.

48 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

42-56PMJ0808.qxd 8/8/11 12:20 PM Page 49
ples of situated learning from two PMO
communities of practice. The first one
refers to a PMO coordination committee
that has been put in place at the min-
istry level, the second relates to a PMO
within a regional center that interplays
with other PMOs at the regional level
and PMOs at local centers. Table 3 gives
more details on participants from
health care organizations that partici-
pated in this study.
Description of the National Health
Care Network
This case describes the social networks
between PMOs within a national health
care system. The major particularity of
this public case study is that the entire
system constitutes a network of quasi-
autonomous organizations spread over
three structural layers: national, region-
al, and local. A first hierarchical look at
this national health care network is
illustrated in Figure 2. Boxes in bold
indicate the units that were investigat-
ed within this research regarding their
PMO. At the national level, three PMOs
were investigated: (a) a PMO dedicated
to a major national project; (b) a PMO
within the information technology (IT)
department; and (c) a PMO within the
IT dedicated supplier. At the regional
level, four PMOs have been investigat-
ed. At the local level, four PMOs were
explored, one located in a first universi-
ty hospital and three in a second univer-
sity hospital. Projects can be initiated at
each of these three levels. National and
regional projects are financed by the
national health budget. The distribu-
tion of the regional envelope through
the local institutions is under the man-
date of each regional agency. Local proj-
ects can be financed by this envelope
but also by local financing (e.g., a hos-
pital foundation).
A second contrasted look can be
presented from the same case study,
this look obtained from the SNA
approach (see Figure 3). The intent of
presenting this figure is not to provide
an in-depth interpretation through
SNA, but rather to propose a first explo-
ration of the potential of this approach
to complement the case study. Network
(a) displays the collaborative linkages
between the seven focal PMOs. PMOS
are focal (black) if they responded to
the survey. Six PMOs maintain collabo-
rative relationships, while one PMO
operates in isolation. Network (b) illus-
trates the number of projects (grey)
reported by each of the seven PMOs
(black). Note that only three projects
were realized under joint responsibility
by two PMOs. These projects are so-
called cut points in the network
because their removal would cause the
network to break up into isolated
groups of projects. Networks (c) and (d)
represent the project networks based
on two different criteria of connection.
Network (c) converts the bipartite net-
work (b) into a network of projects
where projects are connected based on
the joint support by the same PMO.
Network (d) connects projects based on
the co-occurrence of project members.
Whenever a team member has worked
in two or more projects, these projects
receive a link between each other. In
contrast to one PMO, where all projects
are interconnected through at least one
joint member, most other projects
are separated though they belong to the
same PMO.
Situated Learning at the National
Level
Many waves of restructuring have been
going on in the last few years trying to
make better use of limited resources. The
last major reorganization occurred in
2004 and affected the entire health
system, adopting at the same time more
rigorous governance rules and, among
others, the establishment of better per-
formance indicators. Numerous projects
were then undertaken, some of which
needed to be managed in a coordinated
way throughout all regions. One of these
cross-regional major projects was the
implementation of a personal health
record (PHR). It is being developed at the
ministry level, but the resulting solution
will affect each regional, local center and
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
health establishments. Moreover, the
success of this project is not uniquely
technological. New processes need to be
developed, and the implementation will
need formal change management. In
this perspective, a recommendation
from the ministry was made to imple-
ment a PMO in each regional center.
From the national level, a generic organi-
zational structure model has been
strongly proposed for the regional cen-
ters that suggests the existence of a PMO
within the IT department. However, this
model has many variations depending
upon the size of the region (population)
and its current project management
assets.
In addition to the implementation
of PMOs at the regional level, two com-
mittees have been created at the
national-level grouping: (1) all regional
project managers responsible for
implementation (the project managers
committee) and (2) all regional PMO
directors (the PMO coordination com-
mittee).
The PMO coordination committee is
managed at the national level by the IT
department. The short-term objective of
this committee is to facilitate the imple-
mentation of the PHR project. But it also
has a long-term objective of implement-
ing a coordinated project management
over all health care institutions, crossing
all the regional and local borders. This
second objective is the equivalent of
implementing a national portfolio man-
agement. Both objectives would be
unreachable if undertaken without the
full engagement of the regional and local
institutions.
Eighteen people participate in the
PMO coordination committee. The PMO
director within the IT ministerial depart-
ment is the initiator and is responsible for
the PMO coordination committee. He is
in charge of the administrative support,
the logistic organization, and the fees
related to the face-to face meeting. PMO
directors from the 18 regional agencies
are important members. Their level of
expertise varies widely, from many years
in PMO management to almost new to
49
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 50

Exploring PMOs Through Community of Practice Theory

PAPERS

Ministry of Health
and Social
Services

National Other PHR Project

Level Departments Departments Dedicated IT
IT Department
Regional Supplier
PMOs
Project
Coordination
Managers
Committee
Committee

There are 18 Regional Agencies

Regional Regional Agency Regional Agency Regional Agency Regional Agency Regional Agency
Level #1 #2 #3 #4 #18

There Are 4 University Hospital Centers and 95

University University Local Health
Health and Social Centers Spread over the 18
Hospital Hospital and Social
Regional Agencies
Center #1 Center #2 Center
Local
Level
in Direct
IT Real Estate Hospital
Contact
with
Organization with a PMo
People
Youngster Included in the Case Study
IT Center
Organization not Included in the
Long Stay Case Study (with or without a PMO)
Center

Figure 2: The three layers of national health care organizations.

(a) The network of PMOs (b) The PMO-project network

(c) The project network (PMO-managed) (d) The project network (joint staff)

Figure 3: The networks of projects and PMOs in the national health care organization.

50 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

42-56PMJ0808.qxd 8/8/11 12:20 PM Page 51
the project management profession.
These members reflect the terms new-
comers and masters in the language of
community of practice (Lave & Wenger,
1991). From interviews, masters
describe themselves as having a dis-
tance in front of others, which seems to
be acknowledged by newcomers.
Masters want to share; they have the
taste of it, and they like to share their
own experiences. Other members of this
committee come from the IT depart-
ment, the dedicated providers, and the
PHR project.
There are very practical objectives
from this committee, such as project
management methodology and
processes, project management soft-
ware tools, templates, and so on. A
national project portfolio embryo is
also in construction. The agenda aims
to produce all that is needed to succeed
in the implementation of the project. A
list of requirements has been first
established with the members and pri-
ority assigned. On a voluntary basis,
members are part of subcommittees
that work on specific deliverables—for
example, the granularity of the
methodology and the details needed
for each level. The current practices in
regional agencies are put together to
orient the future. It is not only a matter
of sharing actual practices; it is also
expected that working together will
bring solutions further along from
where they actually are. The work done
in subcommittees is then presented at
the committee for consensual decision.
At the end of the process, the project
management environment in health
care will have been discussed and will
be the result of consensus. Outcomes
(e.g., templates, risk management
process) are progressively available for
every regional PMO to make use of it
and experiment it. Feedback is then
taken into consideration for the next
version.
This committee could also be
defined as a virtual community of prac-
tice because not all members are locat-
ed in the same area in their daily
work—quite the contrary. Members are Duguid (2008a) and Lave (2008).
widespread over the national territory. However, the PMO coordination com-
They share a common position as all mittee forms a real social network that
members are PMO directors or the aims to construct new knowledge from
equivalent. However, they differ when established practices within regional
taking into consideration the regional levels. It also plays a role in disseminat-
context and their relative experience in ing practices from the master to the
the implementation and management newcomers. The objective here is
of a PMO. Members of the PMO coordi- to identify the events that provide a
nation committee meet face-to-face group learning situation, even if they
once a month, or less depending on the refer to an actualization of the initial
agenda. All interviewees referred to this concept of community of practice.
committee when they were questioned The second learning mechanism
on PMO communities of practice. from the PMO coordination committee
Two different learning mechanisms is the creation of new networks. One
can be observed within this PMO coordi- single case has been reported during
nation committee (see Table 4). There is interviews, but more may exist. Three
no doubt that the PMO coordination PMO regional directors decided to work
committee has been decided at the min- together outside of the committee. Even
istry level with the aim of succeeding in though they did not know each other
the implementation of the PHR. before the committee was put in place,
Therefore, it is quite far from the initial common interest has been identified
concept of community of practice where between them. They quickly recognized
practice is at the heart of a community that they shared a common way of look-
(Lave & Wenger, 1991). The approach is ing at PMO problems and solutions out-
rather one of instrumentalism of the side the scope of the PMO coordination
concept and integrated as a manage- committee. So, they identified a few of
ment tool as pinpointed recently by both these elements and met several times to
Learning Mechanisms Person Directly Involved Object of Knowledge
Participation in the PMO PMO director within the PMO implementation
Coordination Committee IT department at the Standardization of
national level processes; tools
PMO directors (or the Common language
equivalent) from the
18 regional agencies
Internal experts Not reinventing the wheel
Consultant that provides Inventory of projects at
methodology and associated regional and local levels
tools (portfolio embryo)
PMO director from the PHR
project
PMO director from the
dedicated IT supplier
Creation of New Three PMO directors at Sharing on solution
Networks (Outside regional agency
the Committee)
Table 4: Learning mechanisms from the PMO coordination committee.
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 51
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 52
Exploring PMOs Through Community of Practice Theory
PAPERS
work out solutions together. This
approach is more in line with the initial
approach of a community of practice.
But it would have no chance to happen
without the opportunity given by the
PMO coordination committee.
Situated Learning at the Regional
Level
The regional centers have a mission to
maintain and improve the health and
the well-being of their population
and to provide people with adapted
access to health and social services. The
regional center under study coordi-
nates 16 local health institutions. The
governance mechanisms other than the
internal instances (such as the board)
include four consulting regional com-
mittees, one of which recently formed
to work specifically on IT orientations.
A PMO has been put in place prior
to ministerial recommendation. The
regional center organizational chart
shows the PMO as an entity responsible
for a high-priority project financed by
the Ministry, the PHR. This PMO has
five employees, of which four are proj-
ect managers, with a majority of them
being consultants. A dynamic climate
existed within the PMO. A common
working room was installed with many
technological features helping in the
group work (Internet link, e-board,
etc.). The PMO from this regional cen-
ter was cited throughout the health care
network as a PMO success story.
However, the PMO’s reputation of
excellence did not prevent its disman-
tlement. At the time of these interviews,
there was one week left in the life of this
PMO. The aim of this article is not to
discuss the structural change in the
management of projects within this
regional center, but it must be taken
into account in the discourse.
Five learning mechanisms could
be identified from the analysis of the
interviews at this regional agency (see
Table 5). First, the PMO director partic-
ipated in the PMO coordination com-
mittee. At the implementation of their
own PMO, they received advice and
support on the methodology proposed
52 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
by the Ministry. Now, they are per- Third, the mission of this PMO is to
ceived as being a PMO model of suc- accompany and support the project
cess. They have implemented a PMO management within the region—in
for a longer period of time than other particular, projects that are undertaken
regional entities. They share their in local establishments to implement
regional experience within this com- the PHR project. Two large health cen-
mittee with PMO directors from other ters exist in this particular region. One
regional agencies. is a university hospital and the other is
The second mechanism relates to a youth center. Each one has several
the internal regional agency organiza- projects, but in fact, the university hos-
tion. The regional center PMO, at pital grabs the largest part of the
the time of interviews, was under the regional budget envelope. A PMO
finance department. The major project already existed at the university hospi-
within the PMO mandate was the PHR tal center. The relationship between
for which a special expertise was need- this PMO and the one at the regional
ed. An employee from the IT depart- center mostly involved directors of
ment had this expertise precisely. Not these PMOs and aimed at sharing expe-
only did this employee have the oppor- riences informally.
tunity to join the PMO as a project The fourth learning mechanism
manager, but he also had experience belongs to the relationship between the
with the methodology and tools and youth center and the PMO at the region-
constructively challenged them. The al center. This situation is quite different
fresh look from this newcomer to the from the previous one where the youth
PMO resulted in improved methodolo- center was looking for support in the
gy and tools. implementation of its first PMO. A senior
Learning Mechanisms Person Directly Involved Object of Knowledge
Participation in the Director of the PMO Obtain knowledge on
PMO Coordination specific methodology
Committee
Share experience on this
methodology and other
project management tools
and systems
Newcomer to the PMO Project manager within the Experiences by a
PMO and a new project newcomer of the PMO
manager from the IT methodology and tools in
department order to improve them
Ad-hoc Meeting PMO director at the regional Sharing experiences in
agency and the PMO PMO management
director at a local
establishment
Action Within the PMO Senior project manager at Transfer of knowledge in
Mission: To Accompany the regional agency PMO implementing a PMO
Project Management and PMO director at a local
establishment
Isolated Island Clinical experts and IT Management of clinical
project management projects
experts
Table 5: Learning mechanisms from a regional center.
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 53
project manager from the regional cen-
ter PMO worked closely with the new
PMO director at the youth center to
accompany and support her in this new
PMO implementation and in the related
cultural change.
The last learning mechanism chal-
lenges the well-being of a community
(Lave & Wenger, 1991). In the overall
health care system, projects and PMOs
are widely associated with IT, reasons
for this being the history of project
management and the importance of
the IT budget over all other project
components. However, within the
health care system, IT projects should
not have legitimacy if not related to a
clinical raison d’être. Recently, in this
particular regional agency, the clinical
experts are trying to assume the project
leadership, and in doing so, pushed
aside the IT experts who have the project
management expertise. The result is that
clinical experts have formed a regional
working committee on specific projects
where they do take major orientations for
project in a kind of isolated island. There
is neither an IT representative on this
committee or a project management
expert. Consequently, this creates some
confusion in the implementation of
solutions and all the knowledge devel-
oped in project management has been
forgotten.
Discussion and Conclusion
The national health care case study
included rich data that helps under-
stand how a community of PMOs
works.
Community and Practices
The examples presented show two dif-
ferent situations to observe both the
sense of a community and the practices.
The first one, the PMO coordination
committee, has been created officially
under a top-down by the IT department
in an instrumental view of a community.
However, a learning mechanism
occurred; the participants manifested
their passion to share and learn from each
other. Practices were mostly oriented
toward the PMO’s functions, such as
methodology and standards and port-
folio management. In the second exam-
ple, learning mechanisms emerged bot-
tom-up from the participants. Practices
varied depending on the need from
managing one specific project, helping
in the implementation of a PMO, and
sharing in the management of a PMO.
Network of Practice
In the field of project management, the
term community of practice is used
openly in all sorts of situations either
intraorganizational (e.g., communities
of practice for project managers) or
interorganizational (e.g., communities
of practice within a local PMI chapter
specifically on construction projects,
PMOs, etc.). The interpretation of what
a community of practice is depends on
the nature of the community itself; it is,
therefore, a product of the community
of practice (Duguid, 2008b). Duguid
(2008b) went back to the earlier approach
on apprenticeship and suggested a dis-
tinction between communities of prac-
tice and networks of practice. These are
two forms of knowledge networks that
may coexist within large organizations.
The distinction is based upon learning
to be versus learning about: “The for-
mer requires knowing how, the art of
practice, much of which lies tacit in a
community of practice. Learning about
requires the accumulation of knowing
that, which confers the ability to talk a
good game, but not necessarily to play
one” (Duguid, 2008b, p. 77). Explicit
knowledge contains only partially the
knowledge embedded in the communi-
ty of practice. In this perspective, face-
to-face interaction is almost necessary
to access the knowing how. However,
Duguid (2008b) proposed the concept
of network of practice to take into
account wide practice sharing within
large and decentralized organizations:
“The network of practice designates the
collective of all practitioners of a partic-
ular practice” (p. 78). Practices and
tools (know what) from the network of
practice are then reintroduced in a
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
process of embedding at the local level
(know-how) and within a local commu-
nity of practice.
Community of PMOs and PMOs
in Transition
A community of practice lasts as long as
the interest is vivid within its members.
But a question arises when the short life
of PMOs is considered, as shown in
the specific case of the national health
care organization. What happens to the
knowledge and the learning activity
going on within existing communities
of practice? What happens to the com-
munity? What happens to the practice?
The PMO transition challenges the con-
cept of situated learning where the his-
tory of a community of practice is taken
into account. What happens to the
masters? Is the commitment main-
tained over transformation of the situa-
tion? Future research should address
these questions. Therefore, knowledge
management within organizational
project management should directly
correlate with the challenge of the
economic-based economy.
Variety of Communities of PMOs
As PMOs show a wide variety of config-
urations, communities of PMOs might
as well show this diversity where prac-
tices will differ depending on PMO
functions and characteristics. Practices
are tightly linked to the functions PMOs
perform. From the present case study,
the more visible differences regarding
practices are related to project manage-
ment practices, as well as the more
specific PMO functions. Learning
mechanisms seem to be differentiated
based on the persons involved and on
the object of knowledge.
Cultural Influence
Communities of practice are embedded
in the cultural life in which they evolve
(Lave & Wenger, 1991). There is no sin-
gle definition of culture, but following
Henrie and Sousa-Poza (2005), we
adopted Hofstede’s definition: “the col-
lective programming of the mind which
53
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 54
Exploring PMOs Through Community of Practice Theory
PAPERS
distinguishes the members of one
group of category of people from
another” (1997, p. 5). In our research,
cultural groups could be identified at
two levels: the country and the commu-
nities of PMOs.
At the country level, this article
examines communities of practice
within a single-case study. Four organi-
zations have been targeted as part of
our data collection design. They were
chosen for their cultural diversity in
terms of: (1) countries (four); (2) private
(two)/public (one)/mutual (one);
(3) industry (health care, manufacturing,
telecommunications, and banking);
and (4) physical (three) and virtual PMO
(one). To that end, we contextualize the
case—analyses within cultural com-
monality as opposed to cultural differ-
ences, especially as neither case studies
by themselves nor the sampling
approach chosen would allow for more
than speculative results about cultural
influences or differences (i.e., one data
point per country). When the full
data collection and analysis is done,
this cultural aspect will be taken into
consideration.
The cultural aspect should also be
taken into account within the commu-
nities of PMOs. As shown in the health
care case, communities of practice
allow individuals from different internal
or even external units to participate in a
common social network. Even within
the same type of organization and the
same country, each of these individuals
comes from a culturally different mind-
set within their own local innovation
field (J. S. Brown & Duguid, 2001).
Cultural issues seem to play an influen-
tial role in the knowledge dynamic
process within communities of practice.
In conclusion, preliminary results
from this research seems to shed light
on the role that PMOs can play as driv-
ers of knowledge management within
organizations. Qualitative case studies
within the national health care network
described previously illustrate the
interplay between PMOs being part of
communities of PMOs. Multiple social
54 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
networks have become visible in shar- Bredillet, C. N. (2004). Projects:
ing concrete practices within learning Learning at the edge of organization.
mechanisms. More work still needs to In P. W. G. Morris & J. K. Pinto (Eds.),
be done. Yet, results from this research The Wiley guide to managing projects
confirm that the community of practice (pp. 1112–1136). Hoboken, NJ: Wiley.
theory presents legitimacy in the study Bredillet, C. N. (2007). From the editor:
of knowledge management within Exploring research in project manage-
organizational project management. ■ ment: Nine schools of project
management research (part 1). Project
References Management Journal, 38(2), 3–4.
Abril, R., & Müller, R. (2009). Lessons
Bredillet, C., Ruiz, P., & Yatim, F. (2008,
learned as organizational project
July). Investigating the development of
memories. In J. Girard (Ed.), Building
project management: A time-distance
organizational memories: Will you
analysis approach of G8, European G6,
know what you knew? (pp. 97–114).
and outreach 5 countries. Paper pre-
New York: Information Science
sented at the 2008 PMI Research
Reference.
Conference, Warsaw, Poland.
Almeida, P., & Kogut, B. (1999).
Breschi, S., Lissoni, F., & Montobbio, F.
Localization of knowledge and the
(2007). The scientific productivity of aca-
mobility of engineers in regional net-
demics inventors: New evidence from
works. Management Science, 45(7),
Italian data. Economics of Innovation
905–917.
and New Technology, 16(2), 101–118.
Arthur, M. B., DeFillippi, R. J., & Jones,
Bresnen, M., Edelman, L., Newell, S.,
C. (2001). Project-based learning as the
Scarbrough, H., & Swan, J. (2003).
interplay of career and company non-
Social practices and the management
financial capital. Management
of knowledge in project environments.
Learning, 32(1), 99–117.
International Journal of Project
Association for Project Management.
Management, 21(3), 157–166.
(2000). Project management body of
Brookes, N. J., Morton, S. C., Dainty,
knowledge. Cambridge, UK: Dixon Miles.
A. R. J., & Burns, N. D. (2006). Social
Aubry, M., Hobbs, B., & Thuillier, D.
processes, patterns and practices and
(2007). A new framework for under-
project knowledge management:
standing organisational project man-
A theoretical framework and an
agement through PMO. International
empirical investigation. International
Journal of Project Management, 25(4),
Journal of Project Management, 24(6),
328–336.
474–482.
Aubry, M., Müller, R., Hobbs, B., &
Brown, J. S., & Duguid, P. (2001).
Blomquist, T. (2009, October). Project
Knowledge and organization: A social-
management offices in transition.
practice perspective. Organization
Paper presented at the International
Science, 12(2), 198–213.
Research Network on Organizing by
Projects Conference, Berlin, Germany. Brown, S. L., & Eisenhardt, K. M.
(1997). The art of continuous change:
Bellini, E., & Canonico, P. (2008).
Linking complexity theory and time-
Knowing communities in project-
paced evolution in relentlessly shifting
driven organizations: Analysing the
organizations. Administrative Science
strategic impact of socially constructed
Quarterly, 42(1), 1–34.
HRM practices. International Journal
of Project Management, 26(1), 44–50. Bruner, J. (1996). The culture of educa-
Blackburn, S. (2002). The project man- tion. Cambridge, MA: Harvard
ager and the project-network. University Press.
International Journal of Project Clarke, T. (2004). The stakeholder cor-
Management, 20(3), 199–204. poration: A business philosophy for
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 55
the information age. In T. Clarke (Ed.),
Theories of corporate governance: The
philosophical foundations of corporate
governance (pp. 189–202). London:
Routledge.
Corbin, J., & Strauss, A. L. (1990).
Grounded theory research: Procedures,
canons, and evaluative criteria.
Qualitative Sociology, 13(1), 3–21.
Crawford, L., & Cooke-Davies, T. J.
(2005, September). Project governance:
The pivotal role of the executive spon-
sor. Paper presented at the PMI Global
Congress North America, Toronto,
Canada.
Duguid, P. (2008a). Prologue:
Community of practice then and now.
In A. Amin & J. Roberts (Eds.),
Community, economic creativity, and
organization (pp. 1–10). Oxford, UK:
Oxford University Press.
Duguid, P. (2008b). The art of knowing:
Social and tacit dimensions of knowl-
edge and the limits of the community
of practice. In A. Amin & J. Roberts
(Eds.), Community, economic creativity,
and organization (pp. 69–89). Oxford,
UK: Oxford University Press.
Eisenhardt, K. M. (1989). Building the-
ories from case study research.
Academy of Management Review, 14(4),
532–550.
Fernie, S., Green, S. D., Weller, S. J., &
Newcombe, R. (2003). Knowledge
sharing: Context, confusion and con-
troversy. International Journal of
Project Management, 21(3), 177–187.
Gertler, M. S. (2003). Tacit knowledge
and the economic geography of con-
text, or the undefinable tacitness of
being (there). Journal of Economic
Geography, 3(1), 75–99.
Gibson, C. B., & Birkinshaw, J. (2004).
The antecedents, consequences, and
mediating role of organizational
ambidexterity. Academy of
Management Journal, 47(2), 209–226.
Glückler, J. (2008). Islands of expert-
ise—Global knowledge transfer in a
technology service firm. SPACES
online, 6(03). Retrieved from
http://www.spaces-online
.uni-hd.de/include/SPACES 2008-03
Glueckler.pdf
Henrie, M., & Sousa-Poza, A. (2005).
Project management: A cultural litera-
ture review. Project Management
Journal, 36(2), 5–14.
Hobbs, B., & Aubry, M. (2007). A multi-
phase research program investigating
project management offices (PMOs):
The results of phase 1. Project
Management Journal, 38(1), 74–86.
Hobbs, B., & Aubry, M. (2008). An
empirically grounded search for a
typology of project management
offices. Project Management Journal,
39(S1), S69–S82.
Hobbs, B., & Aubry, M. (2010). The
project management office or PMO: A
quest for understanding. Newtown
Square, PA: Project Management
Institute.
Hofstede, G. H. (1997). Cultures and
organizations: Software of the mind.
New York: McGraw-Hill.
Jick, T. D. (1979). Mixing qualitative
and quantitative methods:
Triangulation in action. Administrative
Science Quarterly, 24(4), 602–611.
Keegan, A., & Turner, R. J. (2001).
Quantity versus quality in project-
based learning practices. Management
Learning, 32(1), 77–98.
Kotnour, T. (1999). A learning frame-
work for project management. Project
Management Journal, 30(2), 32–38.
Kotnour, T. (2000). Organizational
learning practices in the project man-
agement environment. International
Journal of Quality & Reliability
Management, 17(4/5), 393–406.
Lave, J. (2008). Epilogue: Situated
learning and changing practice. In A.
Amin & J. Roberts (Eds.), Community,
economic creativity, and organization
(pp. 283–296). Oxford, UK: Oxford
University Press.
Lave, J., & Wenger, E. (1991). Situated
learning: Legitimate peripheral partici-
pation. New York: Cambridge
University Press.
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Lazega, E. (2001). The collegial phe-
nomenon: The social mechanisms of
cooperation among peers in a corporate
law partnership. Oxford, UK: Oxford
University Press.
Lazega, E., & Pattison, P. E. (2001).
Social capital as social mechanisms
and collective assets. In N. Lin, K. S.
Cook, & R. Burt (Eds.), Social capital:
Theory and research (pp. 185–208).
New York: Aldine-de Gruyter.
Manning, S. (2005). Managing project
networks as dynamic organizational
forms: Learning from the TV movie
industry. International Journal of
Project Management, 23(5), 410–414.
Mead, S. P. (2001). Using social net-
work analysis to visualize project
teams. Project Management Journal,
32(4), 32–38.
Merriam-Webster. (2007). Merriam-
Webster’s collegiate dictionary (11th ed.).
(2007). Springfield, MA: Author.
Miles, M. B., & Huberman, A. M.
(1994). Qualitative data analysis: A
source book of new methods. Beverly
Hills, CA: Sage.
Mitchell, J. C. (1969). The concept and
use of social network. In J. C. Mitchell
(Ed.), Social networks in urban
situations: Analysis of personal rela-
tionships in central African towns
(pp. 1–50). Manchester: Manchester
University Press.
Müller, R. (2009). Project governance.
Aldershot, UK: Gower.
Nonaka, I., & Takeuchi, H. (1995). The
knowledge-creating company. New
York: Oxford University Press.
Nonaka, I., & von Krogh, G. (2009).
Tacit knowledge and knowledge con-
version: Controversy and advancement
in organizational knowledge creation
theory. Organization Science, 20(3),
635–652.
Ouchi, W. G., & Maguire, M. A. (1975).
Organizational control: Two functions.
Administrative Science Quarterly, 20(4),
559–569.
Powell, W. W., Koput, K. W., & Smith-
Doerr, L. (1996). Interorganizational col-
laboration and the locus of innovation:
55
42-56PMJ0808.qxd 8/8/11 12:20 PM Page 56
Exploring PMOs Through Community of Practice Theory
PAPERS
Networks of learning in biotechnology.
Administrative Science Quarterly, 41(1),
116–145.
Project Management Association of
Japan. (2008). Project & program man-
agement (P2M): Project and program
management for enterprise innovation.
Tokyo: Author.
Project Management Institute. (2008).
A guide to the project management
body of knowledge (PMBOK® guide)
(4th ed.). Newtown Square, PA: Author.
Project Management Institute. (2009).
Communities of practice. Retrieved
from http://www.pmi.org/Get
Involved/Pages/Communities-of
-Practice.aspx
Pryke, S., & Pearson, S. (2006). Project
governance: Case studies on financial
incentives. Building Research &
Information, 34(6), 534–545.
Reagans, R., & McEvily, B. (2003).
Network structure and knowledge
transfer: The effects of cohesion and
range. Administrative Science
Quarterly, 48(2), 240–267.
Scarbrough, H., & Swan, J. (2008).
Project work as a locus of learning: The
journey through practice. In A. Amin &
J. Roberts (Eds.), Community, economic
creativity, and organization (pp.
148–177). Oxford, UK: Oxford
University Press.
Scott, J. (2000). Social network analy-
sis: A handbook (2nd ed.). London:
Sage.
Sense, A. J., & Badham, R. J. (2008).
Cultivating situated learning within
project management practice.
International Journal of Managing
Projects in Business, 1(3), 432–438.
Sorenson, O., & Waguespack, D. M.
(2005). Research on special networks
and the organization of research and
development: An introductory essay.
Journal of Engineering and Technology
Management, 22(1–2), 1–7.
Strauss, A. L., & Corbin, J. (1998).
Basics of qualitative research:
Techniques and procedures for develop-
ing grounded theory (2nd ed.).
Thousand Oaks, CA: Sage.
56 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Tsai, W. (2001). Knowledge transfer in
intraorganizational networks: Effects of
network position and absorptive
capacity on business unit innovation
and performance. Academy of
Management Journal, 44(5), 996–1004.
Turner, J. R., & Müller, R. (2003). On
the nature of the project as a tempo-
rary organization. International
Journal of Project Management, 21(1),
1–8.
Turner, J. R., & Müller, R. (2004).
Communication and co-operation on
projects between the project owner as
principal and the project manager as
agent. European Management Journal,
22(3), 327–336.
Wasserman, S., & Faust, K. (1994).
Social network analysis: Methods and
applications. Cambridge, UK:
Cambridge University Press.
Wenger, E., & Snyder, W. M. (2000).
Community of practice: The organiza-
tional frontier. Harvard Business
Review, 78(1), 139–145.
Williams, T. (2007). Post-project reviews
to gain effective lessons learned.
Newtown Square, PA: Project
Management Institute.
Williams, T. (2008). How do organiza-
tions learn lessons from projects—And
do they? IEEE Transactions on
Engineering Management, 55(2),
248–266.
Yin, R. K. (2003). Case study research:
Design and methods (3rd ed.). London:
SAGE.
Monique Aubry, PhD, is a professor in the School
Business and Management, at the University of
Quebec at Montreal (UQAM). Her principal
research interest is in the area of organizing for
projects and organizational design, more specifi-
cally in project management offices. Her second
important research area is polar expeditions,
where she scrutinized the planning process to
learn about flexibility. The results of her work
have been published in major academic journals
and presented to several international confer-
ences, both research and professional. She is
member of the Project Management Research
Chair (www.pmchair.uqam.ca). Before joining
UQAM, she was a project manager in a major
Canadian financial group for more than 20
years. She is a member of PMI’s Standards MAG.
She is involved in the local PMI community of
practice on PMOs, where she contributes to rein-
forcing the links between professionals and
researchers.
Ralf Müller is a professor at Umeå University in
Sweden and at BI Norwegian Business School
in Norway. He lectures and researches in proj-
ect management and governance as well as in
research methodologies. He is the author or
coauthor of more than 100 publications, for
which he received, among other accolades, the
Project Management Journal’s 2009 Paper of
the Year, 2009 International Research Network
on Organizing by Projects’s Best Conference
Paper Award, and several Emerald Literati
Network Awards for outstanding journal papers
and reviewer work. He holds an MBA from
Heriot Watt University and a DBA degree from
Henley Management College at Brunel
University in the United Kingdom. Before join-
ing academia, he spent 30 years in the indus-
try consulting with large enterprises and gov-
ernments in 47 different countries for their
project management and governance. He also
held related line management positions, such
as the worldwide director of project manage-
ment at NCR Teradata.
Johannes Glückler is a professor of economic and
social geography and research fellow at the Marsilius
Center for Advanced Study at the University of
Heidelberg. He received his PhD from the University
of Frankfurt. Previously, he was a professor of eco-
nomic geography at the Catholic University of
Eichstätt-Ingolstadt. His research interests are in
the areas of economic geography, social networks,
and service industries. He has written on relational
economic geography, the geography of knowledge,
and organizational networks in journals such as
Organization Studies, the Journal of Economic
Geography, Regional Studies, and the Service
Industries Journal. He is coauthor of the mono-
graph The Relational Economy (Oxford University
Press, 2011), which analyzes the geographies of
knowing and learning in the global knowledge
economy.
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 57

PAPERS
Cultural Patterns Influencing Project
Team Behavior in Sub-Saharan Africa:
A Case Study in Ethiopia
Fanta Tesgera Jetu, College of Telecommunications and Information Technology,
Addis Ababa, Ethiopia
René Riedl, Johannes Kepler University, Linz, Austria
Friedrich Roithmayr, Johannes Kepler University, Linz, Austria

ABSTRACT ■
Despite the increasing attention paid to the
human element of project success found in
the project management literature, empirical stud-
ies exploring cultural patterns influencing this
particular human element continue to be far
from satisfactory. To help further understand
the influence of cultural patterns within Sub-
Saharan Africa project environments, we draw
on a case study conducted in Ethiopia’s service
sector. Apart from the well-perceived cultural
values commonly referred to in the existing lit-
erature, we specifically investigated the deep-
rooted underlying causes, which include
Ethiopian cultural habits, as a principal factor in
influencing project team behavior. The article
concludes with implications and recommenda-
tions for future research.
KEYWORDS: cultural patterns; values;
habits; project team behavior; project success;
Ethiopia; Sub-Saharan Africa
Project Management Journal, Vol. 42, No. 5, 57–77
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20260
INTRODUCTION ■
he human element of project success has received increasing atten-
T tion in the project management literature, and several studies have
drawn attention to its growing importance in the successful comple-
tion of projects (Belout, 1998; Belout & Gauvreau, 2004; Cooke-
Davies, 2002; Kliem & Ludin, 1992; Smyth & Morris, 2007).
Notwithstanding the contributions of research to date, empirical stud-
ies exploring the cultural patterns influencing this particular human ele-
ment continue to be far from satisfactory. Significant gaps still exist in our
understanding of how cultural patterns influence project team behavior in
project team settings. In spite of the theoretical advancements in this area,
empirical research has not developed at the same pace (Henrie & Sousa-
Poza, 2005). Only a limited number of empirical studies exist, and these
studies provide useful insight into the impact that culture has on projects
(Bredillet, Yatim, & Ruiz, 2010; Camprieu, Renaud, & Feixue, 2007; Kendra &
Taplin, 2004; Shore & Cross, 2005; Zewikael, Shimizu, & Globerson, 2005). In
recent years, there have been encouraging signs that the topic is attracting
greater attention (Henrie & Sousa-Poza, 2005; Kendra & Taplin, 2004; Rees,
2004; Soderlund, 2004). Researchers have continued to call for empirical
work in areas, including (1) behavior of project organizations (Soderlund,
2004), (2) the different norms of behavior and decision-making patterns of
people (Zewikael et al., 2005), and (3) the linkage of the cultural dimensions
with respect to project management issues (Shore & Cross, 2005), among
others.
In this context, we sought to explore the cultural and behavioral dimen-
sions of project management that, to date, have not received sufficient
attention. Henrie and Sousa-Poza (2005) indicate that the culture team
members bring with them to a project work environment can considerably
influence their contributions to project success. Baiden, Price, and Dainty
(2006, p. 21) most notably argue that “the behavior of people needs to
change in order to create an appropriate project culture for successful proj-
ect delivery. A key challenge, therefore, is to replace traditional project driv-
ers with outcomes related to behavioral and cultural improvement.”
Research needs to embrace and address this challenge, an area that contin-
ues to offer interesting avenues for future research. Empirical studies in this
area can help practitioners, and project managers in particular, further
understand the impacts of cultural and behavioral factors with regard to the
human element of project success.

September 2010 ■ Project Management Journal ■ DOI: 10.1002/pmj 57

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 58
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
This study has been designed to
explore the cultural patterns influencing
project team behavior within Sub-
Saharan Africa (SSA)1 project environ-
ments through case study research
conducted in Ethiopia’s service sector.
Despite the diversity and lack of homo-
geneity, African countries share similar
features and histories that transcend
organizational boundaries (Beugre &
Offodile, 2001; Blunt & Jones, 1997;
Jones, 1988). Beugre and Offodile (2001,
p. 537) write: “Cultural patterns such as
respect for elders, consensus decisions,
respect for authority, family orientation,
collectivism, etc., appear to characterize
most African countries.” A similar view
is also shared by Muriithi and Crawford
(2003). Generally, developing countries
share similar cultural features owing to
the similarities in their historical back-
grounds, subsistence economic condi-
tions, unstable political environment,
and sociodemographic makeup (Aycan,
2002).
Studies that have discussed the cul-
tural contexts of SSA are reasonably sub-
stantial, although their review is beyond
the scope of this study. There are well-
perceived cultural values commonly
referred to in the existing literature that
characterize project environments in
SSA, and these include traditionalism
(Adigun, 1995; Beugre & Offodile, 2001;
Jones, 1988; Nzelibe, 1986), extended
family orientation (Beugre & Offodile,
2001; Hofstede, 1983; Muriithi &
Crawford, 2003; Nzelibe, 1986; Seriki,
2007), weak institutional collectivism
(Blunt & Jones, 1997), high-context com-
munication (Beugre & Offodile, 2001;
House, Hanges, Javidan, Dorfman, &
Gupta, 2004; Muriithi & Crawford, 2003),
autocratic leadership, bureaucratic con-
trols, and procedures (Beugre & Offodile,
2001; Muriithi & Crawford, 2003; Seriki,
2007), among others. These prevailing
cultural patterns are believed to largely
inhibit productivity, undermine proper
communication and transparency,
1According to Beugre and Offodile (2001), SSA is a region
that excludes the Arab countries of North Africa.
58 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
restrain individual initiatives and com-
mitment, and instead encourage shirk-
ing accountability and responsibility.
Only a few studies (Muriithi &
Crawford, 2003; Seriki, 2007) have dealt
with the specific cultural contexts influ-
encing projects or innovative team per-
formance across organizations in SSA;
hence, further investigation into the
specific cultural patterns influencing
project team behavior is important in
order to redefine the conventional
practices underpinning project team
management, particularly in Ethiopia,
as well as in SSA in general.
To put the article in perspective and
provide a theoretical framework for the
study, we will start with the conceptual
definitions of culture and project
success. We will provide insight and
summarize the study’s background,
introduce a case study project that was
designed and conducted to provide
empirical evidence in support of cultur-
al patterns, and particularly cultural
habits, influencing project team behav-
ior in an Ethiopian context. Finally, we
will conclude the study and highlight its
implications and limitations and pro-
vide suggestions for pursuing future
research.
Theoretical Framework
Numerous definitions of culture can be
found in the body of literature. Javidan
and House (2001, p. 292), for example,
define culture as “a set of beliefs
and values about what is desirable and
undesirable in a community of people,
and a set of formal or informal practices
to support values.” The definition by
Hodgetts, Luthans, and Doh (2006,
p. 583) provides a better understanding
in the context of this study. These
authors define culture as “the acquired
knowledge that people use to interpret
experience and generate social behav-
ior. This knowledge forms values, cre-
ates attitudes, and influences behavior.”
Thus, differences in human attitudes
and behavior can be explained based on
the value priorities people hold and the
relative importance they attach to such
values (Schwartz, 2006). For Schwartz,
culture explains the motivational basis
of attitudes and behavior.
Beugre and Offodile (2001, p. 537)
identify two elements of cultural pat-
terns in a society: cultural values and
cultural habits. The former are ele-
ments of a given society that people
consider important, give credit to, and
strive to achieve; the latter, however, are
patterns of behaviors observed in a cul-
ture and that are not necessarily valued
because they are not considered
acceptable norms of behavior. Cultural
values, which are espoused values
viewed as the correct ways to perceive,
think, and act, refer to what is desirable
in a society, whereas cultural habits,
which are practiced but not viewed as
valid and acceptable norms of behav-
ior, refer to what is undesirable (Javidan
& House, 2001).
Cultural patterns are manifested in
human behavior in three forms: activi-
ties, interactions, and sentiment (Hoegl
& Gemuenden, 2001). Activities are
reflected in actions that are relevant to
achieving goals, whereas interactions
are expressed in terms of interrelations,
communication, and influence
processes involved among people.
Moreover, sentiment is invisible and is
influenced by both activities and inter-
actions. At the team level, two types of
behaviors pertaining to team members
can be distinguished: task behavior and
teamwork behavior (Rousseau, Aube, &
Savoie, 2006). According to Rousseau
et al., task behaviors are those that are
inherent in the technical aspects of the
task, whereas teamwork behaviors
characterize work teams. The first is
needed to contribute directly to task
accomplishment, whereas the latter is
needed to ensure shared understand-
ing and the viability of working teams;
hence, neither is very useful without
the other in project team settings. Both
behaviors can influence the outcome
on a team level, so it is necessary to
understand how cultural patterns influ-
ence project team behavior in a project
team setting, which has a significant
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 59
Cultural
Project Team
Patterns
Values Behavioral
Manifestation
(Interactions,
Activities, and
Habits Sentiment)
Figure 1: Theoretical framework.
and direct effect on project success. The
topic merits more research attention,
considering the potential to improve
the functioning of project team behav-
ior in the SSA region.
As indicated in the theoretical
framework in this study (Figure 1), the
relationships between cultural patterns
and project team behavior are depicted
with arrows, which indicate the pre-
sumed direction of influence. Figure 1
provides an overview of how cultural
patterns influence project team behav-
ior and is useful in understanding how
project team behavior relates to project
success. By and large, cultural patterns
(i.e., cultural values and cultural habits)
have a direct impact on project team
behavior and tend to manifest them-
selves in both teamwork and task
behavior, an understanding that is cen-
tral to project success.
Apparently, project success is a
well-established area of study in project
management literature; nevertheless,
its definition and measurement still
remain nebulous and have been per-
ceived differently by different partici-
pants (Jugdev & Müller, 2005; Shenhar,
Tishler, Dvir, Lipovetsky, & Lechler,
2002). A universally accepted definition
has not yet been established, although
there seems to be a general consensus
that typically views project success
along two components: project man-
agement success and product success
(Baccarini, 1999; Cooke-Davies, 2002).
Project Team
Context
Behavior
Teamwork
Behavior
Project
Success
Task
Behavior
First, a project can be considered suc-
cessful if the target values regarding
performance (time, cost, and quality)
are met. Second, a project can be consid-
ered successful if the effects of the
project meet expectations (increased pro-
ductivity, enhanced creativity and prob-
lem solving, employee satisfaction and
commitment, quality services and cus-
tomer satisfaction, and so forth).
Interestingly, the focus of project
management research has been pre-
dominantly on performance; hence,
the construct of soft measures has been
less addressed. Given that our focus is
on projects that relate to organizational
improvement and change programs, we
chose to limit our definition of project
success to achieving expectations from
business process reengineering (BPR)
and information technology (IT) proj-
ects through developing and changing
the project team’s values, attitudes, and
behavior that support the implementa-
tion of these projects (Beugre &
Offodile, 2001; Hammer & Champy,
1995). Although such changes are not
sufficient on their own to meet the
desired expectations, they are essential
in helping project teams work in a more
integrated manner to ensure lasting
organizational improvement and
change programs in Ethiopia in partic-
ular and SSA in general.
It needs to be stated that achieving
project success, be it project manage-
ment success or product success, is
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
obviously a complex process, inde-
pendent of success assessment. Several
factors, such as political, economic,
technological, competitive, and stake-
holder interests, have influences on
project success (Belassi & Tukel, 1996;
Camprieu et al., 2007; Fortune & White,
2006; Gray, 2001; Leybourne, 2007;
Neal, 1995). Moreover, projects are not
free from the influence of organization-
al climate and upper management
style, which particularly affects project
success (Gray, 2001).
A number of studies (Camprieu
et al., 2007; Gray, 2001; Seriki, 2007)
provide a conceptual framework with
which to analyze the impact of exoge-
nous and endogenous factors on proj-
ect success. The framework by
Camprieu et al. includes cultural, indi-
vidual, socioeconomic, and situational
factors. The framework by Seriki (2007),
which examines the influence of socie-
tal contexts on innovative team per-
formance within organizations in SSA,
also includes demographic forces, cul-
tural forces, and institutional forces. In
essence, the factors influencing project
success are quite diverse, ranging from
project team behavior to global con-
texts within which project activities are
bounded. This study acknowledges
the difficulty in clearly delineating the
influence of project team behavior,
when in fact project success is typically
the outcome of the dynamic interac-
tions between and among these factors.
Because these factors are usually
different in their nature and interrelat-
ed, an understanding of how these
factors influence project success is rele-
vant to both academicians and practi-
tioners. It is important to note, however,
that some of these factors are usually
outside the control of project managers
(e.g., global contexts); hence, project
management has to focus on the types
of factors that can be controlled, or at
least influenced.
Background of the Study
After Nigeria, Ethiopia is the second
most populated nation in Africa. The
59
57-77PMJ0808.qxd 8/8/11 12:21 PM
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
country is home to many ethnic groups
with different languages, cultures, and
traditions, making it one of the most
ethnically diverse nations in Africa. A
centralized state system is a very recent
historical development, which has
been shaped over time and culminated
close to the end of the nineteenth cen-
tury (Levine, 2000). At present, the
country is a federal republic, ruled
under its 1994 constitution. The econo-
my’s mainstay is agriculture. Ethiopia is
yet one of the world’s poorest nations,
with untapped resources and growth
potential.
Since the introduction of a free
market economy in 1991, the govern-
ment has embarked on the initiation of
different reform packages, such as
commercialization of agriculture,
industry and private-sector develop-
ment, and the improvement of infra-
structure and public services to achieve
sustainable socioeconomic develop-
ment in the country (Ministry of
Finance and Economic Development,
2006). The liberalization of the econo-
my brought in its wake major changes
to the structure and level of economic
activities. Private sector organizations
have expanded tremendously and, as a
result, various spheres of the economy
have enjoyed steady growth in private
investment capital projects over the last
15 years. For example, from 1992 to
1993 through 2006 to 2007 alone, the
sum of investment capital worth US
$36.65 billion,2 for a total of 25,835 proj-
ects, was approved by the government
(National Bank of Ethiopia, 2006/2007).
Nevertheless, there remains a long way
to go in order to reap the benefits of these
reform packages as outlined by the govern-
ment. For example, the Ethiopian Herald
(“Business Process Re-engineering,” 2009,
p. 8) acknowledges that “the stunning
successive growth in the economic
sector has so far not been accompanied
by efficient and effective service sectors.
This reality has called for a reform
2The exchange rate applied was Birr 9.6081/US $ as of
June 30, 2008.
60 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Page 60
program and re-engineering in the pub-
lic sector” (italics added). Recognizing
that the service sector, which has con-
tributed about 43 percent of the gross
domestic product (GDP), in addition to
agriculture over the last 15 years
(Ethiopian Economic Association [EEA],
2007), is a critical success factor needed
to support economic growth, so the gov-
ernment has taken successive measures
to reform the sector.
Thus, organizationwide transfor-
mational programs targeting processes,
structure, technology, and people
(Hammer & Champy, 1995; Heeks,
2002) have come and gone under differ-
ent names over the last 18 years: the
civil service reform program initiated in
1993, the performance and service
delivery improvement program piloted
in 2001, and BPR launched in 2005
(“Business Process Re-engineering,”
2009). Mengesha and Common (2006,
p. 4), for example, indicated:
With a view to realize comprehen-
sive “state transformation” and
“total system overhaul” and in line
with recommendations forwarded
by the World Bank, as in the case of
African countries in general, the
Ethiopian government has
embarked on multiple public
administration reforms since the
early 1990s.
Recently, several organizations
(both public and private) within the
service sector have been moving toward
BPR projects, with the goals of address-
ing and meeting new challenges as well
as responding to customer-driven qual-
ity services. IT projects are usually
considered part of a wider initiative to
integrate technology solutions with
organizational change projects and fun-
damentally change the state of service
provisions—make great strides in terms
of organizational efficiency and per-
formance (Hammer & Champy, 1995).
Project teams (with diverse knowl-
edge, skills, and experience) are rou-
tinely created in order to handle and
implement these organizational change
projects. Although the increased use of
project teams is related to higher proj-
ect success (Thamhain, 2004a; Webber,
2002), the expected change has not come
fast enough, and insufficient progress
has been made so far in most organiza-
tions, particularly in the public service
sector. BPR is still in an experimental
phase, and there are only a handful of
success stories in some sections of gov-
ernment ministries (“Business Process
Re-engineering,”2009). In order to
assess the impact of BPR projects,
Mengesha and Common (2006), for
example, conducted small-scale sur-
veys in two government ministries and
proceeded to discover promising
achievements in both performance and
user satisfaction by implementing
major improvements in the service
delivery system.
From a cultural perspective, it is
important to understand the reasons
that have undermined project team
efforts and hindered project success.
These are of paramount significance
and must be addressed or project
teams will be unable to sustain and fur-
ther bolster the positive developments
attained thus far. This study is meant to
provide the initial evidence and give
some confidence in the validity of this
claim. Studying cultural patterns and
changing people’s attitudes and behav-
iors are generally viewed as important
components (antecedent and critical
success factors) of organizational
change projects (Beugre & Offodile,
2001; Hammer & Champy, 1995). This
requires prior investigation and reflec-
tions on the nature of cultural patterns
that have the greatest influence on
project team behavior. More specifical-
ly, the cultural habits that influence
project team behavior are worth
exploring based on the personal experi-
ences of project experts in the field. The
following section presents empirical
findings from a case study conducted
in Ethiopia, which sought to find an
explanation and shared understanding
by project experts on the cultural habits
influencing their behavior.
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 61

The Case Study involving experts working on BPR and age, participants ranged from 31 to 51
IT projects within the service sector. years. They had diversified qualifications,
Method
First, we selected ten private and which included the fields of business/
This case study, aimed at generating a
public organizations within the banking economics (50%), computer science/
greater understanding of the influence
and utility subsectors. To obtain nation- information technology (31%), statis-
of cultural habits on project team
al-level insights, the selection of sample tics/mathematics (13%), and engineer-
behavior in real project team settings,
organizations focused on those that rep- ing (6%). Over 60% of the participants
lends itself more readily to a qualitative
resent major institutional forms and have earned a postgraduate degree, and
approach (Patton, 1990; Punch, 2005;
provide services for profit. A preliminary their work experience ranges from 10 to
Strauss & Corbin, 1998). Qualitative
survey was conducted within the chosen 15 years and over. Almost all of the par-
methods are generally believed to con-
organizations to obtain data on total ticipants have been involved in various
tribute to “practical problem solving,
staff, capital, annual turnover, the num- projects and are senior officials within
decision making, action research, poli-
ber of staff working on BPR and IT proj- their respective organizations. Approxi-
cy analysis, organizational and com-
ects, and the budgets allotted for these mately 50% of the participants have
munity development” (Patton, 1990,
projects. The survey revealed that the worked as project directors and managers
p. 94). These methods can help to reveal
number of employees in these organiza- in BPR and IT project works, whereas the
insights that might not otherwise be
tions ranged from a minimum of 446 to a remaining 50% have been involved main-
apparent through traditional means—
maximum of 12,688. The annual ly as project coordinators/team leaders
the quantitative paradigm—by empha-
turnover ranged from a minimum of and members. More than 50% of them
sizing the lived experiences of people in
US $4.48 million to a maximum of US have been involved in more than five proj-
the field (Strauss & Corbin, 1998).
$957.42 million, whereas the total capital ect team assignments within their respec-
Drawing on elements from an
ranged from US $13.84 million to US tive organizations (Appendix B).
exploratory case study (Punch, 2005;
$2.14 billion. The total number of staff
Yin, 2003), as well as the design and
members working on these projects
implementation of focus group inter-
within the selected organizations was Procedure
views (Krueger, 1988), this study
854. The budgets allotted for these proj- The focus group interview was con-
attempts to obtain multiple perspec-
ects ranged from US $0.57 million to US ducted following the guidelines and
tives by learning more about the feel-
$117.19 million (Appendix A). procedures recommended by Krueger
ings, perceptions, viewpoints, and
Second, to avoid sample bias and in (1988). To allow for sufficient prepara-
beliefs of project experts on the cultural
consultation with the collaborating tion and to help build the participants’
habits influencing their behavior. A
organizations, 30 people (three from confidence, each interviewee was given
focus group interview is the most
each of the 10 organizations) working an outline of the interview program
attractive data-gathering option when
on these projects were formally invited to in advance (purpose, date, time, venue,
research is trying to probe, gain deeper
participate in an interview. In order and points of discussions) and infor-
insight, and develop explanations of the
to address reliability and validity issues, med of the expectations. To maintain
various aspects of human behavior
the selection process took into consid- maximum neutrality and objectivity,
(Punch, 2005). The goal is “not to infer
eration participants with relevant and participants were assured of confiden-
but understand, not to generalize but to
solid experience in project team assign- tiality before, during, and after the
determine the range, and not to make
ments. Moreover, the sample in each interview; they were also informed that
statements about the population but to
organization consisted of project man- they took part in the interview based on
provide insights about how people per-
agers, coordinators/team leaders, and their expertise in the field, because the
ceive a situation.” (Krueger, 1988, p. 96)
experts/officers—all members along study was not focused on any current
The insight and data provided by
the project hierarchy. In order to obtain decision-making processes or any par-
focus group interviews give us a basis
diverse opinions, experiences, and ticular decision made in the past with
with which to examine changing views
achieve patterns of common under- regard to their respective organizations.
and develop an understanding of exist-
standing shared by the majority of The interviews were conducted in
ing cultural patterns, particularly cul-
members from the wider population, two rounds, during a half-day time
tural habits, as well as obtain a thorough
efforts were made to maintain a mix of period, and each interview lasted four
picture of how they influence project
participants in terms of age, gender, hours. As a rule of thumb, conducting
team behavior in project team settings.
and educational background. more than two rounds of focus group
Sample and Sample Characteristic The participant’s demographic interviews depends on the value of
As a whole, the study consists of two information revealed that female partic- obtaining additional new insights
rounds of focus group interviews ipants accounted for 13%. In terms of (Krueger, 1988). Our initial assessment

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 61

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 62
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
of the data from the first and second
rounds of interview discussions
revealed stable and similar response
trends and patterns to the respective
questions. Hence, the potential value of
conducting more than two rounds was
considered too marginal for this study.
Indeed, the diversity of participants
(from different organizations) in both
interview rounds provided checks and
balances that allowed for an assess-
ment of relatively consistent cultural
habits that are frequently mentioned
and discussed.
To encourage open and free discus-
sions on issues of concern, the inter-
views and discussions were conducted
in the country’s official language. Upon
the consent and willingness of the par-
ticipants, the entire interview was both
audio- and videotaped. Sixteen experts
(eight experts in each round) from eight
organizations participated in both
rounds of the interview program,
whereas others were unable to attend
because of prior commitments. After
full transcriptions of the interviews
were prepared, they were sent to the
participants for feedback on the content
of the transcription before translation.
This helped to review and validate that
the viewpoints and ideas reflected by
participants, along with the sugges-
tions forwarded during the interview,
were those of the experts and not of the
researchers. Moreover, to avoid
researcher bias, the transcripts were
translated into English by an independ-
ent professional translator.
Interview Protocol
The interview protocol consisted of
semistructured questions designed to
provide a step-by-step, in-depth inter-
view process. In order to isolate key
problems to be addressed later, the
experts were asked the following ques-
tions in order. As a preamble, the first
three peripheral questions asked the
experts to define project success, its cri-
teria/parameters, and the contribution
of project teams to project success; this
was done to understand how the
62 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
experts define project success and its
indicators based on their own project
experience and at the same time to
understand the value organizations
attach to people in the successful deliv-
ery of projects. The experts were then
asked whether or not they believed a
relationship existed between the cul-
tural patterns of project teams and
project success, and if so, to indicate
the strength of this relationship. As
questions aimed to probe and explore
deep-rooted behavioral problems
underlying project activities in greater
depth, the rest of the questioning was
specifically related to the influence of
cultural habits on: (1) team relationship,
(2) team learning, and (3) team working.
In conclusion, the questions also took
into account the influence of sociode-
mographic factors and the suggestions
offered to improve the problems.
A review of project management
and the cultural management literature
served to help us design and develop
our own interview protocol (Appendix
C). The protocol enabled us to develop a
clear structure and ensure that all rele-
vant issues were covered during the
interview. To minimize possible moder-
ator effects on the participants, the
objective of the interview and the bene-
fits thereof were thoroughly reflected on
before the start of the interview. After
having established rapport, all efforts
were made to elicit active participation
and candor during the discussion.
Analysis Approach
Several approaches exist in the analysis
of qualitative data (Bryman, 2004;
Saunders, Lewis, & Thornhill, 2007). In
the analyses of transcripts from the
interview, the concepts of selective
coding and core category were used to
systematically link subordinate and
subcategories (Punch, 2005; Strauss &
Corbin, 1998). The first author used
open coding in sorting data into rele-
vant categories and selective coding in
assigning segments of text from codes
to core categories. The second author
reviewed the process to overcome the
possibility of random assignment and
discrepancies were resolved, and this
enabled us to identify emergent pat-
terns and relationships, as well as a set
of generalizations about the nature of
the influence (Bryman, 2004; Saunders
et al., 2007).
The data analysis included the tran-
scripts (nearly 70 pages of text derived
from eight hours of audio and video
records), in addition to notes taken
during discussions from the two
rounds of interviews. All of the impor-
tant viewpoints raised and discussed by
the experts were indicated in the forms
of quotations in this study report; how-
ever, the report did not include each
participant’s mood (e.g., their tone of
voice, nonverbal cues, and so forth). To
protect the respondents’ anonymity
and make the results more accessible to
the reader, all synopses and reports by
the focus group experts were also
assigned fictitious names (Experts 1
through 16). NVivo qualitative data
analysis software (version 8) was used
to structure and code the interviews’
results.
Discussion Results
For brevity, only the key findings of the
case study are presented, whereas more
detailed results can be obtained from
the authors; moreover, due to space
constraints, our discussion of the
results is confined to the cultural habits
influencing project team behavior.
The experts agreed that their
behavioral conditions reflected their
cultural patterns, which also form the
basis of everyday life; hence, culture is
presented as the fabric of individual
behaviors, including shaping the proj-
ect team members’ behavior: “Our cul-
ture suppresses openness, accepts
male dominance, selfishness and
reluctance to work and their effects are
reflected at the office” (Expert 8). The
experts felt that the influence of family
background, schooling, and an attach-
ment to the broader community play
key roles in shaping their behavior. The
cultural forces of these institutions are
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 63
interrelated and determine the behav-
iors of project team members—in
other words, what they see, perceive,
experience, and do in project team set-
tings.
Even our behaviors within the team
depend on our exposure in life and
the experiences we have already
developed. Family is the main
source of our behavioral learning
and plays a greater role in shaping
our behaviors. Then, there is school,
where the discipline in the school
we followed had its own role in
shaping our behaviors. Our ties to
the community also play a role.
(Expert 6)
The potential impact of cultural
patterns on project success has been
underlined, for example, within cul-
tures that work together (the Debo,
Jigae, Ikub, and Idir cultures in
Ethiopia). It was noted that people of
the Debo and Jigae cultures help to fin-
ish a task rather quickly by working and
cooperating with each other, whereas
people of the Ikub culture play a major
role in providing solutions to financial
problems. People of the Idir culture
also help others in times of grief and
distress. These practices are clear man-
ifestations of values, such as collec-
tivism, cooperation, harmony, and
sound interpersonal relationships.
Moreover, it was indicated that
Ethiopians are not only very hospitable
people but they also maintain a culture
that encourages arbitration and medi-
ating conflicts through traditional ways
before taking legal action, a practice
that should be further encouraged.
These views are compatible with
Ethiopia’s very high collective orienta-
tion, as mentioned in Hofstede’s (1983)
findings pertaining to East Africa and
those of House et al. (2004), which per-
tain to SSA. These are the positive
aspects in a cultural context that char-
acterize project teams, and carrying
these positive cultural values over to
project work will contribute to project
success.
Yet, there are concerns among the
experts as to why these types of cultural
values are not shared and practiced in
order to successfully attain project
objectives within a project team setting.
As one expert stated:
In our culture, the kind of coopera-
tion we show in projects, marriage,
or grieving is highly different. In
social gatherings, such as marriage
and funerals, the people actively
cooperate and participate. They
share both their sorrow and happi-
ness. However, when it comes to
projects, we do not do the same. We
challenge ourselves to participate
and cooperate even after we have
joined the project, being attracted to
its vision. (Expert 2)
The experts acknowledged the diffi-
culties in breaking cultural barriers in
order to bring people into a collective
state of mind that would enhance proj-
ect success.
Table 1 illustrates the cultural habits
that have negative influences on project
team behavior.
Team Relationship Cultural Habits
The experts acknowledge that rela-
tionship-related cultural habits have
the greatest influence on project team
behavior. A common cause is the preva-
lence of networking, which includes
hidden motives and/or agendas among
members, tends to quickly dissipate the
initial boost of energy and enthusiasm
within a project team, and hinders
attaining the project’s objectives.
Instilling positive team spirit to encour-
age the team in the right direction
toward the goal becomes a daunting
task as team members with the same
private interests and objectives create a
united front.
When asked how networking influ-
ences teamwork behavior, the experts
pointed out a tendency to look for loop-
holes and rely on individuals in order to
advance their own interest and focus
more on personal gain and advantages.
In this sense, personal contacts and
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
networking seem to be both the source
and the driving force behind an indi-
vidual’s confidence. The following
statements reflect this growing phe-
nomenon:
In our culture, instead of working,
we look for individuals on whom we
can depend on as a ladder to ascend
to a higher position or power.
(Expert 16)
Running to satisfy private interest
by relying on individuals who have
the power and using them as a
shield is now becoming a familiar
practice. (Expert 1)
Another key issue emerging from
this study is the prevalence of skepti-
cism and cynicism regarding project
objectives as well as distrust among
members. The experts agree that the
nature of communication, seemingly
fueled by skepticism and cynicism, has
a powerful suppressive influence on the
communicative and cooperative
behaviors of members in project team
settings. They attribute this partly to
the cultural patterns within the family/
society, which are largely reflected in
the individual attitudes and behaviors
in a project team setting. The experts
believe that an individual raised in a
closed family environment is more
reluctant to speak out, despite having a
good idea in mind and despite a will-
ingness to cooperate in support of a
mutual interest. These individuals tend
to lack self-confidence and do not have
the tenacity to bargain or persuade oth-
ers, neither in a work environment nor
outside the office. For example, one
respondent explained that:
I do not dare to speak, even in occa-
sions when I expect others will
speak too much. This is probably
because I come from a society that
encourages silence. Unless I believe
the issue was not raised by anybody
else or it should not be missed, I
think about speaking but remain
silent. Even after speaking out as
much as I can, I cannot express
63
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 64

Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa

PAPERS

Question Areas Cultural Habits Project Team Behaviors (Specific Manifestations)

Team Relationship Networking • Relying on others for personal advantage or benefits
• Setting one’s confidence in terms of personal contacts and networks
• Having hidden group motives/agenda
Skepticism/Cynicism • Being skeptical/cynical of what is being communicated
• Lack of positive thinking/feeling toward others
• Problems with personal courtesy in communication
Team Learning Rigidness • Tendency to magnify one’s own ideas
• Diehard attitude (not likely to be won)
• Lack of willingness to learn from others and learn from mistakes
• Indifference toward others
Self-centeredness • Problems of valuing other’s ideas and learning together
• Withholding information rather than sharing
• Problems of showing courtesy and respect toward other ideas
• Feeling of indispensability
• Focusing on individual achievement
Defensiveness • Fear of the unknown (fear of losing a job or position)
• Fear of objection to ideas and being challenged
• Feelings of jealousy to better ideas (fear of being outshined)
• A “know-it-all” attitude
• Not wanting to appear uninformed
• Doubting the ideas of others
Team Working Externalization • Gossiping/backstabbing and limited face-to-face debating or discussing problems
• Blaming others for problems that are team problems/scapegoating
• Reluctance to accept facts and face the truth
• Complaining and magnifying problems
Opportunism • Putting self-interest before the project’s objectives
• Using projects for self-presentation and selling
Conformism • Behaving in a more rule- and procedure-driven way
• Waiting for work orders or instructions
Superficiality • Having no plan and failing to make decisions that include risks
• Not willing to clearly speak one’s mind and state a position (pretension)
• Inability to openly challenge problems and ideas (passiveness)
Mediocrity • Inefficient use of time and lack of a positive attitude toward work
• Trying to benefit from the work of others
• Enforcing lower performance norms by assigning degrading nicknames to
performing individuals
Risk Aversion • Indecisiveness (hesitation regarding actions and decisions)
• Shifting responsibility and accountability
• Limited initiative, effort, and commitment
Sociodemographic • Endurance problem
Factors • Stability problem
• Commitment problem
Table 1: Cultural habits influencing project team behavior.

64 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 65
myself as sufficiently as I want. This
often surprises me. (Expert 15)
Emphasis is also placed on the
courtesy of communication (manner of
presentation) in project team settings.
A man may speak furiously in a big
tone. His ideas could be good, yet
the way he expressed them may
demoralize the team as a whole or
offend team members. Our way of
presentation is also very important.
(Expert 9)
Successful communication depends
on how well the message comes across;
however, the manner of presentation,
coupled with a pessimistic view of what
has been communicated, can lead to
widespread skepticism, cynicism, and
intimidation within a project team set-
ting and could ultimately affect project
success.
The importance of open and trans-
parent communication is a key factor in
creating a sense of belonging and
mutual understanding, as well as
acquiring commitment and support
from all members to ensure the
project’s sustainability. The following
statements made by the experts
demonstrate the importance of effec-
tive communication:
To move the team in one direction,
there are lots of steps to be crossed
. . . and such a move needs to be
transparent both internally and
externally. (Expert 14)
If the project team members have a
common understanding about the
project, then we can say they are a
step ahead in their goals. (Expert 5)
If there is no good communication,
good participation, and transparen-
cy, then the project will be a total
failure. (Expert 8)
If studies and their decisions were
made behind closed doors . . . it will
have an impact on the perception of
the employee—the one who executes
the reform . . . Therefore, there has to
be communication in every stage of
any project, and the communication
has to be from the top down and
between peers. (Expert 4)
According to the experts, skepticism
and cynicism occur when project team
members believe that information has
not only been withheld but also when it
has been shared only with members
from a particular interest group. They
agree that a lack of openness during dis-
cussions regarding the project’s vision
and objectives naturally has the greatest
impact in terms of the differences in
expectations during the project’s execu-
tion or at the project’s conclusion. An
expert notes that “if the team has a com-
mon vision, assisted by communication,
speaking the same language through
participation, communicating the
progress of the project to stakeholders,
and believing in the project, then these
are successes” (Expert 1). Information
sharing and continual communication
efforts made on an ongoing basis give
project team members a sense of project
ownership and control over the project’s
content. Moreover, another way to
reduce similar problems is to build trust-
ing relationships. It is therefore neces-
sary to improve both the prevalence of
networking and address the skeptical
and cynical relationships dominating
project team settings, which significant-
ly influence project team behavior in
Ethiopia.
Team Learning Cultural Habits
The experts also observed a strong
influence from learning-related cultural
habits. The main problems associated
with team learning seem to be rigidity,
self-centeredness, and defensiveness.
For example, the experts indicated the
prevalence of a dominant view in
the magnification of one’s own idea,
which deters the emergence of con-
structive ideas and suggestions in proj-
ect team settings.
. . . showing courtesy, and respecting
and capitalizing on better ideas
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
from others are still challenging . . . .
If I give an opinion after concluding
my idea is the best, it means that I
am not ready to accept another, per-
haps better idea. (Expert 2)
According to the experts, diehard
attitudes and a lack of willingness to
learn from others, or learn from mis-
takes, not only take up too much proj-
ect time, but they also steer the team in
an unnecessary direction. If a handful
of members dominate the discussions
or remain inflexible in their positions,
balancing member contributions in
terms of views and ideas to support the
decision-making process is hardly
attainable.
If I am rigid or stiff, then the project
time could be wasted through
unnecessary debate and discussion.
Thus, it has influence on the com-
pletion of the project by its dead-
line. (Expert 2)
The discussions by the experts
revealed that self-centered learning
behavior tends to dominate project
environments within the investigated
organizations. Everyone seemed to
agree that the most challenging aspect
of team learning is the willingness of
each member to learn from each other
and value each other’s ideas, as well as
transfer knowledge within the project
system. An expert commented that “we
need to know that team members who
have the knowledge are willing to trans-
fer it and that the other members who
lack the knowledge are willing to
receive or learn it” (Expert 9). If the
effort that members exert to learn from
each other is weak, the possibility of
synergistic solutions will remain at
stake. The viewpoint that team learning
needs to be perceived as a natural
process in project team settings was
emphasized.
There is a common belief that the
practice of acquiring and sharing
knowledge is limited, because mem-
bers tend to retain information rather
than share it and they tend to focus on
65
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 66
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
individual success and achievement
rather than collective achievement. The
discussions revealed that there are
many indications to show how preva-
lent these problems are:
. . . unwillingness of certain individ-
uals to share their knowledge and
information in work, which has a
common benefit except in situa-
tions assumed to have special bene-
fit for them . . . Unless I am paid or
promised something, I might not
speak my mind. (Expert 4)
There are people who are selfish
and do not like learning naturally.
There are people who like to appear
as the only knowledgeable person. If
such attitudes are not broken, then
they will definitely contribute to
team failure. (Expert 15)
Moreover, the issue of failure to
respect and be courteous to others was
emphasized. Experts noted the absence
of positive thinking toward members,
particularly if their ideas affect the
undertaking of project activities and
the morale of others. Furthermore,
learning from each other is considered a
waste of time, because there is a feeling
of indispensability, particularly by proj-
ect managers/team leaders who want to
handle project activities by themselves.
Despite the opportunity for team
learning, the practice is even more con-
strained by the defensive stance taken
by members.
As we often cast doubt on how
someone has better knowledge than
us and we often only promote our
own idea, we are not ready to learn
from others. (Expert 3)
An expert points out how a sense of
insecurity can affect the learning
process between the teacher—a team
member with the knowledge—and the
learner—a team member with no
knowledge.
The teacher thinks that sharing
knowledge and experience threatens
66 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
or puts his or her position in jeop-
ardy or of being taken over by others.
If he or she is economically inse-
cure, he or she tends to hide his or
her skill and knowledge. On the
other hand, the learner does not
want to appear uninformed and
pretends as if he or she knows every-
thing. (Expert 5)
Moreover, the team learning process
can be demarcated by position, age, or
gender. The experts acknowledge that
those in higher positions are uncomfort-
able learning from colleagues in lower
positions, because there are those in
lower positions who believe knowledge
can only come from those in higher
positions or it may seem as though eld-
ers are knowledgeable in everything.
The two sides of the problem seem to
create the tendency to support and pur-
sue unconstructive ideas simply by tak-
ing sides against superiors, elders, or
even colleagues, because challenging
bosses and elders is discouraged.
There is a problem of openly and
positively forwarding ideas and
opinions with regard to individuals
and positions. (Expert 1)
All these behavioral manifestations
have a negative influence on the
progress and realization of project
objectives, because they not only
undermine the strong motivation need-
ed for constantly learning within proj-
ect team settings, but they also inhibit
knowledge and prevent experience-
sharing practices.
A better understanding of these cul-
tural habits (such as rigidness/stiffness,
self-centeredness, and defensiveness),
which affect the entire team’s learning
process within the project team is crucial
to further developing and implement-
ing new project ideas and solutions,
thereby improving overall project per-
formance. In this sense, the following
statements by experts better indicate
the significance of team learning.
People need to share their knowl-
edge in order to speak a common
language. If there is sharing of
knowledge, they can easily achieve
project goals without friction and
sacrifice. (Expert 11)
When we work in a team, we plan,
identify problems and seek solu-
tions together. We together develop
a sense of ownership, which fosters
commitment and initiation. The
learning process will pave the way
for the team to continuously
improve and remain successful.
(Expert 7)
When the understanding in team
work is developed, one team mem-
ber identifies the strong and weak
sides of the other team member and
then is able to appreciate the
stronger side. This will help to iden-
tify the best quality of the team to
share and carry out the project
activity based on their full willing-
ness and capacity. (Expert 4)
The challenges on record need to
improve in order to pave the road for
enhanced team learning in project
team settings, and it is imperative
that team members share and use their
knowledge, skills, and expertise in the
name of attaining the project’s objec-
tives.
Team Working Cultural Habits
The experts also acknowledge the influ-
ence of teamwork-related cultural
habits on the integration of individual
thoughts and actions to achieve project
objectives.
One of the greatest challenges is
externalizing project problems. The
experts underscore the fact that people
prefer to externalize project problems
and disseminate these challenges in the
form of gossip, which has its own
impact on the progress and realization
of projects. The experts who spoke
about these excessive influences indi-
cated that:
We grew up in closed society and
often like to back-stab when we can
comment and speak openly.
Sometimes this develops gradually
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 67
on its own or through a member
into internal politics and influences
project team success. It may start as
a simple matter, but one of the team
members slowly turns it into a form
of communal gossip, spreading
throughout the organization and
then into the community that
expects the results of the project. We
have lots of cultural and behavioral
influences. (Expert 15)
Externalizing, blaming, and com-
plaining are our common negative
attitudes. There is purity of thinking.
(Expert 1)
In other words, if things go wrong,
people are inclined to blame or point
fingers at other individuals and blame
them for team problems, try to save
face, or lessen the facts for fear of
upsetting a third party. There is a prob-
lem with hiding facts and not facing the
truth.
We say team spirit exists when the
project’s aim is owned without
pushing work on others or pointing
fingers at others . . . . When people
regard and respect each other, they
interrelate, and this in turn makes
the team successful. (Expert 11)
Moreover, there is a very clear sense
by the experts that the domination of
self-interest (opportunism) is emerging
as a key barrier to project success.
We respond quickly if it is a private
matter. But if it is beyond that, we
look for somebody else to do it. In
offices, if the duty is assigned to an
individual capacity, we commit our-
selves and finish it soon. If it is
assigned to a team, we show reluc-
tance to work on it. (Expert 8)
This even includes projects that are
used as an opportunity for self-presenta-
tion and selling. These behavioral pat-
terns keep members from moving quickly
and committing and dedicating them-
selves solely to the project’s vision. The
experts unanimously agree that when
self-interest is dominant or overshadows
the project’s objective, it is extremely
challenging to achieve a high level of
team integration and commitment.
The other problem involves superfi-
ciality in cases in which members sim-
ply pretend something is their position
or responsibility when in fact it is not.
The problem of unwillingness to clearly
speak one’s mind or state one’s position
is underscored.
There is a problem in taking one’s
own position or sticking to the deci-
sion that our conscience may oblige
us is a reliable one. There is a prob-
lem of going with the wind or simply
following others by retreating from a
former position and siding with the
other. (Expert 1)
Superficiality is becoming the norm
in Ethiopia, which may also hold true in
other countries in SSA, because it
seems that open and sober-minded
people are often labeled or attacked in
one way or another. The following
statements by the experts better reflect
the reality of this situation:
In our culture, openness has its
price. It may cause many losses. An
open person often has no accept-
ance. For this and other reasons,
pretension is now becoming a famil-
iar practice. There is no honest and
heartfelt relationship. (Expert 6)
In a society that is overwhelmed by
excessive passiveness, openness
could be difficult. If there is no
openness, then we may lose even
our contributions completely.
(Expert 11)
Moreover, because most people fail
to make plans and decide against tak-
ing risks, projects will fail to meet their
goals. Such behavior is partly the mani-
festation of risk aversion and partly due
to uncertainty avoidance.
Given the risky nature of projects
that require timely decisions and
swift action . . . if ideas are shared
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
and no one makes the final decision,
then that is dangerous. (Expert 9)
Experts expressed how the tenden-
cy to risk aversion disproportionately
affects team spirit and the success of
projects.
Moreover, the practice of working
under specific work instructions or by
order (conformism) was reported to be
high: “If there is no order to work, it will
be considered as if there is no work”
(Expert 4). The experts silently agreed
that people behave in a more rule- and
procedure-driven way due to lack of
interest in work and lack of self-
confidence, with the intention of benefit-
ting from the work of others (mediocrity),
or even to avoid risks, which, in turn,
increases project control and the coor-
dination of effort and time. This also
includes enforcing lower performance
norms by undermining or assigning
discouraging nicknames to more com-
mitted and high-performing individu-
als. There is a mutual feeling that
determination and persistence by
members in sacrificing to achieve the
project’s objectives and goals are not
balanced.
In conclusion, the efforts to
improve these cultural habits have
been profound if the goal is for project
teams to stay on course with regard to
the project, exhibit practical commit-
ment to the project’s objectives, and
share responsibility and accountability
in regard to results.
Sociodemographic Factors
Finally, a discussion ensued after ask-
ing the experts to share their views on
how sociodemographic factors (e.g.,
gender, age, education, salary, marital
status, family size, and occupational
status) influence project success. The
objective is to discover if and how these
factors influence project success.
The participants agreed that these
factors both positively and negatively
affect project success; however, their
influences varied, depending on a pro-
ject’s type and nature, and the time
required to complete the project. If the
67
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 68
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
nature of the project is considered
time-intensive, there will be age impli-
cations. For example, if the project
requires the physical demands of sit-
ting and working for longer periods of
time, these imply a direct correlation to
age. If the project is considered too
complex, there will be implications
regarding experience, qualifications,
training, expertise, and team composi-
tion. Marital status can also impact the
project. Single individuals are more
likely to commit their time and focus
more intently on the project, whereas
those who are married may have to
divide their time and attention between
the project and family commitments,
resulting in an inability to commit to
and focus on the project. A common
belief is that younger people are more
energetic and passionate; however,
young people and single individuals
also tend to be less stable. If older indi-
viduals are parts of the team, they can
share life experiences, but this does not
necessarily mean they know every-
thing. If the team size increases, a
diversity of project ideas is enhanced,
but the larger the team size, the less
team members listen to what the others
are saying. Thus, there should be a way
to balance these factors in order to cre-
ate a positive environment in which
team members can work productively.
Conclusion
Research focusing on the cultural and
behavioral factors within the body of
project management literature has
made progress in recent years, and the
field is ripe for further research and
development. Perhaps discovering just
how cultural patterns, particularly cul-
tural habits found in a project team
environment, might influence project
team behavior could provide a unique
insight into the cultural and behavioral
dimensions of project management.
This empirical study, apart from the
perceived cultural values that are com-
monly known and pronounced in the
body of literature, reveals a deep-rooted
underlying cause embedded in cultural
68 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
habits and is among the many principal
factors influencing project team behav-
ior in Ethiopia. The findings focus on the
growing influence of cultural habits as
displayed in project team behavior, which
we believe require special attention in the
project management literature, particu-
larly within project environments in SSA.
The experts themselves recognize many
problems with regard to project team
behavior, which may be explained in ref-
erence to some of the above-mentioned
cultural habits identified in this study.
The common patterns of responses and
understanding provided by the experts’
insight suggest that cultural habits relat-
ed to team relationship, team learning,
and team working have the most influ-
ence on project team behavior, and this
has a significant and direct effect on
project success.
Considerable emphasis is placed on
team relationship cultural habits (net-
working, skepticism/cynicism), team
learning cultural habits (rigidness, self-
centeredness, and defensiveness), and
team working cultural habits (external-
ization, opportunism, conformism,
superficiality, mediocrity, and risk aver-
sion). Moreover, the influence of
sociodemographic factors (e.g., prob-
lems of stability, endurance, and com-
mitment) was noted. They acknowledge
that these problems are predominantly
rooted in societal traditions, such as
family, school, and community. These
findings are also broadly consistent
with observations in the literature
(Hodgetts et al., 2006; Hofstede, 1983;
House et al., 2004; Seriki, 2007).
Figure 2 provides insight into the
cultural habits that must improve and
be overcome if project teams in particu-
lar, and projects in general, are to be
successful. Societal cultures have an
influence on the cultural habits found
within project teams, which, in turn,
have a direct impact on project team
behaviors that affect project success.
The sociodemographic makeup of a
project team directly influences project
success and indirectly influences and
shapes team members’ behaviors. For
example, age, education, gender, salary,
years of service, and occupational status
influence cultural habits, and these are
reflected in project team behavior.
Moreover, organizational culture is
extremely important in mediating the
influence of societal culture on project
team behaviors. For example, studies
indicate the existence of an interface
between organizational culture and
societal culture, and the mediating role
of organizational culture in facilitating
or hindering project success (Seriki,
2007). Naturally, organizations are
embedded in a particular national cul-
ture, although this does not necessarily
mean that they share the same organi-
zational culture. Yet, many scholars
argue that the cultural patterns of orga-
nizational members at work are likely to
reflect the values and behaviors held
more broadly in society in general
(Hodgetts et al., 2006; Hofstede, 2001;
House et al., 2004; Seriki, 2007); this is
because they are embedded within larg-
er social systems that influence how
they behave and perform. For example,
Hofstede (2001) indicates the degree of
difficulty organizations face in order to
change national cultural values that
people bring to the workplace. Although
organizational culture continues to
have some degree of importance, the
influences of one’s national culture are
stronger (Shahin & Wright, 2004). Thus,
the society in which individuals are
born constitutes the primary social
environment in which people learn and
draw from the dominant cultural pat-
terns that represent their collective
identity (Hodgetts et al., 2006).
Indeed, there are numerous cultural
habits that impact project team behav-
ior other than those explored in this
study; moreover, the factors that influence
project success are also not limited to the
issues that exist with regard to the team’s
cultural habits. The project context,
including external factors beyond the
team’s control and other factors such as
technology, tasks, and products associ-
ated with the project team’s function-
ing, can also affect project success.
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 69

Societal Culture Project Context

(Family, School, and Community)

Organizational Culture
(Mediating Role) Project Success
- Increased productivity
Project Team - Enhanced creativity
Areas of Project Team Behavior and problem solving
Influence Cultural Habits (Specific - Employee satisfaction
and commitment
Manifestations)
- Quality services and
customer satisfaction
Team - Networking -…
Relationship - Cynicism/Skepticism

- Self-centeredness Sociodemographic
Team - Rigidness
Factors
- Defensiveness
Learning - Age
- Gender
- Education
- Externalization - Salary
- Opportunism - Occupational status
Team - Conformism -…
Working - Superficiality
- Mediocrity
- Risk Aversion

Figure 2: Cultural habits influencing project team behavior and project success.

Hence, as indicated from the outset,
the validity of inference and the conclu-
sion derived from this study are affect-
ed by a number of other factors that
have not been considered here. Despite
this fact, in an environment that largely
lacks awareness about the influence of
cultural habits, this study provides insight
(input) into the project team’s interven-
tional strategy to address and improve
problems. In this regard, the following
section highlights the study’s implica-
tions, limitations, and directions for
future research.
Implications, Limitations,
and Future Research
Implications
This study reveals the need for change
regarding the traditional assumptions
underpinning people management
within a project environment in SSA.
The findings strongly suggest that con-
ducting BPR or implementing the latest
technological advances (IT projects) in
SSA will often fall short of expectations,
unless the cultural patterns (especially
the cultural habits influencing project
team behavior) of the people participat-
ing in such projects are changed. The
cultural patterns embedded within proj-
ect teams have a determining impact on
an organization’s drive for process,
structural, and technological changes.
Therefore, organizational improve-
ment and change projects are likely to
generate the expected benefits through
changing the values, attitudes, and
behaviors of the people involved in the
implementation of these changes. The
project’s social and cultural setting is a
key factor in understanding and
addressing many of the problems, as
well as contemplating the kinds of val-
ues and beliefs that could improve the
project team’s cultural habits are very
important. Also, encouraging these val-
ues and beliefs among team members
is important in order to enhance proj-
ect success. Organizations can only
attain final results from BPR and IT
projects when these convictions are
instilled in the minds of people. Hence,
influencing the team’s thoughts, per-
ceptions, and directions is possible
when empirical studies such as this one
offer both practitioners and project
managers critical thought on the nature
of the cultural habits influencing project
team behavior.

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 69

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 70
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
To improve the implementation of
BPR and IT projects, we suggest that the
design and plan of project teams need
to address three important interrelated
questions, which are perceived to be
weak or void within the organizations
under consideration: (1) What are the
project team management activities
that need to be integrated into the
major stages of BPR and IT projects?
(2) What forms of project team inter-
vention strategies are the most useful to
support the change management effort
over the life cycles of these projects?
and (3) What specific set of project
team values, attitudes, and behaviors
are important to bring about change
development over the courses of these
projects?
Sustaining project team efforts
beyond the project start-up phase
becomes challenging when there is
weak take-off in BPR and IT projects.
The important part of project team
management starts with adequate proj-
ect team planning (Thamhain, 2004b).
The planning phase needs to outline
important team management activities
and determine how the project team
should be functioning as BPR and IT
projects evolve through different
stages. McDonough III (2000), for
example, emphasizes the consideration
of appropriate project goals, human
resource assignment, empowerment,
and the creation of a productive cli-
mate as the stage setters in enhancing
the likelihood of project team success.
Proper project team planning could
assist organizations in the implementa-
tion of BPR and IT projects in four
areas: (1) clarification of project team
goals, functions, and boundaries;
(2) project team recruitment and selec-
tion; (3) development and alignment of
a compensation and reward system for
team efforts; and (4) identification,
design, and delivery of programs
geared to members’ training and devel-
opment needs.
Aligned with project team manage-
ment activities, different project team
intervention strategies are also needed
70 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
to identify the specific actions to build
and develop project teams while imple-
menting these projects. Jackson and
Klobas (2008, p. 329) note, “Projects are
collective, purposeful activities based
upon the development of common
understandings and interpretations of
means and ends.” Pre-involvement,
shaping, and changing pre-implemen-
tation attitudes lay the foundation for
communicating and reducing anxieties
and concerns over organizational
change projects and reducing commu-
nication barriers and misconceptions,
conflicting views, and expectations that
may shift the attention and efforts of
project teams in the successful delivery
of these projects (Bishop, 1999; Clarke,
1999; Thamhain, 2004b). Through sen-
sitization or awareness creation pro-
grams, an intervention strategy at the
start-up phase of a project needs to aim
at enhancing mutual understanding
among members about the rationale of
the project and how it works, benefits,
or impacts their work (Clarke, 1999;
McDonough III, 2000; Thamhain,
2004b). Exerting more efforts in involv-
ing members, embracing their ideas
and concerns, and getting them on
board in the start-up phase are recom-
mended to ensure the successful imple-
mentation of BPR and IT projects. As
projects progress, practitioners and
project managers must recognize the
negative impacts of cultural habits on
project team behavior and the impor-
tance of building a climate of mutual
trust and respect to ultimately improve
the overall performance of these proj-
ects. Mutual trust is needed for quick
and coordinated project team actions,
when value differences are widely
prevalent due to functional diversity,
time allocation heterogeneity, and dif-
ferences in reporting structures
(Webber, 2002). Intervention strategies
may draw on team-building, support,
knowledge management, motivational,
or decision-making solutions to
improve the individual and collective
contributions of members. For exam-
ple, a team-building strategy may target
role clarification, goal setting and
planning, problem solving and deci-
sion making, communication, inter-
personal relations, project-specific
norms and rules to provide members
with a sense of self-competence and
confidence, greater clarity on project
work requirements and demands,
accountability and responsibility for
results, mutual performance, and a
supportive attitude in the implemen-
tation of these projects. The advance-
ment in performance, thoughts, and
behavior within project teams is also
likely when team leadership provides
the adequate platform and support,
whereby members can build a com-
mon understanding of, trust in, and
respect for each other; exhibit high
levels of acceptance, involvement, and
commitment; and establish conflict
resolution strategies (Cleland, 1995;
Thamhain, 2004a).
The relevant values, attitudes, and
behaviors that support and encourage
acceptance and effective implementa-
tion of these projects need to be identi-
fied, nurtured, and developed. Hence,
the choice and design of any intervention
strategy should take into account the
specific set of values, attitudes, and
behaviors that are important to bring-
ing about change development over the
courses of these projects. Kloppenborg
and Petrick (1999), for example, identi-
fy important team characteristics that
are needed to perform and facilitate the
completion of projects as they progress
through their life cycles. They indicate
that the completion of the first stage
(project initiation) demands intellectu-
al virtues to set goals and priorities;
identify final deliverables, potential
roadblocks; and risks; and determine
overall feasibility of the project, where-
as the second (project planning) needs
both social virtues and emotional
virtues to detail activities, cost sched-
ules, and human resource requirements.
Moreover, project implementation
requires moral virtues to make deci-
sions, solve problems, take actions, and
get the project done, whereas the last
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 71
(project evaluation) demands political
virtues to objectively assess perform-
ance and fairly recognize contributions
to project objectives. As project teams
have increasingly accumulated and
developed distinct sets of values, atti-
tudes, and behaviors that have sup-
ported their success, they positively
influence organizations’ abilities to
implement lasting organizational im-
provement and change programs
through BPR and IT projects.
By integrating project team manage-
ment activities, project team interven-
tion strategies, and the desired project
team values, attitudes, and behaviors
into the stages of BPR and IT projects,
practitioners and project managers can
avoid or mitigate the negative impacts
of cultural habits, thereby improving
the performance of these projects.
Limitations
As with any other qualitative research,
there are limitations unique to this
research approach. One of the basic
problems is an inability to fully capture
the intended meanings of the words and
statements made by the experts as they
were being colloquially expressed during
the interview sessions. Moreover, as the
interviews were held in the participants’
native languages, the words and state-
ments expressed by the experts may
have taken on different meanings during
translation, although there a great effort
was made to maintain the originality of
the experts’ views. Similarly, although the
researcher had the opportunity to
observe the tones and interactions (non-
verbal communications) that occurred
between the experts during the inter-
views, it was also difficult to encapsulate
the experts’ motives—there was the
potential to overlook important facts
(Krueger, 1988) or there might have been
a response bias (Yin, 2003). The
researcher had little control over the inter-
actions between the participants that
one would find in an experimental
design (Yin, 2003). Furthermore, this
study was based on findings by experts in
one particular country, and the sample
size is considered small even if the proce-
dures employed were consistent with
theoretical considerations. In spite of this
fact, the organizations considered are
involved in many projects, with a large
number of employees providing a broad
range of services. Moreover, the diversity
of participants (project managers, coor-
dinators/team leaders, and experts/
members) and organizations (small and
large, private and public) not only
ensures the adequacy as well as the rep-
resentativeness of the sample, but also
contributes to a broad application of the
findings. Thus, the sample could be
understood as representative for
Ethiopia.
The limitations impose the conclu-
sions that may be drawn from this case
study; hence, the findings depicted in
the study should be considered as
indicative rather than definitive and as a
foundation for further research. It
should also be mentioned that this study
does not come to the conclusion or give
the impression that Ethiopia necessarily
shares the same cultural context with
countries in SSA that influence project
team behavior. There may be differences
in the degree to which cultural habits
influence project team behavior in SSA.
Yet, as facts from the literature and this
case study suggest, the identified cultur-
al habits are typical of those seen in a
variety of organizations in SSA; thus, the
analyses and conclusions from this case
study could be reasonably applied in a
broad sense to projects in organizations
throughout SSA.
Future Research
Further research will bring about new
insight and changes that can improve
project team behavior to make organiza-
tional change projects real and durable.
An interesting area for future research
would be religion. It has a greater role in
shaping the Ethiopian culture in particu-
lar and SSA culture in general. It is part of
everyday life, and people’s values are
partly conditioned by their religion;
hence, its influence on project team
behavior is worth investigating. Another
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
area to consider is the contextual reali-
ties of BPR and IT projects that influ-
ence project team behavior. Examples
include organizational policies, proce-
dures, practices, and routines that
define daily life in organizations.
The interaction between traditional
and modern values (traditionalism and
modernism) in SSA society, and the rel-
ative advantages and disadvantages of
both in modern project team settings,
are also other important areas. For
example, studies can provide empirical
evidence on how the traditional drivers
of African values, such as group solidar-
ity, cooperation, harmony, and sound
interpersonal relationships (which are
presumably dominant in the normal
course of social interaction in SSA but
less practiced or limited in project team
settings) are further capitalized to
foment and sustain the momentum of
project success in SSA. Project success
depends on the type of the project and
the cultural context within which it is
conducted, among others. Hence, a
study of how traditional SSA values
compete with modern project manage-
ment practices encompassing more
sectors and countries could help to
uncover an array of attitudinal and
behavioral problems influencing the
success of organizational change proj-
ects. In general, an in-depth under-
standing of the design and plan of BPR
and IT projects is worthy of future
research in light of the cultural contexts
of SSA. Hence, more empirical studies
are needed to dissect and understand
the cultural patterns, especially the cul-
tural habits, influencing project team
behavior to develop project manage-
ment models or approaches suitable
and applicable within the project envi-
ronments of Ethiopia, in particular, and
throughout SSA in general. ■
References
Adigun, I. O. (1995). Effects of domes-
tic multiculturalism on job attitudes in
Nigeria: A research note. International
Journal of Human Resource
Management, 6(4), 910–929.
71
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 72
Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa
PAPERS
Aycan, Z. (2002). Leadership and team-
work in developing countries:
Challenges and opportunities. In W. J.
Lonner, D. L. Dinnel, S. A. Hayes, &
D. N. Sattler (Eds.), Online readings in
psychology and culture (Unit 15,
Chapter 8). Bellingham, WA: Center for
Cross-Cultural Research, Western
Washington University. Retrieved from
http://www.wwu.edu/culture
/aycan.htm
Baccarini, D. (1999). The logical frame-
work method for defining project suc-
cess. Project Management Journal,
30(4), 25–32.
Baiden, B. K., Price, A. D. F., & Dainty,
A. R. J. (2006). The extent of team inte-
gration within construction projects.
International Journal of Project
Management, 24(1), 13–23.
Belassi, W., & Tukel, O. (1996). A new
framework for determining critical
success/failure factors in projects.
International Journal of Project
Management, 14(3), 5–18.
Belout, A. (1998). Effects of HRM on
project effectiveness and success:
Towards a new conceptual framework.
International Journal of Project
Management, 16(1), 21–26.
Belout, A., & Gauvreau, C. (2004).
Factors influencing project success:
The impact of human resources
management. International Journal
of Project Management, 22(1),
1–11.
Beugre, C. D., & Offodile, O. F. (2001).
Managing for organizational effective-
ness in Sub-Sahara Africa: A cultural fit
model. International Journal of
Human Resource Management, 12(4),
535–550.
Bishop, S. K. (1999). Cross-functional
project teams in functionally aligned
organizations. Project Management
Journal, 30(3), 6–12.
Blunt, P., & Jones, M. L. (1997).
Exploring the limits of western leader-
ship theory in East Asia and Africa.
Personnel Review, 26(1/2), 6–23.
Bredillet, C., Yatim, F., & Ruiz, P. (2010).
Project management deployment: The
72 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
role of cultural factors. International
Journal of Project Management, 28(2),
183–193.
Bryman, A. (2004). Social research
methods (2nd ed.). New York: Oxford
University Press.
Business process re-engineering—An
imperative component for rapid and
sustainable development. (2009, July
3). Ethiopian Herald, Vol. LXV, No. 254,
p.8.
Camprieu, D., Renaud, D. J., & Feixue,
Y. (2007). Cultural differences in proj-
ect risk perception: An empirical com-
parison of China and Canada.
International Journal of Project
Management, 25(7), 683–693.
Clarke, A. (1999). A practical use of key
success factors to improve the effec-
tiveness of project management.
International Journal of Project
Management, 17(3), 139–145.
Cleland, D. I. (1995). Leadership and
the project management body of
knowledge. International Journal of
Project Management, 13(2), 83–88.
Cooke–Davies, T. (2002). The “real”
success factors on projects.
International Journal of Project
Management, 20(3), 185–190.
Ethiopian Economic Association.
(2007, March). Report on the Ethiopian
economy, unemployment challenges
and prospects. Vol. V 2005/06.
Fortune, J., & White, D. (2006).
Framing of project critical success fac-
tors by systems model. International
Journal of Project Management, 24(1),
53–65.
Gray, R. J. (2001). Organizational cli-
mate and project success.
International Journal of Project
Management, 19(2), 103–109.
Hammer, M., & Champy, J. (1995).
Reengineering the corporation: A mani-
festo for business revolution. Helsinki,
Finland: Werner Söderström Oy.
Heeks, R. (2002). Information systems
and developing countries: Failure,
success, and local improvisations. The
Information Society, 18(2), 101–112.
Henrie, M., & Sousa-Poza, A. (2005).
Project management: A cultural liter-
ary review. Project Management
Journal, 36(2), 5–14.
Hodgetts, R. M., Luthans, F., & Doh, J.
P. (2006). International management:
Culture, strategy and behavior (6th ed.).
New York: McGraw-Hill.
Hoegl, M., & Gemuenden, H. G. (2001).
Teamwork quality and the success of
innovative projects: A theoretical
concept and empirical evidence.
Organizational Science, 12(4), 435–449.
Hofstede, G. H. (1983). The cultural
relativity of organizational practices
and theories. Journal of International
Business Studies, 14(2), 75–89.
Hofstede, G. H. (2001). Culture’s conse-
quences: Comparing values, behaviors,
institutions, and organizations across
nations (2nd ed.). San Francisco, CA:
Sage.
House, R. J., Hanges, P. J., Javidan, M.,
Dorfman, P. W., & Gupta, V. (2004).
Culture, leadership, and organizations:
The GLOBE study of 62 societies. San
Francisco, CA: Sage Publications.
Jackson, P., & Klobas, J. (2008).
Building knowledge in projects: A
practical application of social con-
structivism to information system
development. International Journal of
Project Management, 26(4), 329–337.
Javidan, M., & House, R. J. (2001).
Cultural acumen for the global manag-
er: Lessons from project GLOBE.
Organizational Dynamics, 29(4),
289–305.
Jones, M. (1988). Managerial thinking:
An African perspective. Journal of
Management Studies, 25(5), 481–505.
Jugdev, K., & Muller, R. (2005). A retro-
spective look at our evolving under-
standing of project success. Project
Management Journal, 36(4), 19–31.
Kendra, K., & Taplin, L. (2004). Project
success: A cultural framework. Project
Management Journal, 34(1), 30–45.
Kliem, L. R., & Ludin, S. I. (1992). The
people side of project management.
London: Gower.
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 73
Kloppenborg, T. J., & Petrick, J. A.
(1999). Leadership in project life cycle
and team character development.
Project Management Journal, 30(2),
8–13.
Krueger, R. A. (1988). Focus groups: A
practical guide for applied research.
San Francisco, CA: Sage.
Levine, D. N. (2000). Greater Ethiopia:
The evolution of a multiethnic society.
Chicago: University of Chicago Press.
Leybourne, S. A. (2007). The changing
bias of project management research:
A consideration of the literatures and
an application of extant theory. Project
Management Journal, 38(1), 61–73.
McDonough, E. F., III. (2000).
Investigation of factors contributing to
the success of cross-functional teams.
Journal of Product Innovation
Management, 71(2), 221–235.
Mengesha, G. H., & Common, R.
(2006). Civil service reform in Ethiopia:
Success in two ministries. Research
Memorandum, 59, 1–26.
Ministry of Finance and Economic
Development (MoFED). (2006,
September). A plan for accelerated and
sustained development to end poverty
(PASDEP) (2005/06–2009/10), Volume I.
Addis Ababa, Ethiopia: Author.
Muriithi, N., & Crawford, L. (2003).
Approaches to project management in
Africa: Implications for international
development projects. International
Journal of Project Management, 21(5),
309–319.
National Bank of Ethiopia. (2006/2007).
Quarterly bulletin, fourth quarter.
Addis Ababa, Ethiopia: Author.
Neal, R. A. (1995). Project definitions:
The soft-systems approach.
International Journal of Project
Management, 13(1), 5–9.
Nzelibe, L. O. (1986). The evolution of
African management thought.
International Studies of Management
and Organization, 16(2), 6–16.
Patton, M. Q. (1990). Qualitative evalu-
ative and research methods (2nd ed.).
San Francisco, CA: Sage.
Punch, K. F. (2005). Introduction to
social research: Quantitative and quali-
tative approaches (2nd ed.). London:
Sage.
Rees, D. (2004). Managing culture. In
J. R. Turner & S. J. Simister (Eds.),
Project management: A comprehensive
handbook (pp. 793–815). New Delhi:
Gower.
Rousseau, V., Aube, C., & Savoie, A.
(2006). Teamwork behaviors: A review
and an integration of frameworks.
Small Group Research, 37(5), 540–570.
Saunders, M., Lewis, P., & Thornhill, A.
(2007). Research methods for business
students (4th ed.). Upper Saddle River,
NJ: Pearson Education.
Schwartz, S. H. (2006). Les valeurs de
base de la personne: Théorie, mesures
et applications [Basic human values:
Theory, measurement, and applica-
tions]. Revue française de sociologie, 42,
249–288.
Seriki, H. T. (2007). Teamwork for inno-
vation in Sub-Saharan Africa
(Unpublished dissertation). Deutscher
Unvirsitäts-verlag/GWV Fachverlage
GmbH, Wiesbaden, Germany.
Shahin, A. I., & Wright, P. L. (2004).
Leadership in the context of culture:
An Egyptian perspective. Leadership &
Organization Development Journal,
25(6), 499–511.
Shenhar, A. J., Tishler, A., Dvir, D.,
Lipovetsky, S., & Lechler, A. (2002).
Refining the search for project success
factors: A multivariate, typological
approach. R&D Management, 32(2),
111–124.
Shore, B., & Cross, B. J. (2005).
Exploring the role of national culture
in the management of large scale inter-
national science projects. International
Journal of Project Management, 23(1),
55-64.
Smyth, H., & Morris, P. W. G. (2007).
An epistemological evaluation of
research into projects and their man-
agement: Methodological issues.
International Journal of Project
Management, 25(4), 423–436.
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Soderlund, J. (2004). Building theories
of project management: Past research,
questions for the future. International
Journal of Project Management, 22(3),
183–191.
Strauss, A. L., & Corbin, J. (1998).
Basics of qualitative research:
Techniques and procedures for develop-
ing grounded theory (2nd ed.). San
Francisco, CA: Sage.
Thamhain, H. J. (2004a). Linkages of
project performance to team perform-
ance: Lessons for team leadership.
International Journal of Project
Management, 22(7), 533–544.
Thamhain, H. J. (2004b). Team leader-
ship effectiveness in technology-based
project environments. Journal of
Project Management, 35(4), 35–46.
Webber, S. S. (2002). Leadership and
trust facilitating cross-functional team
success. Journal of Management
Development, 21(3), 201–214.
Yin, R. K. (2003). Case study research:
Design and methods (3rd ed.).
Thousand Oaks, CA: Sage.
Zewikael, O., Shimizu, K., &
Globerson, S. (2005). Cultural differ-
ences in project management capabil-
ities: A field study. International
Journal of Project Management, 23(6),
454–462.
Fanta Tesgera Jetu has completed his doctoral
study at Johannes Kepler University in Linz,
Austria, under the North-South Dialogue
Scholarship Program. He holds a bachelor’s
degree in management and public administration
and an MBA from Addis Ababa University in
Ethiopia. His research interests are in the areas of
project team management, human and working
relations in projects, the cultural and behavioral
dimensions of project management, and organi-
zational change management and development.
René Riedl is an associate professor in the
Department of Business Informatics-
Information Engineering at Johannes Kepler
University. Moreover, he serves on the executive
board of the Institute of Human Resources and
73
57-77PMJ0808.qxd 8/8/11 12:21 PM Page 74

Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa

PAPERS

Organizational Development in Management at
Johannes Kepler University. In spring 2007, he
was a guest researcher in the Harvard Business
School at Harvard University, Boston,
Massachusetts, USA. Before his academic
engagement, he worked as a project manager
for an Austrian outsourcing provider. He has writ-
ten several books. Additionally, his research has
been published in Behavior Research Methods,
Business and Information Systems Engineering,
Communications of the AIS, MIS Quarterly,
NeuroPsychoEconomics, Proceedings of the
ICIS, and WIRTSCHAFTSINFORMATIK, among oth-
ers. In addition, he serves as an ad-hoc reviewer
for journals like Management Science, MIS
Quarterly, Journal of the AIS, The DATA BASE for
Advances in Information Systems, and Business
and Information Systems Engineering.
Friedrich Roithmayr is a professor of business
informatics at Johannes Kepler University. He
has been serving as vice rector for communi-
cation and foreign affairs at the same univer-
sity since 2007. His consulting experiences
and research interests are in the areas of
knowledge management, education, audit and
control of information systems, information
engineering, e-business, and business
process management. He is the author of sev-
eral information systems books and his
research has been published in a number of
peer-review journals and proceedings.

74 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 75

Appendix A: Participants’ Demographic Information

Number Percentage
Gender
Female 2 13
Male 14 87
Total 16 100
Age
31–35 4 25
36–40 4 25
41–45 4 25
46–51 4 25
Total 16 100
Occupational Status
Directors and Managers 9 56
Heads and Coordinators 4 25
Officers/Experts 3 19
Total 16 100
Educational Achievement
Bachelor Degree 6 37
Postgraduate Degree 10 63
Total 16 100
Educational Background
Computer Science/Information Technology 5 31
Business/Economics 8 50
Statistics/Mathematics 2 13
Engineering 1 6
Total 16 100
Tenure (Years of Service)
10–15 Years 4 25
More Than 15 Years 12 75
Total 16 100
Position in Currently Assigned Projects
Project Manager/Process Owner 8 50
Project Coordinator/Team Leader 4 25
Project Team Member 4 25
Total 16 100
Average Number of Project Team Assignments
Within the Current Organization
2–4 7 45
5–7 7 45
More Than 7 2 10
Total 16 100

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 75

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 76

Cultural Patterns Influencing Project Team Behavior in Sub-Saharan Africa

PAPERS

Appendix B: Background Information on Sample Organizations

BPR and IT
Total Project Annual Projects’
Staff Working Capital Turnover Budgets
on BPR and (in Millions— (in Millions— (in Millions—
Subsectors Total Staff IT Projects US $) US $) US $)
Banking 14,812 219 821.18 483.56 50.50
1. Commercial Bank of Ethiopia 8,033 56 474.18 309.32 24.28
2. Development Bank of Ethiopia 939 33 198.79 40.90 8.05
3. Construction and Business Bank 900 38 18.21 22.90 12.49
4. Awash International Bank S.C 1,329 17 38.41 44.03 2.66
5. United Bank S.C 1,963 24 34.35 29.04 1.15
6. Nib International Bank S.C 1,202 27 43.40 32.89 1.30
7. Cooperative Bank of Oromia S.C. 446 24 13.84 4.48 0.57
Utility 29,548 635 3,023.49 1,725.00 183.59
1. Ethiopian Telecommunications Corporation 12,260 371 572.43 586.07 117.19
2. Ethiopian Electric Power Corporation 12,688 144 2,144.03 181.51 8.92
3. Ethiopian Air Lines 4,600 120 307.03 957.42 57.48
Total 44,360 854 3,844.67 2,208.56 234.09
Note. The figures were based on a company report and information as of June 30, 2008. The exchange rate applied was Birr 9.6081/US $ as of June 30, 2008.

76 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

57-77PMJ0808.qxd 8/8/11 12:21 PM Page 77

Appendix C: Focus Group Interview Protocol

Date Two rounds (August 27 and 28, 2009, respectively)

Place Video Conference Room, College of Telecommunications & Information Technology, Ethiopian
Telecommunications Corporation, Addis Ababa, Ethiopia
Interview/Discussion Time Four hours (8:30 A.M. to 12:30 P.M.)
Expected Number of Participants 10–15
Interview/Discussion Questions 10 semistructured questions
1. How do you define and explain project success in relation to your project experience and knowledge?
2. What do you think are the special indicators/parameters of project success?
3. How do you understand project teams and their contributions to the successful realization of projects (like BPR and IT projects) in
your respective organizations?
4. Do you think there is a relationship between project success and the cultural patterns of project teams? If so, how do you see and
evaluate the strength of this relationship?
5. How do you think cultural habits influence your relationship—collective belonging and shared purpose as a project team?
• What are their manifestations in a project team setting?
• How do they impact your relationship and project success?
6. How do you think cultural habits influence project team learning—your ability to acquire, share, and apply knowledge as a project
team?
• What are their manifestations in a project team setting?
• How do they impact project team learning and project success?
7. How do you think cultural habits influence project team working—successful integration of your thoughts and actions to achieve
project objectives?
• What are their manifestations in a project team setting?
• How do they impact project teamwork and project success?
8. How do you think sociodemographic factors (e.g., gender, age, education, salary, marital status, family size, occupational status,
years of service, training, team number and composition, and so forth) influence project success?
9. Based on the discussion and in relation to the above questions, what do you think should be done to improve the project team’s
behavior to enhance project success?
10. Any comment or suggestions related to the questions or interview/discussion?

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 77

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 78
PAPERS
Exploring Risk Dimensions in the
Indian Software Industry
Arpita Sharma, Professional Development Department, Jaypee Institute of Information
Technology, Noida, India
Santoshi Sengupta, Professional Development Department, Jaypee Institute of Information
Technology, Noida, India
Aayushi Gupta, Professional Development Department, Jaypee Institute of Information
Technology, Noida, India
ABSTRACT ■
The success of software projects is quite sub-
jective in nature and is fettered by many risks,
the perception of which varies from individual to
individual and largely depends on the demo-
graphic characteristics of the executives and
even the characteristics of the project. This
study aims to identify and gauge the software
risk dimensions and analyze the differences of
perception among executives toward software
risks. The contributions of this study untangle
the issues underlying risks in the software
industry and associates these issues with the
perception of the “human” factor present in
the industry.
KEYWORDS: software projects; risks;
demographics
Project Management Journal, Vol. 42, No. 5, 78–91
© 2011 by the Project Management Institute
Published online in Wiley Online Library
(wileyonlinelibrary.com). DOI: 10.1002/pmj.20258
78 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
INTRODUCTION ■
he Indian software industry is characterized by the diversity of the
T projects it engenders. From size to complexity and from scope to crit-
icality, the attributes of a software project can be varied. Some projects
are big, encompassing numerous resources with complex integration
and interorganizational developmental processes, whereas others are rela-
tively small and simple. Some have a worldwide reach, whereas some may
affect only a small division or client group (Keil, Tiwana, & Bush, 2002). Some
software projects are developed “in-house,” whereas others may be out-
sourced. Regardless of the size, complexity, criticality, or scope, the success
of software projects is not guaranteed. There is strong evidence to suggest an
unacceptably high rate of software project failure in the software industry. A
large number of projects are abandoned before completion or are complet-
ed after comprising on quality, cost, budget, or all three (Standish Group,
2009).
There has been a wide range of studies conducted, which have addressed
issues pertaining to software projects: their success, their failure, the effi-
ciency of the team handling them, and the organizational climate in which
they are developed. Various studies (Anudhe & Mathew, 2009; Bannerman,
2008; Boehm, 1989; Costa, Barros, & Travassos, 2007; Dash & Dash, 2010;
Dey, Kinch, & Ogunlana, 2007; Keil, Smith, Pawlowski, & Jin, 2004; Oz &
Sosik, 2000; Ropponen & Lyytinen, 2000) have been conducted in the past to
unveil the reasons for the high rates of delays and failures in the software
industry. Miscommunication of requirements, inaccurate estimations, low
team member morale, lack of client ownership, and lack of top management
support are some of the risk factors that have been mentioned by most of the
researchers, thus emphasizing the technical, managerial, and people
aspects. Nonetheless, it cannot be said with the utmost confidence as to
what extent and magnitude these factors affect the success or failure of the
software project, nor can it be stated how many of these factors genuinely
affect the success or failure of the software project. The reason for this vague-
ness is simple: these factors are merely products of the wide variety of
perceptions of the software practitioners who actually handle these factors
during the software development life cycle. A different hierarchical level will
produce a different perception; a different span of experience will lead to a
different perception; and a different project attribute will create a different
perception. Thus, it is a fact that the perception toward these factors varies
widely in the experience and designation of the software practitioners, as
well as the duration, team size, and value of the project. The question now is:
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 79
How does the perception toward these
factors vary with various groups of the
demographic and project attributes?
This study aims to evaluate the var-
ious risk dimensions across a number
of demographic characteristics of soft-
ware practitioners and also aims to
study the variance in risk dimensions
among the various project characteris-
tics handled by software practitioners.
This study is important because it helps
us understand the perception of the
team vis-à-vis middle management
and top management.
Literature Review
Software Risk Dimensions
Numerous studies have been conducted
on the identification and management
of software risk factors. These studies
date back to 1975, when Brooks cited the
causes of project failure on the basis of
his experience at IBM. Thereafter, many
researchers (Anudhe & Mathew, 2009;
Bannerman, 2008; Boehm, 1989; Costa
et al., 2007; Dash & Dash, 2010; Dey
et al., 2007; Keil et al.; 2004; Oz & Sosik,
2000; Ropponen & Lyytinen, 2000) have
been working incessantly on the identi-
fication and management of software
risks, some of which are discussed in this
study. Dey et al. (2007), through a case
study on The Town and Country
Planning Office (TCPO) in Barbados,
identified the unavailability of key per-
sonnel, employee turnover, and incor-
rect/incomplete requirement as the
risks affecting software development.
The study also developed an integrated
framework for managing risk in soft-
ware development with the involve-
ment of the stakeholders in the TCPO.
Verner, Evanco, and Cerpa (2007) con-
ducted exploratory statistical analyses
on both the software developers and top
management to identify their percep-
tions about the determinants of project
success and used logistical regression to
predict project success. Accordingly, the
developers’ perspectives suggest that
success is more likely to happen if the
project manager is involved in schedule
negotiations; adequate requirements
information is available when the esti- collection and proactive analysis),
mates are made; initial effort estimates staffing (maintaining buffer resources,
are good; staff leave is taken into involving the client in resource recruit-
account; and more staff is not added ment), and changes in the client’s corpo-
late in the project in order to meet an rate structure (transparency and adequate
aggressive schedule. communication) are some of the risk
Zhou, Vasconcelos, and Nunes factors, and their mitigation is men-
(2008) analyzed ten case studies in the tioned in their study.
United Kingdom, the United States, and
Perspectives of Software Professionals
New Zealand to identify critical risk fac-
The concept that different stakeholders
tors (scope creep, unwillingness of the
can perceive software projects in differ-
customer to accept final systems, poor
ent ways has also been well established
project management, etc.) at the pre-
in the literature (Lyytinen, Mathiassen,
implementation and implementation
& Ropponen, 1998). Keil et al. (2002)
stages of the software project.
Bannerman (2008) conducted a study in
have demonstrated that users and proj-
ect managers differ in terms of their
government agencies in Australia to
project risk perceptions, while
investigate the practices of a state gov-
Warkentin, Bekkering, and Moore
ernment when dealing with software
(2007); Warkentin, Bekkering, Johnston,
projects. Analysis of the study uncovered
and Moore (2009); and Stephen, Keil,
ten categories of risk factors—namely,
Mathiassen, Shen, and Tiwana (2007)
project governance, project setup,
have exhaustively studied the percep-
partner engagement, business propri-
tion of risk among various demographic
etorship, project management, change
characteristics of software professionals
management, management of projects,
and have suggested that professionals
recognition of red flags, management of
with more experience in project leader-
risk, and benefit realization. The study
ship are more likely to view projects and
also suggested the various risk manage-
their associated risks more holistically
ment techniques used in these projects.
and assign and resolve risk as if they
Iacovou and Nakatsu (2008) used the
were organizational in nature. Agarwal
Delhi survey method on 57 senior IT
and Rathod (2006), Linberg (1999),
professionals and identified lack of top
Wateridge (1995), Verner et al. (2007),
management commitment, the original
and Verner, Beecham, and Cerpa (2010)
set of requirements miscommunicated,
have explored the success indicators as
language barrier in project communica-
perceived by software professionals.
tions, lack of required technical know-
All of these studies provide great
how by the offshore team, and failure to
insight into the practitioner’s perception
consider all costs as the core risk factors.
about the software risks dimensions;
The study aimed at providing insight
however, a study about the perception
into the risks affecting offshore-
among various demographic character-
outsourced development projects.
istics of software practitioners on these
Anudhe and Mathew (2009), using case-
dimensions is largely anecdotal and
based methodology and structured and
lacking in the Indian context. Further-
semistructured interviews with senior
more, not much research has been
management of various Indian software
done in understanding the dynamics
companies, described various risk fac-
of risk among various project charac-
tors affecting the software projects.
teristics handled by the software practi-
Schedule and budget management
tioners.
(developing a collaborative work culture
with clients), client expectations (edu- Objectives of the Study
cating the client to involve a deep level of Based on the literature review and the
involvement with the customer), gaps identified in it, the objectives of
requirements capture (elaborate data the study are as follows:
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 79
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 80
Exploring Risk Dimensions in the Indian Software Industry
PAPERS
1. To identify and rank the software risk
dimensions affecting software proj-
ects in India.
2. To evaluate the difference of percep-
tion toward risk dimensions on the
basis of the designation and experi-
ence of software professionals.
3. To evaluate the difference of percep-
tion toward risk dimensions on the
basis of project characteristics—
namely, team size, duration, and
total value of the project handled by
Indian software professionals.
Research Methodology
A systematic and coherent approach
was adopted for the research study.
First and foremost, a pilot study was
done on 40 software project managers
working in software companies located
in the National Capital Region (India)
to gauge the risk factors that affected
the success of their last executed proj-
ects. The project managers in the pilot
study were specifically asked to identify
the critical risk factors affecting the
software development life cycle. Based
on the perceptions of the project man-
agers in the pilot study and in-depth
secondary data analysis, an exhaustive
list of 23 risk items affecting the soft-
ware development life cycle was identi-
fied. These items were meticulously
drawn out after thorough interviews
and a comprehensive literature review;
thus, the list is all-inclusive. A question-
naire was prepared using these risk
items and was administered to software
professionals with a minimum of four
years’ experience in handling software
projects in India.
To carry out extensive research, a
survey design was used. Four major IT
hubs in India—namely, NCR (Gurgaon,
Noida, Delhi, Faridabad), Hyderabad,
Bangalore, and Chennai—were select-
ed. From each IT hub, eight companies
were randomly selected, thus bringing
the total to 32 companies. A total of 900
questionnaires were sent out, of which
340 filled-in questionnaires were
returned, with a response rate of 37.7
percent; of these, only 300 were found
80 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
Kaiser-Meyer-Olkin
Number Cronbach’s Measure of
of Items Alpha Sampling Adequacy
Software 23 0.956
risks
Table 1: Reliability and validity of the software risk factors and organizational climate factors.
to be completely filled out and 40 were
discarded. A random sampling tech-
nique was used to gather data from IT
professionals with more than four years
of experience in handling software proj-
ects. The questionnaire was intricately
designed to elicit information about
(1) the personal characteristics of the
respondents (namely, designation and
total experience); (2) project character-
istics handled by the respondents
(namely, team size, duration of the proj-
ect, and total value of the project); and
(3) the risk factors impacting the
success of the last executed project. In
addition to gathering data through the
questionnaires, in-person interviews
were also conducted with the project
managers and senior management to
accentuate the data collected. Statistical
Package for the Social Sciences (SPSS)
version 17.0 was consistently used for
the statistical analyses.
Analysis and Findings
The analysis of the data set obtained
was conducted in several steps. First,
the major software risk dimensions
were identified using principal compo-
nent analysis (PCA). PCA is widely used
to examine the underlying patterns for
a large number of variables and to
determine if the information can be
summarized in a small set of factors or
components for subsequent correlation
or regression. Second, ANOVA-Duncan
post-hoc was conducted to test the
variance in these dimensions among
various demographics and project
characteristics. The reliability of the
survey instrument was also tested.
Bartlett’s Test of
Sphericity
0.916 Approx. 5,309.252
Chi-Square
df 253.00
Sig. 0.000
To test the validity of the instrument,
Cronbach’s alpha and Kaiser-Meyer-
Olkin (KMO) tests were conducted.
Cronbach’s alpha was calculated to
measure the internal consistency and
reliability of the instrument. The results
of the Cronbach’s alpha, Bartlett’s test
of sphericity, and KMO tests are shown
in Table 1.
Personal Profiles of the Respondents
The first section of the instrument
gathered information about the per-
sonal profiles of the respondents,
which included designation and total
experience; each of these background
variables is described in the sections
that follow. It must be noted here that
the open-ended questions were asked
from the respondents regarding the
demographic and project characteris-
tics. Because these data could not be
used in raw form, the data were tabulat-
ed and grouped together according to
the cumulative frequencies in such a
way that each group has almost equal
distribution. Table 2 provides the
demographic characteristics.
Designation
Because the questionnaire was deliber-
ately administered to IT professionals
with more than four years of experience
handling software projects, the respon-
dents were primarily project leads and
higher-level employees. As shown in
Table 2, out of 300 respondents, 141 (47
percent) were primarily project man-
agers, senior managers, and account
managers, who were specified as Level
2, whereas 43 respondents (14 percent)
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 81

finally, the approximate value of the

Characteristics Number Percentage
project in US dollars. These details are
Designation 116 38.70% provided in Table 3.
Level 1
(project leads, technical leads, consultants, Team Size
senior software engineers, lead consultants) The total team size was divided into
three categories. As is clear from Table
Level 2 141 47% 3, 100 projects were handled by a team
(project managers, senior managers, account
size of three to ten members, whereas
managers)
89 projects were handled by a team
Level 3 43 14.30% size of 11 to 20 members; thus, 189 (63
(chief operating officer, head of IT, director, percent) projects handled by the
chief executive officer) respondents had a team of 20 mem-
Total experience (in years) bers or less. On the higher side, only 25
4–9 years 112 37.30% projects (8.4 percent) had a team rang-
10–14 years 123 41% ing from 50 to almost 500. Only one
More than 14 years 65 21.70% project had a total value of US $145
Table 2: Demographic characteristics of the respondents. million, with a team size of 500 team
members.

Duration
As shown in Table 3, it was found that
were from the top management team Thus, as seen from the demograph-
113 projects (37.7 percent) were com-
(chief operating officer, head of IT, ics, the sample was dominated by
pleted in less than one year. After
director, chief executive officer), who project managers and senior project
detailed conversations with several IT
were specified as Level 3. Such a wide managers. Furthermore, an in-depth
professionals, it was found that proj-
scale of distribution was necessary to analysis has been conducted to gauge
ects cannot really be classified as
enable a better analysis and interpreta- the profiles of projects handled by the
short-term, medium-term, or long-
tion of the data. respondents.
term projects because they are organi-
Total Experience Profile of the Last Executed Project zation-specific. For companies with
As shown in Table 2, the respondents Handled by the Respondents thousands of employees, a project with
were classified into three categories, The respondents were asked to provide a one-year duration would be consid-
depending on their total experience. details of the last executed project they ered a short-term project, but for a
The second category (123 respondents handled. The instrument contained company with only 10 employees, the
[41 percent]) was dominated by project questions on the team size of the proj- same project would be considered a
managers and senior project man- ect, total duration of the project, and, long-term project.
agers, with total experience ranging
from 10 to 14 years. A few directors and
vice presidents were also in this cate-
Project Details Number Percentage
gory. In the last category, with more
than 14 years of experience, there were Number of team members in the project
65 (21.7 percent) respondents, mainly 3–10 100 33.30%
from the senior management team. A 11–20 89 29.70%
few senior managers and account More than 20 111 37%
managers fell under this category. The Time taken to complete the project (in months)
main reason for this blend is that the 1–9 months 113 37.70%
software industry is a modern industry, 10–19 months 96 32%
and consists of 25- to 30-year-old indi- More than 20 months 111 37%
viduals who can start their own busi- Total value of the project (in million dollars)
nesses and hire their own employees; 0.02–0.70 102 34%
therefore, it is easier to reach higher 0.71–2.00 89 29.70%
levels at an early age compared with Greater than 2.00 109 36.30%
the traditional industries (e.g., iron and
steel). Table 3: Characteristics of the projects handled by the respondents.

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 81

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 82
Exploring Risk Dimensions in the Indian Software Industry
PAPERS
Value
As shown in Table 3, the projects were
almost evenly distributed among the
three groups, with most of the projects
falling into either the first group of proj-
ect value (up to US $70,000) or the third
group (value above US $2 million).
However, after a detailed analysis, it
was found that most of the projects
outsourced to Indian software compa-
nies ranged between US $1 and 10 mil-
lion, with 151 projects (50.3%) falling
into this category.
Thus, it can be seen from the profile
of the project that the sample is a
homogenous mix of team, time, and
total value of the project. Further study
was done on extracting the risk factors
as rated by these respondents.
Identification of the Risk
Dimensions
As already pointed out, the 23 risk items
used for the study were identified after
an all-encompassing and exhaustive
secondary data analysis and pilot study.
Table 4 describes the 23 risk items used
for the study.
Factor analysis was done to extract
the software risk factors affecting the
success of the projects; principal com-
ponent analysis was the method of
extraction and Varimax was the rotation
method. As per the Kaiser criterion,
only factors with eigenvalues greater
than 1 were retained. Four factors in the
initial solution have eigenvalues greater
than 1; together, they account for
almost 68% of the variability in the orig-
inal variables. The items falling under
each of these factors were then dealt
with quite prudently. The factors
extracted for the study are shown in
Table 5.
SRS Variability Risk
The software requirement specification
(SRS) variability risk is the name given
to the first risk dimension identified
through factor analysis. The items
included in this are shown in Table 5.
All of these items have one commonal-
ity: lack of proper flow of information
leading to requirement variability. The
82 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
problem of requirement variability ini-
tiates at the stage in which the project
manager does not have any prior expe-
rience in handling the similar type of
project. This problem is further height-
ened when the manager fails to under-
stand the client because of regional or
language differences. Together, these
two issues create a ripple effect and
open up the sea of miscommunication
of requirements, gross estimation errors,
conflicting and continuous requirement
changes, and inaccurate require-
ment analysis, thus delaying the
recruitment of the team, which results
in a gross miscalculation of the cost of
the project. This is the initiating stage
of the project, and such issues are
bound to create many problems in the
project, even resulting in cancellation.
The same has been reiterated by Boehm
(1991), Baccarini (1996), King (1994),
Clancy (1995), and Smite (2006).
Besides this, the lack of client owner-
ship and lack of drive to specify require-
ments are major contributors to vague
requirements, and not enough clarifi-
cation is done to solve them in time.
Researchers even state that project
managers fail to make correct estima-
tions in the initial stages of the software
development and sometimes distort
the facts or become too optimistic, thus
creating gross estimation errors (Keil,
Im, & Mahring, 2007; Snow, Keil, &
Wallace, 2007). Thus, it is obvious how
crucial it is to understand the require-
ments correctly for the success of the
project.
Team Composition Risk
As is clear from Table 5, the second fac-
tor has seven items loaded on it, and all
are related to team composition risk.
This factor deals with the risks related
to the team members responsible for
the development and execution of the
project. The major contributors to these
risks are the lack of top management
support and unavailability of a compe-
tent project manager in handling the
team. Any lack of interest exhibited by
top management will result in hiring of
an inexperienced or highly diverse
team. In addition, if top management is
not keen on investing in training or hir-
ing a subject matter expert, there will
be a risk of unavailability of a domain
expert, which will create problems for
the project (Barki & Hartwick, 1989;
Gioia, 1996; Keil et al., 1998; Leitheiser
& Wetherbe, 1986; Nah et al., 2001). In
addition to senior management’s lack
of interest, the project manager is also
responsible for contributing to the
team’s composition risk. The project
manager acts as a liaison between top
management and the team. All issues
related to promotion and performance
appraisals are handled by the project
manager. If the manager is inept at
handling the team issues, there is
bound to be dissatisfaction among
team members, resulting in low morale,
lack of commitment, and, ultimately,
high turnover (Bosco, 2004; Dey et al.,
2007; Faraj & Sambamurthy, 2006;
Standish Group, 2009). This is a very
important risk affecting the project.
Control Processes Risk
As is clear from Table 5, control
processes risk arises when the project
does not have a good and sound config-
uration management. Configuration
management is the detailed recording
and updating of information that
describes the project’s hardware and
software. Such information typically
includes the versions and updates that
have been applied to the software prod-
uct and the locations and network
addresses of hardware devices (Babich,
1986; Bersoff, 1984). If the project does
not have a good and systematic config-
uration plan, it will lead to poor docu-
mentation, because the version will not
be saved, updated, or made available
when needed. The problem will be fur-
ther aggravated due to insufficient test-
ing. When a team member makes
changes in the code and fails to save it
in the central repository, it results in a
loss to the project. The reason for this is
very simple, because when the changes
are not communicated to the tester,
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 83

23 Risk Items Prior Literature and Pilot Study

Working with inexperienced team
Delay in recruitment and resourcing
Less or no experience in similar projects
Insufficient testing
Team diversity
Lack of availability of domain expert
Lack of commitment from the project team
High level of attrition
Estimation errors
Inaccurate requirement analysis
Lack of top management support
Low morale of the team
Miscommunication of requirements
Conflicting and continuous requirement changes
Language and regional differences with client
Lack of client ownership and responsibility
Inadequate measurement tools for reliability
Third-party dependencies
Inability to meet specifications
Inaccurate cost measurement
Poor code and maintenance procedures
Poor documentation
Poor configuration control
Table 4: Risk items used for the study.
Addison and Vallabh (2002); Hoodat and Rashidi (2009); Jiang and Klein
(2001); Keil, Cule, Lyytinen, and Schmidt (1998); Schmidt, Lyytinen, Keil, and
Cule (2001); Reel (1999); Smith et al. (2006); pilot study
Pilot study
Keil et al. (1998); McFarlan (1982); McLeod and Smith (1996); pilot study
Pilot study
Pilot study
Barki and Hartwick (1989); Gioia (1996); Keil et al. (1998); Leitheiser and
Wetherbe (1986); Nah, Lau, and Kuang (2001); pilot study
Pilot study
Arora, Arunachalam, Asundi, and Fernandes (2001); Dey et al. (2007); Reel
(1999); pilot study
Hoodat and Rashidi (2009); Smith et al. (2006); Zhou et al. (2008)
Addison and Vallabh (2002); Field (1997); Keil et al. (1998); Mursu, Soriyan,
and Olufokunbi (1996); Schmidt et al. (2001); pilot study
Barki and Hartwick (1989); Gioia (1996); Keil et al. (1998); Leitheiser and
Wetherbe (1986); Nah et al. (2001)
Pilot study
Iacovou and Nakatsu (2008); Shull, Rus, and Basili (2000); Zhou et al. (2008)
Addison and Vallabh (2002); Boehm (1989); Clancy (1995); Hoodat and Rashidi
(2009); Jones (1993); King (1994)
Anudhe and Mathew (2009); Arora et al. (2001)
Keil et al. (1998); Mursu et al. (1996)
Pan (1999)
Krasner (1998)
Pilot study
Galorath and Evans (2006); Masticola (2007)
Pilot study
de Souza, Anquetil, and de Oliveira (2007); Huang and Trauth (2007); Mattsson
(2008); Oza et al. (2004)
Aharon and Ilana (2010); Sabherwal, Sein, and Marakas (2003)

they will not be able to test the code,
thus resulting in insufficient testing. A
poor and mediocre code with inade-
quate maintenance procedures is also
caused by improper configuration con-
trol. The importance of configuration
control and documentation has also
been mentioned by Huang and Trauth
(2007); Oza, Hall, Rainer, and Grey
(2004); Sabherwal, Sein, and Marakas
(2003); and Jannson (2007).
Dependability Risk
Dependability risk is the name given to
the fourth and last factor; the items
falling under this risk are shown in
Table 5. It is extremely vital for a soft-
ware project to be dependable and reli-
able. Software dependability is defined
as the ability to avoid service failures
that are more frequent and more severe
than acceptable (Avizienis, Laprie,
Randell, & Landwehr, 2004). Dependa-
bility is a broad term, which includes

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 83

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 84

Exploring Risk Dimensions in the Indian Software Industry

PAPERS

Factor reliability is supported by numerous

Factor Item
1 Conflicting and continuous requirement changes
Inaccurate requirement analysis
Miscommunication of requirements
Estimation errors
Less or no experience in similar projects
Inaccurate cost measurement
Language and regional differences with client
Delays in recruitment and resourcing
Lack of client ownership and responsibility
2 Lack of availability of domain expert
Working with inexperienced team
Team diversity
Lack of commitment from the project team
Low morale of the team
High level of attrition
Lack of top management support
3 Poor documentation
Poor code and maintenance procedures
Insufficient testing
Poor configuration control
4 Third-party dependencies
Inability to meet specifications
Inadequate measurement tools for reliability
Table 5: Factor analysis of the risk dimensions.
availability, reliability, safety, integrity,
and maintainability of the software
(Avizienis et al., 2004). Dependability of
the software is therefore very crucial for
the success of a project. For the suc-
cessful completion of a project, all
components (hardware and software)
must be available at the right time and
in the right place. To make things easi-
er, sometimes part of the project is out-
sourced to a third-party vendor, which
can be a great advantage if the right
vendor is chosen. On the other hand, if
Loading Factor Name studies and also conforms to studies by
Sherer (1995), Pan (1999), Krasner (1998),
0.789 SRS and Ropponen and Lyytinen (2000).
Variability
0.786 Risk
Ranking of Software Risk Dimensions
0.765
For determining the most important
0.687 risk affecting the software projects in
0.646 India, means and standard deviations
of the risk dimensions were calculated.
0.635 The respondents were asked to rate the
0.612 effect of each risk based on the success of
their last executed project, on a scale
0.604
of 1 to 5, in which 5 was too much effect
0.533 and 1 was no effect at all. After the fac-
0.761 Team tor analysis, when four factors
Composition emerged, the score of each of the fac-
0.651 tors was computed by taking out the
Risk
0.650 mean of the items falling under each
factor. For example, in order to calcu-
0.628 late the mean of dependability, the
0.613 scores of all the items (i.e., third-party
dependencies, inability to meet specifi-
0.596
cations, and inadequate measurement
0.561 tools for reliability) were first added,
0.733 Control and then the mean was calculated.
Processes Similarly, means and standard devia-
0.716 tions were calculated for all the factors.
Risk
0.556 The ranking of the dimensions, based
on the means and standard deviations,
0.529
is shown in Table 6.
0.803 Dependability It is clear from Table 6 that SRS vari-
Risk ability has the highest mean of 3.06,
0.598
stating that most of the respondents
0.578 consider software requirement specifi-
cation variability as the most important
risk affecting software projects. The
standard deviation for SRS variability
risk is 1.06. The SRS variability risk is
closely followed by dependability risk,
an unreliable vendor is chosen, there with a mean of 2.84; team composition
can be many problems, such as poor risk, with a mean of 2.75; and, finally,
and undependable components, late control processes risk, with a mean of
delivery of critical components, and so 2.52, thus, clearly proving that SRS vari-
forth. This will create a disastrous effect ability risk is the most important risk
on the project and prevent the project affecting Indian software projects,
team from meeting the customer or which is also in line with the findings of
client’s specifications. Furthermore, Sharma, Gupta, and Khilnani (2009).
any component from the third-party Although SRS variability risk is per-
vendor cannot really be tested in ceived to be the most crucial risk, is
isolation and, if proved unreliable, can the perception the same across all the
completely thwart the entire project. groups of designation and experience?
This finding about dependability and This is explored in the following section.

84 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 85

level 3 respondents, thus testifying that

S. No. Factor Name
1 SRS Variability Risk
2 Dependability Risk
3 Team Composition Risk
4 Control Processes Risk
Table 6: Means and standard deviations of the risk factors.
Comparison of Risk Factors
Across Various Personal and
Project Characteristics
The dimensions of software risk so for-
mulated after the factor analysis were
then compared with the various per-
sonal characteristics of the respondents
and the project characteristics handled
by the respondents chosen for the
study. The personal characteristics
included experience and designation,
whereas project characteristics includ-
ed total team size, total time taken to
complete the project, and the total
value of the project. The comparisons
are discussed in the following section.
Designation
Duncan’s Mean Test was applied to
compare the dimensions of software
risk among the three designation
groups of the respondents. All risk
dimensions—namely, SRS variability,
team composition, control processes,
and dependability—showed significant
differences in mean and standard devi-
ation values. Table 7 shows all the values
Mean Standard Deviation
3.06 1.06
2.84 1.13
2.75 1.03
2.52 1.05
of mean and standard deviations of
the dimensions of software risk across the
various designation groups.
As shown in Table 7, the F-value is
highest in cases of SRS variability. This
factor has been ranked the highest by
respondents of level 1 (project leads,
technical leads, consultants, and ana-
lysts), with a mean of 3.58 and a stan-
dard deviation of 0.87, which implies
that level 1 respondents perceive these
risks as having a high effect on the suc-
cess of the project. Dependability and
team composition risks, with means of
3.26 and 3.19, respectively, are again
considered more significant risks by
level 1 respondents than the other two
groups, which are dominated by project
managers (level 2) and directors (level
3). This is due to the lack of sufficient
experience, expertise, and authority in
handling and mitigating risks. Another
interesting fact that emerged out of the
analysis was that the difference was sig-
nificant only with level 1. It should be
noted here that there were no signifi-
cant differences between level 2 and
these two levels have an almost similar
opinion. When compared with level 1
employees, both these groups showed
significant difference. Hence, it can be
said with statistical confidence that
there exists a difference in perception
of these risks among the various desig-
nation groups, which conforms to
many other previous studies. Stephen
et al. (2007) testified that IT project
managers with more experience have
risk perceptions that differ from those
of more junior managers. Warkentin
et al. (2009) has also concluded that,
instead of viewing risks as separate or
discrete categories, managers at higher
levels, owing to their more comprehen-
sive organizational perspectives, are
more likely to consider risks essentially
organizational in nature compared
with their junior managers. The same
has been reiterated by Smith, Eastcroft,
Mahmood, and Rode (2006).
Total Experience
Duncan’s Mean Test was applied to
compare the dimensions of software
risk among three groups and formed on
the basis of total experience. Significant
differences were found in the mean val-
ues of all of the dimensions of risk.
Table 8 shows all the values of mean
and standard deviations of the dimen-
sions of risk across the various experi-
ence groups. As shown, the F-value was
highest in the case of SRS variability,
followed by team composition, control
processes, and dependability. It should

D1 (N ⴝ 116) D2 (N ⴝ 141) D3 (N ⴝ 43)

Risk Factors Mean SD Mean SD Mean SD D1 v/s D2 D1 v/s D3 D2 v/s D3 F-value
SRS Variability 3.58 0.87 2.72 1.04 2.74 1.01 * * – 27.05**
Team Composition 3.19 0.98 2.41 0.94 2.67 1.05 * * – 20.89**
Control Processes 2.97 0.95 2.19 0.98 2.32 1.12 * * – 20.47**
Dependability 3.26 1.18 2.62 1.08 2.42 0.82 * * – 14.60**
Note. D1 ⫽ level 1, D2 ⫽ level 2, D3 ⫽ level 3; Duncan’s Mean Test.
*Significant at 0.05 level. ** Significant at 0.01 level.
Table 7: Comparisons of risk factors among three designation groups.

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 85

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 86
Exploring Risk Dimensions in the Indian Software Industry
PAPERS
E1 (N ⫽ 112)
Risk Factors Mean SD
SRS Variability 3.51 0.93
Team Composition 3.14 0.99
Control Processes 2.91 1.02
Dependability 3.19 1.17
Note. E1 ⫽ up to 9 years, E2 ⫽ 10–14, E3 ⫽ more than 14; Duncan’s Mean Test.
*Significant at 0.05 level. ** Significant at 0.01 level.
Table 8: Comparisons of risk factors among three experience groups.
be noted again that the difference was
significant only between two groups
(i.e., between E1 [up to 9 years of expe-
rience] and E2 [10 to 14 years of experi-
ence] and E1 and E3 [more than 14
years of experience]). E2 and E3 had no
significant differences between them as
far as the perceptions of these four risk
factors were concerned.
All four risks were ranked highest by
E1 respondents, followed by E2, and
then E3. This is not surprising, because
employees with less experience are not
as well versed in managing such issues
or even mitigating them, compared
with veterans in the industry for whom
such issues do not emerge as risks but
as minor challenges that need to be
faced and dealt with. Respondents in
the E2 and E3 categories, therefore,
have similar opinions about such risks,
and so there is no significant difference
between the two. This finding also has
congruence with earlier studies, such
as those by Bourne and Walker (2004),
Smith et al. (2006), and Warkentin et al.
(2009), in which it was concluded that
employees with more experience in
project leadership were more likely to
view projects and their associated risks
more holistically and assign and resolve
risks as if they were organizational in
nature.
Project Characteristics
After comparing the dimensions of
software risks with the various personal
characteristics, the same dimensions
86 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
E2 (N ⫽ 123) E3 (N ⫽ 65)
Mean SD Mean SD E1 v/s E2
2.82 1.07 2.74 1.01 * *
2.52 0.97 2.51 1.02 * *
2.31 0.89 2.23 1.09 * *
2.74 1.09 2.44 0.98 * *
were compared with the various project
characteristics. The project characteristics
included total team size, total time taken
to complete the project, and the total
value of the project. The comparisons
are discussed in the sections that
follow.
Total Team Size
Size refers to the magnitude of the
resources needed to complete the proj-
ect (Thompson, Iacovou, & Smith, 2009).
According to this definition, human
resources engaged in a project make up
the team size. Past research also illus-
trates that the level of resources correlates
with the complexity of the development
(i.e., project-related risks [Baccarini,
1996; Francalanci, 2001; Otto & Magee,
2006]). The team size of the projects is
an important variable and is associated
with the risk dimensions. In this study,
team size has been divided into three
categories—namely, T1 (up to 10 mem-
bers), T2 (11 to 20 members), and T3
(more than 20 members). As shown in
Table 9, Duncan’s Mean Test was con-
ducted to find the significant differ-
ences among the means of these three
categories. The finding shows that none
of the F-values was significant; thus, it
cannot be said with statistical confi-
dence that the risk dimensions vary
with the team size.
Total Duration
The total time taken for the completion
of a project is an important attribute
and is associated with risks, because it
E1 v/s E3 E2 v/s E3 F-value
– 18.17**
– 13.61**
– 13.91**
– 10.42**
is an extensive resource for any project
(Warkentin et al., 2009). The total dura-
tion of a project was categorized under
three heads—namely, TT1 (up to 9
months), TT2 (10 to 19 months), and
TT3 (more than 19 months). The risk
factors were, thus, compared with these
three categories using Duncan’s Mean
Test. Only team composition had sig-
nificant differences among the three
categories, with an F-value of 3.1201
(Table 10). None of the other risks had
any significant differences among the
three groups.
Team composition had a significant
difference only between the TT2 and
TT3 categories (i.e., between projects
with durations of 10 to 19 months and
projects with durations of more than 19
months). Duncan’s Mean Test shows
that there is a difference in mean values
of risk between these two categories.
Projects with longer durations have a
higher mean compared with projects
with shorter durations and this is
because, as the length of time increas-
es, the levels of employee morale and
motivation tend to diminish, because
such projects are generally viewed as
software maintenance projects. With
low or almost no challenge in the type
of work, along with high attrition,
employees lack the commitment nec-
essary for the project, and thus the
team composition emerges as a signifi-
cant risk for projects with longer dura-
tions (Morris, 2004; Schmidt et al.,
2001). Ropponen and Lyytinen (2000)
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 87

T1 (N ⫽ 100) T2 (N ⫽ 89) T3 (N ⫽ 111)

Risk Factors Mean SD Mean SD Mean SD T1 v/s T2 T1 v/s T3 T2 v/s T3 F-value
SRS Variability 2.99 1.11 3.11 1.03 3.08 1.03 – – – 0.3304
Team Composition 2.71 1.13 2.74 1.01 2.79 0.96 – – – 0.1772
Control Processes 2.64 1.13 2.43 0.84 2.47 1.13 – – – 1.1641
Dependability 2.77 1.22 2.89 1.06 2.85 1.10 – – – 0.2921
Note. T1 ⫽ up to 10, T2 ⫽ 11–20, T3 ⫽ more than 20; Duncan’s Mean Test.

Table 9: Comparisons of risk factors among three team size groups.

TT1 (N ⫽ 113) TT2 (N ⫽ 96) TT3 (N ⫽ 111)

Risk Factors Mean SD Mean SD Mean SD TT1 v/s TT2 TT1 v/s TT3 TT2 v/s TT3 F-value
SRS Variability 2.99 1.13 2.99 1.06 3.18 0.98 - - - 1.1998
Team Composition 2.70 1.12 2.56 1.00 2.93 0.94 - - * 3.1201*
Control Processes 2.47 1.10 2.46 1.06 2.60 0.99 - - - 0.5424
Dependability 2.76 1.15 2.75 1.19 2.98 1.07 - - - 1.4238
Note. TT1 ⫽ up to 9 months, TT2 ⫽ 10–19 months, TT3 ⫽ more than 19; Duncan’s Mean Test.
*Significant at 0.05 level.

Table 10: Comparisons of risk factors among three total time groups.

and Warkentin et al. (2009) have point-
ed out that considering the time issue
of a project, the team relationships
have to be managed. As quoted in
Warkentin et al. (2009), “Ultimately you
need effective communication chan-
nels with your vendors and technology
partners. Mutual respect and under-
standing play a large role in the rela-
tionship” (p. 14). This clearly states
that team composition is associated
with the duration of a project and that it
has a larger impact on projects with
longer durations as compared with short-
er ones.
Total Monetary Value
Money is a critical resource that should
be allocated and monitored for the suc-
cess of software and information sys-
tems development projects (Laudise &
Nuara, 2002; Warkentin et al., 2009).
The total dollar value thus becomes an
important attribute for any project, and
it has been selected for comparing the
risk factors. The total dollar values of
projects in which the respondents were
involved are divided into three cate-
gories—namely, V1 (up to US $0.70 mil-
lion), V2 (US $0.71–2.00 million), and V3
(more than $2.00 million). As shown in
Table 11, Duncan’s Mean Test was
applied to see if there were any differ-
ences in the mean values of the risk fac-
tors among the three categories of
dollar values associated with the last
executed projects; it was determined
that none of the differences was signifi-
cant. Thus, it cannot be said with statis-
tical confidence that there exists a
difference in the mean value of the risk
factors across the three categories of
project value.
Thus, it is clear how each of the soft-
ware risk dimensions is viewed by the
various stakeholders within the soft-
ware development organization. Rather
than viewing many software risks as
separate or discrete categories, senior
project managers, with their more
comprehensive organizational per-
spectives, view all risks as essentially
organizational in nature, compared
with the perspectives of the project
leads and technical leads. As far as the
variance in risk dimensions among the
project characteristics is concerned,
the analysis did not show significant
variance among most of the project
characteristics. The team composition
risk, however, did show a significant
variance among the large-size projects,
which is also in line with the findings of
Ropponen and Lyytinen (2000).
Conclusion, Limitations, and
Implications
To conclude, it can be said that based on
the perceptions of software executives—
ranging from middle to top level—
primarily four kinds of risk dimensions
prevail in the Indian software industry

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 87

78-91PMJ0808.qxd 8/8/11 3:06 PM Page 88
Exploring Risk Dimensions in the Indian Software Industry
PAPERS
V1 (N ⫽ 102)
Risk Factors Mean SD
SRS Variability 2.93 1.17
Team Composition 2.66 1.14
Control Processes 2.49 1.09
Dependability 2.72 1.23
Note. V1 ⫽ up to US $0.70 million, V2 ⫽ US $0.71–2.00 million, V3 ⫽ more than US $2.00 million; Duncan’s Mean Test.
Table 11: Comparisons of risk factors among three value groups.
that have an impact on the success of
software projects. These four categories
of software risks do affect the success of
software projects in India. These risk
dimensions are SRS variability risk,
team composition risk, control
processes risk, and dependability risk.
These risks have also been ranked on
the basis of their mean values, and it
has been determined that SRS variabil-
ity risk has the maximum effect on the
success of the software projects. On fur-
ther exploration, it has been found that
there is a difference in the perceptions
of software executives (based on their
personal attributes and project attrib-
utes) toward these risk dimensions,
wherein senior managers perceive
these risks to be more controllable and
having less impact on the success of the
project compared with the perspectives
of junior managers.
The analysis of risk dimensions and
perceptions of individuals regarding
these dimensions is extremely helpful
for both practitioners and academicians
because it helps in disentangling the
perceptions about risk factors at various
levels of demographic characteristics
and also explains the variances among
various groups of project characteristics.
This will enable organizations to accu-
rately gauge the software risk dimen-
sions based on the designation and
experience of employees and the dura-
tion, team size, and value of projects.
This study illuminates the existing the-
oretical foundations regarding software
88 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
V2 (N ⫽ 89) V3 (N ⫽ 109)\
Mean SD Mean SD V1 v/s V2
3.12 1.06 3.13 0.94
2.79 1.01 2.80 0.94
2.54 1.07 2.51 1.00
2.87 1.16 2.93 1.00
risks by exploring the detailed and
ample responses provided by the vari-
ous groups of experienced system
developers and IT professionals.
Although the respondents provided
rich and fertile data for the examination
of software risks, future studies should
increase the sample size to enable
quantitative assessments, in addition to
the qualitative assessments provided
here. In addition to the limitations
posed by the number of study partici-
pants, future research should pursue
the involvement of a greater number of
organizations. Also, only software risks
have been taken into consideration;
these software risks include mainly
technical and team-related issues.
There are many more risks that are
external to projects but have a deep
impact on project success. Such risks
are environmental, cultural, political,
and even organization-specific. This
study was based on a generic pattern of
the software industry in India. More
authentic results can emerge if organi-
zation-specific factors are chosen for
the study. These constraints serve as
limitations to the overall generalization
of this study. Further research should
be undertaken to find out ways to amal-
gamate the perceptions of less experi-
enced, lower-level personnel with those
of senior, upper-level IT professionals,
and to study how these different views are
managed to promote a more unified and
consistent approach to risk manage-
ment. The findings of the exploratory
V1 v/s V3 V2 v/s V3 F-value
- - - 1.1468
- - - 0.6530
- - - 0.0640
- - - 0.9201
studies provide normative guidance to
both junior and senior developers alike.
These findings provide rich and robust
evidence in support of the theories
developed and advanced by other
recent studies; that is, the identification
of risks and intensity of risks as gov-
erned by the demographic and project
characteristics. Now that it has been
determined that magnitude and inten-
sity of the impact of risks on software
projects are largely matters of percep-
tion, further investigations can be con-
ducted to determine the correlation of
demographic characteristics and proj-
ect characteristics with the intensity of
the risk dimensions. ■
References
Addison, T., & Vallabh, S. (2002).
Controlling software project risks: An
empirical study of methods used by
experienced project managers.
Proceedings of SAICSIT 2002, Port
Elizabeth (pp. 128–140).
Agarwal, N., & Rathod, U. (2006).
Defining success for software projects:
An exploratory revelation. Journal of
Systems and Software, 24, 358–370.
Aharon, Y., & Ilana, L. (2010). Changing
students perception regarding software
documentation. MCIS 2010
Proceedings.
Anudhe, M. D., & Mathew, S. K. (2009).
Risks in offshore IT outsourcing: A
service provider perspective. European
Management Journal, 27, 418–428.
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 89
Arora, A., Arunachalam, V.S., Asundi,
J., & Fernandes, R. (2001). The Indian
software services industry. Research
Policy, 30(8), 1267–1287.
Avizienis, A., Laprie, J. C., Randell, B.,
& Landwehr, C. (2004). Basic concepts
and taxonomy of dependable and
secure computing. IEEE Transactions
on Dependable and Secure Computing,
1, 11–33.
Babich, W. (1986). Software configura-
tion management. Reading, MA:
Addison-Wesley.
Baccarini, D. (1996). The concept of
project complexity: A review.
International Journal of Project
Management, 14(4), 201–204.
Bannerman, P. L. (2008). Risk and risk
management in software projects: A
reassessment. Journal of Systems and
Software, 81, 2118–2133.
Barki, H., & Hartwick, J. (1989).
Rethinking the concept of user
involvement. MIS Quarterly, 13(1),
53–63.
Bersoff, E. (1984). Elements of software
configuration management. IEEE
Transactions of Software Engineering,
10, 77–87.
Boehm, B. W. (Ed.). (1989).
Organizational climate and culture.
San Francisco, CA: Jossey-Bass.
Boehm, B. W. (1991). Software risk
management principles and practices.
IEEE Software, 8(1), 32–41.
Bosco, G. (2004). Implicit theories of
good leadership in the open-source
community. Retrieved from http://
opensource.mit.edu/papers
/bosco.pdf
Bourne, L., & Walker, D. H. T. (2004).
Advancing project management in
learning organizations. The Learning
Organization, 11(1), 226–243.
Clancy, T. (1995). Chaos: IT develop-
ment projects. Retrieved from http://
www.standishgroup.com/msie.htm
Costa, H. R., Barros, M. D. O., &
Travassos, G. H. (2007). Evaluating
software project portfolio risks. Journal
of Systems and Software, 80, 16–31.
Dash, R., & Dash, R. (2010). Risk
assessment techniques for software
development. European Journal of
Scientific Research, 42(4), 615–622.
de Souza, S. C., Anquetil, N., & de
Oliveira, K. M. (2007). Which docu-
mentation for software maintenance?
Journal of the Brazilian Computer
Society, 13(2), 31–44.
Dey, P. K., Kinch, J., & Ogunlana, S. O.
(2007). Managing risk in software
development projects: A case study.
Industrial Management and Data
Systems, 107(2), 284–303.
Faraj, S., & Sambamurthy, V. (2006).
Leadership of information systems
development projects. IEEE
Transactions of Engineering
Management, 53(2), 238–249.
Field, T. (1997). When BAD things hap-
pen to GOOD projects. CIO, pp. 55–62.
Francalanci, C. (2001). Predicting the
implementation effort of ERP projects:
Empirical evidence on SAP/R3. Journal
of Information Technology, 16, 33–48.
Galorath, D. D., & Evans, M. W. (2006).
Software sizing estimation and risk
management. Auerbach Publications.
Gioia, J. (1996, November). Twelve rea-
sons why programs fail. PM Network,
pp. 16–20.
Hoodat, H., & Rashidi, H. (2009).
Classification and analysis of risks in
software engineering. World Academy
of Science, Engineering and Technology,
56, 446–452.
Huang, H., & Trauth, E. (2007, April).
Cultural influences and globally dis-
tributed information systems develop-
ment: Experiences from Chinese IT
professionals. Proceedings of ACM SIG-
MIS-CPR Conference, St. Louis,
Missouri, USA, pp. 36–45.
Iacovou, C. L., & Nakatsu, R. (2008). A
risk profile of offshore-outsourced
development projects. Communica-
tions of the ACM, 51(6), 89–94.
Jannson, A. S. (2007, November/
December). Software maintenance and
process improvement by CMMI.
Retrieved from http://www.utn.uu.se
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
/sts/cms/filarea/0801_ann-sofie
_jansson.pdf
Jiang, J., & Klein, G. (2001). Software
project risks and development focus.
Project Management Journal, 32(1)
20–26.
Jones, C. (1993). Assessment and con-
trol of software risks. Englewood Cliffs,
NJ: Prentice-Hall.
Keil, M., Cule, P., Lyytinen, K., &
Schmidt, R. (1998). A framework for
identifying software project risks.
Communications of the ACM, 41(11),
76–83.
Keil, M., Im, G. P., & Mahring, M.
(2007). Reporting bad news on soft-
ware projects: The effects of culturally
constituted views of face-saving.
Information Systems Journal, 1(791),
59–87.
Keil, M., Smith, H. J., Pawlowski, S., &
Jin, L. (2004). Why didn’t somebody tell
me? Climate, information asymmetry
and bad news about troubled projects.
The DATA BASE for Advances in
Information Systems, 35(2), 65–84.
Keil, M., Tiwana, A., & Bush, A. (2002).
Reconciling user and project manager
perceptions of IT project risk: A Delphi
study. Information Systems Journal,
12(2), 103–119.
King, J. (1994). Sketchy plans, politics
stall software development. Computer
World, 29(24), 81.
Krasner, H. (1998). Looking over the
legal edge of unsuccessful software
projects. Cutter IT Journal, 11(3), 11–22.
Laudise, T. M., & Nuara, L. T. (2002).
How to contract for a successful e-
commerce development project:
Beating the odds. The Business Lawyer,
58, 299–316.
Leitheiser, R. L., & Wetherbe, J. C.
(1986). Service support levels: An
organized approach to end-user com-
puting. MIS Quarterly, 10, 336–350.
Linberg, K. R. (1999). Software devel-
oper perceptions about software proj-
ect failure: A case study. Journal of
Systems and Software, 49, 177–192.
89
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 90
Exploring Risk Dimensions in the Indian Software Industry
PAPERS
Lyytinen, K., Mathiassen, L., &
Ropponen, J. (1998). Attention shaping
and software risk: A categorical analy-
sis of four classical risk management
approaches. Information Systems
Research, 9(3), 233–255.
Masticola S. P. (2007). A simple esti-
mate of the cost of software project fail-
ures and the breakeven effectiveness of
project risk management. Presented
at the First International Workshop
on the Economics of Software and
Computation, IEEE.
Mattsson, K. M. (2008, October).
Problems in agile trenches. Proceedings
of the Second ACM-IEEE International
Symposium on Empirical Software
Engineering and Measurement,
Kaiserslautern, Germany.
McFarlan, W. (1982). Portfolio
approach to information systems.
Journal of Systems Management, 33(1),
12–19.
McLeod, G., & Smith, D. (1996).
Managing IT projects. Boyd and Fraser
Publishing.
Morris, P. (2004, November). Metrics
based project governance. Key note
address from the IWSM Software
Measurement Conference, Berlin,
Germany. Retrieved from http://
compaid.com/caiinternet/ezine
/morris-metrics.pdf
Mursu, A., Soriyan, H.A., &
Olufokunbi, K.C., (1996). Toward suc-
cessful ISD in developing countries:
First results from a Nigerian risk study
using the delphi method. Retrieved
from http://iris22.it.jyu.fi/iris22/pub
Nah, F., Lau, J., & Kuang, J. (2001).
Critical factors for successful imple-
mentation of enterprise systems.
Business Process Management Journal,
7(3), 285–296.
Otto, H. K., & Magee, C. L. (2006).
Estimating factors affecting project
task size in product development: An
empirical study. IEEE Transactions on
Engineering Management, 53(1), 86–94.
Oz, E., & Sosik, J. (2000). Why informa-
tion systems projects are abandoned: A
90 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
leadership and communication theory
and exploratory study. Journal of
Computer Information Systems, 41(1),
66–78.
Oza, N., Hall, T., Rainer, A., & Grey, S.
(2004). Critical factors in software out-
sourcing: A pilot study. Proceedings of
the 2004 ACM Workshop on
Interdisciplinary Software Engineering
Research (pp. 67–71).
Pan, J. (1999). Software reliability.
Carnegie Mellon University. Retrieved
from http://www.ece.cmu.edu
/⬃koopman/des_s99/sw_reliability
Reel, J. S. (1999, May–June). Critical
success factors in Software Projects.
IEEE Software, pp. 18–23.
Ropponen, J., & Lyytinen, K. (2000).
Components of software development
risk: What influences it—A project
manager survey. IEEE Transactions on
Software Engineering, 26(2), 98–112.
Sabherwal, R., Sein, M., & Marakas, G.
(2003). Escalating commitment to
information systems projects: Findings
from two simulated experiments.
Information & Management, 40(8),
781–798.
Schmidt, R., Lyytinen, K., Keil, M., &
Cule, P. (2001). Identifying software
project risks: An international Delphi
study. Journal of Management
Information Systems, 17(4), 5–36.
Sharma, A., Gupta, A., & Khilnani, D.
(2009). Identification and correlation
of software project risks for excelling in
IT industry. FOCUS—The International
Journal of Management Digest, 5(1&2),
42–50.
Sherer, H. (1995). The three dimensions
of software risk: Technical, organisa-
tional, and environmental. Presented
at the 28th Annual Hawaii
International Conference on System
Sciences.
Shull, F., Rus, I., & Basili, V. (2000). How
perspective-based reading can
improve requirements inspections.
Computer, 33(7), 73–79.
Smite, D. (2006). Requirements man-
agement in distributed projects.
Journal of Universal Knowledge
Management, 1(2), 69–76.
Smith, D., Eastcroft, M., Mahmood, N.,
& Rode, H. (2006). Risk factors affect-
ing software projects in South Africa.
South African Journal of Business
Management, 37(2), 55–65.
Snow, A. P., Keil, M., & Wallace, L.
(2007). The effects of optimistic and
pessimistic biasing on software project
status reporting. Information &
Management, 44(2), 130–141.
Standish Group. (2009). CHAOS sum-
mary. Boston, MA: Author.
Stephen, D., Keil, M., Mathiassen, M.,
Shen, Y., & Tiwana, A. (2007).
Attention-shaping tools, expertise, and
perceived control in IT project risk
assessment. Decision Support Systems,
43(1), 269–283.
Thompson, R., Iacovou, C., & Smith, H.
J. (2009). Biased project status reports:
A survey of IS professionals.
Proceedings of the 17th European
Conference on Information Systems.
Verner, J. M., Beecham, S., & Cerpa, N.
(2010). Stakeholder dissonance:
Disagreements on project outcome
and its impact on team motivation
across three countries. Proceedings of
the 2010 Special Interest Group on
Management Information Systems’s
48th Annual Conference on Computer
Personnel Research (pp. 25–33).
Verner, J. M., Evanco, W. M., & Cerpa, N.
(2007). State of the practice: An
exploratory analysis of schedule esti-
mation and software project success
prediction. Information and Software
Technology, 49(2), 181–193.
Warkentin, M., Bekkering, E.,
Johnston, A. C., & Moore, R. S. (2009).
Analysis of systems development proj-
ect risks: An integrative framework.
The DATA BASE for Advances in
Information Systems, 40(2), 8–26.
Warkentin, M., Bekkering, E., &
Moore, J. R. (2007). Risk perspectives
in systems development. Proceedings
of the Americas Conference on
Information Systems (AMCIS 2007).
78-91PMJ0808.qxd 8/8/11 3:06 PM Page 91
Wateridge, J. (1995). IT projects: A
basis for success. International
Journal of Project Management, 13(3),
169–172.
Zhou, L., Vasconcelos, A., & Nunes, M.
(2008). Sorting decision making in
risk management through an evi-
dence-based information systems
project risk checklist. Information
Management and Computer Security,
16(2), 166–186.
Arpita Sharma holds a PhD in management and
is a committed academician and devoted
researcher. She has extensive experience in
teaching undergraduate and postgraduate stu-
dents. She started her career as a faculty mem-
ber in the Professional Development Department
with the Jaypee Institute of Information
Technology (JIIT) in Noida, India, and then also
spent some time with the Jaipuria Institute of
Management in Noida. She has published around
five research papers in international and national
journals of repute. She has presented a number
of papers in various conferences. Her areas of
interest are project management, financial man-
agement, and presentation and communication
skills. She is a highly motivated, innovative, and
results-oriented educator, seeking to combine
academic training in a learning-centric approach
to make a solid contribution to organizational
goals in higher education.
Santoshi Sengupta holds a PhD in management
and has been working with the Jaypee Institute
of Information Technology in Noida, for the past
6 years. She started her career in January 2005
in the faculty of the professional development
department at JIIT. She has to her credit around
10 research publications in international and
national journals of repute and also as chapters
in books. She has presented a number of papers
in international conferences both in India and
abroad. She teaches organization behavior, total
September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
quality management, presentation and commu-
nication skills, English, and group and coopera-
tive processes successfully to B.Tech students.
She endeavors to augment herself as a commit-
ted researcher and proficient teacher to impart
the best to her students. She is a highly moti-
vated, inventive, and results-oriented academi-
cian who seeks to provide academic training
using a learning-centric approach.
Aayushi Gupta, associate professor and head
of the department of professional development,
holds a PhD in management. She has more than
10 years of teaching experience. She has guid-
ed a number of PhD scholars under her and
has nine research publications in international
and national journals of repute and also has
authored chapters in various books. She has
presented a number of papers in international
conferences both in India and abroad. She is a
committed researcher and believes in quality
work.
91
92PMJ0808.qxd 8/8/11 12:27 PM Page 92

Cover to Cover
Kenneth H. Rose, PMP, Book Review Editor

Complexity Theory and Project

Management
by Wanda Curlee and Robert L. Gordon

omplexity” does not have a management that focuses on order, struc-

“C simple definition. Applied

to project management, it
relates to the behaviors and
performance of virtual teams. It does
not necessarily reflect complicated or
ture, and planning.
The book is broken down into five
parts with a total of 22 chapters. Part I
introduces complexity theory and points
to deficiencies in current project man-
large projects. Nor does it imply techni- agement. Part II of the book is about
cal difficulty. Complexity theory is a rel- strategies to apply complexity theory to
atively new science with roots in math make projects more successful. Part III
and sciences. Having slowly moved to presents case studies. Part IV shows how
social sciences and business, it is now to create communities in your organiza-
trying to find its place in project man- tion to support complexity theory. Part V
agement. is a summary with the authors’ insights
Wanda Curlee and Robert L. on the future of complexity theory in
Gordon’s book Complexity Theory and project management. The book offers
Project Management is an ambitious various tools for managing virtual teams.
John Wiley & Sons, 2010,
attempt to explain complexity theory It also provides a number of case studies
ISBN: 9780470545966, hardcover,
and illustrate how it can be applied to and examples of complex projects.
416 pp., $118.75 Member,
managing 21st-century projects that are Practitioners will find many of the check-
$125.00 Nonmember.
characterized by virtual teams. The lists and self-assessments in the book to
authors first introduce complexity theo- be useful. A broad list of references is
ry, which acknowledges that studying a small part of an available at the end of each chapter.
“open system” does not explain the whole. For example, A cogent characterization of complex projects early
examining how a single ant works independently does not in the book would have helped the reader with a better
reveal the dynamics of its colony. Project teams are similar understanding of this complex topic. Programs or pro-
systems. Complexity theory can be applied to understand gram management are never mentioned in the book,
and manage them. The authors also note early in the book leaving the reader to ponder the role of complexity theo-
that complexity theory evolved from chaos theory, a key ry in program management. Under the header “Practical
facet of which is commonly known as the “butterfly Tip,” the authors pepper the book with practical pointers.
effect.” Flapping of wings by a butterfly in one part of the Most of the dispensed advice, however, is ubiquitous in
world may create a drastic change in the weather pattern the literature and too simplistic, lacking depth: “Genuine
in another part. In simple words, all forces are connected. enthusiasm is an effective way to motivate a team,”
When a project is moving forward, it is best to put all the “Teams can make a difference in an organization. No one
forces working in the same direction. is smarter than all of us,” and “Focus on strengths.”
The authors posit complexity theory as a concept and Curlee and Gordon boldly predict that we are in the
a tool to manage project teams at the edge of chaos where nascent phase of the third and newest period of project
creativity occurs. They contend that there are many management driven by complexity theory after the his-
unknowns in complex projects that are better handled by torical (ancient) and modern (since the late 1950s) peri-
a flexible process that promotes openness, coincidence, ods. If they are prescient in this, Complexity Theory and
and serendipity, as opposed to the rigid traditional project Project Management is a key short step in what may be a
long journey ahead.

Project Management Journal, Vol. 42, No. 5, 92

© 2011 by the Project Management Institute
Published online in Wiley Online Library (wileyonlinelibrary.com).
Reviewed by Prasad Kodukula, PhD, PMP, PgMP, President of
DOI: 10.1002/pmj.20264 Kodukula & Associates, Chicago, IL, USA.

92 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj

93PMJ0808.qxd 8/8/11 12:28 PM Page 93

Cover to Cover

The Oxford Handbook of Project Management

edited by Peter W. G. Morris, Jeffrey K. Pinto, and Jonas Söderlund

roject management is occupying the chapters question whether project

P an increasingly central role. Yet

practitioners and researchers often
bemoan the limitations of the
processes, methods, knowledge, and per-
spectives. Indeed, while the successful
management is a distinct domain or even
a profession, and whether it should have a
body of knowledge of its own. Others look
at new models for contracting through
alliances or establishing trust, while oth-
delivery of projects underpins the ers explore issues of strategy, governance,
progress and development of humanity, innovation, uncertainty, escalation, and
very few books cover the theoretical basis knowledge integration.
of the discipline and the relevance of aca- Many of the insights are ripe for further
demic scholarship in this area. The Oxford exploration. For example, Grabher and
Handbook of Project Management Ibert offer the concept of project ecologies,
attempts to fill that void by offering a which encompass the contextual view of a
much-needed glimpse into project man- project including personal, organizational,
agement research and its evolution. and institutional resources as a departure
The introduction positions the book as from the more conventional, temporal, and
Oxford University Press, 2011,
the vanguard of the “third wave” of singular manifestations.
ISBN: 9780199563142, hardcover,
research into project management. The If you are looking for a unifying theory of
550 pp., $142.50 Member,
first wave concentrated on normative tools project management, this research hand-
$150.00 Nonmember.
and techniques. The second wave was con- book is not the right starting place. Different
cerned with new developments such as temporary organiza- perspectives and interpretations introduce the potential for
tions, success factors, and contingency models in an attempt disagreements. While Flyvbjerg explores optimism bias (the
to rethink the discipline. The new wave of analysis and inter- accumulation of underestimated costs and overestimated
pretation, first identified in this work, emphasizes the context benefits), he advocates for the need for good data on the per-
of a project, links to strategy, governance, leadership, trust, formance of past projects. In contrast, Winch and Maytorena
and the view of projects as complex organizations steeped in question the utility of past data in assessing future perform-
uncertainty, ambiguity, and novelty. ance. Research will not provide definitive answers; instead,
The chapters tackle a host of thought-provoking topics the multiplicity of explanations and perspectives opens the
offering fresh ideas and insights. Project management is potential for reflection, dialogue, and sense making.
repositioned as a much broader and more strategic While the book treats readers to glimpses of new
domain, in the process transforming it from being execu- research directions, it fails to capture the full potential of the
tion-oriented to a wider, longer-term concern. Indeed, if forthcoming debates. More contributions would have been
we accept the notion that projects are created rather than welcome, but at 550 pages the book is already a fairly major
found, we can benefit from exploring a much wider canvas. tome. It would have been useful to provide abstracts for each
The research locus can thus advance to address the emerg- chapter to get a feel for the contribution on offer. Minor
ing areas of context, strategic alignment, front-end devel- gripes aside, it is encouraging to see an authoritative survey
opment, and social skills. of research in project management written by leading schol-
Edited books can be difficult to digest, as they offer a ars. The book is an easy and gripping read and is thus des-
mix of styles, approaches, and quality; however, this vol- tined to become an important resource for practitioners and
ume works as a collection of chapters. Together, they will researchers. The inclusion of the title in a prestigious Oxford
convince the reader that project management is con- University book series shows that project management
cerned with a lot more than “simple” execution as projects research is clearly moving to the forefront. This book will
become more significant in most organizations. Some of play a crucial role in propelling the discipline forward.

Project Management Journal, Vol. 42, No. 5, 93
© 2011 by the Project Management Institute
Published online in Wiley Online Library (wileyonlinelibrary.com).
DOI: 10.1002/pmj.20263
Reviewed by Darren Dalcher, PMP, Chair Professor of Software Project
Management at Middlesex University and Director of the National
Centre for Project Management, London, United Kingdom.

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 93

94PMJ0808.qxd 8/8/11 12:29 PM Page 94
Cover to Cover
Delivering Exceptional Project Results: A
Practical Guide to Project Selection, Scoping,
Estimation and Management
by Jamal Moustafaev
amal Moustafaev’s Delivering
J Exceptional Project Results: A Practical
Guide to Project Selection, Scoping,
Estimation and Management con-
tains 19 chapters. In the preface, Moustafaev
provides two ways to organize these chapters.
They may be grouped under three topic cate-
gories (project management, scope defini-
tion, and portfolio management) or in terms
of which audience would be most interested
in which chapters. Audiences include junior
project managers, senior project managers,
and senior business or functional managers.
The book is eminently readable. Anyone
interested in project management will gain
something from reading all of it. Experienced
project managers will enjoy the multitude of J. Ross Publishing, 2011, ISBN:
familiar project situations and issues taken 9781604270402, hardcover, 352 pp.,
from field experience. Junior project man- $49.75 Member, $59.95 Nonmember.
agers will gain useful guidance and some
tools. Upper management will better appreciate the value project
managers bring to their organizations.
Moustafaev admits that most of what he has to say has been
said before, but his lists and tables provide convenient summaries
of the issues, concise tools, and useful guidance. On the subject of
estimation, for instance, Moustafaev explains that estimates
become more precise as projects progress. At project initiation,
accuracy will range from ⫹75 to ⫺25%. In later stages, it narrows
to between ⫹10 and ⫺5%. Unfortunately, customers often need a
price before they start building. An estimate that ranges anywhere
from a quarter less to three quarters greater than a given price is
difficult to sell. Therefore, it is important to define scope and help to running an army could possibly work, but then the example
a customer understand the factors that affect scope, time, cost,
quality, and effort. Note that Moustafaev expands the triple con-
straints into five, which he calls the “project pentagon.”
A principal argument of the book is that the project manager
should be involved during all phases of a project. This includes
initial project selection as well as subsequent scope management
and project execution. Moustafaev’s list of the right questions to
Project Management Journal, Vol. 42, No. 5, 94
© 2011 by the Project Management Institute
Published online in Wiley Online Library (wileyonlinelibrary.com).
DOI: 10.1002/pmj.20265
94 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj
ask and the corresponding table of wrong ways
to define scope are practical guides for defining
a project’s charter.
Moustafaev introduces the responsibility
matrix as a useful tool for keeping track of
assignments. He reviews the difference
between assumptions, risks, and constraints.
These are all things that experienced project
managers understand, but it is helpful to have
them summarized all in one place.
Chapter 14 emphasizes too much the
defensive value of the lessons learned docu-
ment, but otherwise, the points are valid.
Failure to learn from the past dooms one to
repeating it.
Every chapter begins with a small histori-
cal vignette introducing the chapter’s topic.
The chapter on creativity, for instance, begins
with an explanation of why the British army
marched in tight formation through the North
American woods wearing bright red uniforms. It was a creative
tactic to spot (and discourage) deserters.
The chapter on risk management begins with the story of
how the British war office reduced its exposure by selling com-
missions to anyone who would assume the risks of battle for
themselves. A nobleman could buy an officer’s position if he
agreed to finance his own troops and repay himself and them
from the spoils of war. If such an officer was inept, he would die
and be replaced. If he was competent, he would bring victory to
his country, and his country would have spent very little in the
process. One might question whether this free market approach
given is of Arthur Wellesley who, after the Battle of Waterloo, was
awarded the title we know him by, the Duke of Wellington.
Delivering Exceptional Project Results is an easy, enjoyable,
useful, and readable work with something for everyone. The jun-
ior project manager will find some useful guidance. The seasoned
will feel they’ve exchanged war stories with a comrade. And any-
one can enjoy the 19 short stories that introduce each topic.
Reviewed by William A. Scally, PhD, PMP, Project Manager, Mosaic Learning,
Inc., Greenbelt, MD, USA.
95PMJ0808.qxd 8/8/11 12:30 PM Page 95

Cover to Cover

Social Media for Project Managers

by Elizabeth Harrin

ocial media are here to stay. In Chapters 3 through 5 are probably

S spite of continuing concerns

about personal privacy and infor-
mation security, what started in
many cases as a modern means of
entertainment and amusement has
the centerpiece of the book. Harrin dis-
cusses ten different social media tools,
describing them conceptually, not as
specific products, which enhances the
general and long-term utility of the text.
found its way into the mainstream of A common format ensures consistent
project management. Social Media for coverage: What Are They?, Why Should I
Project Managers by Elizabeth Harrin is Use Them?, Pros, and Cons. Some of the
a helpful survey of the technology and pros and cons may seem to be intuitively
the opportunities it presents. obvious or disappointingly brief. Harrin
The book is an easy read. It is written keeps things at a high level at this point
in a casual, familiar style using contem- and that’s probably good. In practice,
porary lingo. Terms not explained in the these tools may be implemented in very
text when introduced are usually includ- different ways in different organizations.
ed in a brief glossary at the end of the Drilling down to details may easily gener-
Project Management Institute, 2010,
book. Use of first- and second-person ate a quagmire of caveats from which the
ISBN: 9781935589112, paperback,
writing gives the text a seminar-narrative, reader might never emerge.
153 pp., $31.95 Member, $39.95
inclusive feel that seems to fit the topic. Chapter 3 is the “what-is” element,
Nonmember.
Readers will quickly discern that this and Chapters 4 and 5 are the “how-to”
book contains a wealth of practical infor- elements from two different points of
mation that has not previously been collected in one place. view. Harrin provides an accurate analysis of communi-
The book’s 12 chapters fall neatly into several sections. cations requirements across the project management life
Chapters 1 and 2 are introductory. Readers looking for a cycle. She describes four specific challenges and how
definition of the term “social media” will not find one here. social media can be applied to overcome them. She does
Instead, they must go to the book’s preface, where Harrin the same for team management. Together, Chapters 4
defines social media in a business environment as “collab- and 5 give readers a sense of the potential value of social
oration and communication with a purpose.” Social media in project management.
media is an activity, not a bunch of things. In Chapter 1, Chapters 6 through 10 address implementation
Harrin describes seven guiding principles of social media: issues. Chapter 8 may be the most interesting to many
community, collaboration, communication, constraints, readers, as it deals in detail with blogs. To many, the
connectivity, channels, and content. She also provides a information presented will be informative and illuminat-
description of “Web 2.0,” a new paradigm of Internet com- ing. To some, it may do much to alleviate concerns about
puting that is more interactive than the static approaches loose cannons rolling irresponsibly across the project
of the past. It allows more user participation in the deck, posting their uncoordinated and unapproved per-
Internet experience and, therefore, enables social media. sonal opinions in open forums for all to see for all time.
Harrin does some more stage setting in Chapter 2, where The book closes with two chapters that provide a bit of
she describes a new way of working that arises from the chal- practical advice and a look to the future.
lenges of economic priorities, new business models, and tech- This is a briefcase book: concise, transportable, and
nology. Social media provides new communication and team easy to read. It is also exceptionally valuable for those
management tools that respond to the new ways and exploit who must manage today’s projects, with today’s work-
contemporary capabilities for the benefit of the project. force, in today’s domains.

Project Management Journal, Vol. 42, No. 5, 95
© 2011 by the Project Management Institute
Published online in Wiley Online Library (wileyonlinelibrary.com).
DOI: 10.1002/pmj.20262
Reviewed by Kenneth H. Rose, PMP, Director, Peninsula Center for
Project Management in Hampton, VA, USA, and winner of the 2006 PMI
David I. Cleland Project Management Literature Award.

September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj 95

96PMJ0808.qxd 8/8/11 12:31 PM Page 96

ERRATUM
Erratum: Are We Getting Any Better?
Comparing Project Management in the
Years 2000 and 2008
Erling S. Andersen

he article from Project Management Journal, In Table 3, showing data for 2008, the values for two of

T Volume 41, Number 4, pages 4–16, discusses the

project management discipline and whether or
not it is progressing. Data is presented for projects
performed in 2000 and 2008.
Table 2 on page 9 presents the most common state-
the statements were reversed in error. The correct values
are as follows:

Statement
Number of Yes Partly No
responses (%) (%) (%)
ments made regarding the projects performed in 2000. An
error was made in presenting the data on the project par- Plans are followed/ 29 34.5 44.8 20.7
ticipants’ knowledge of project work and project methods. milestones or
The correct values appear below for the statement “Good
phases are achieved
as planned
knowledge of project work and methods” (in the article,
the values in the “yes” and “no” columns were reversed): Satisfied customers/ 31 48.4 29.0 22.6
users/project owners

Number of Yes Partly No

Statement responses (%) (%) (%) Based on these corrections, the statements in Figure 6
Good knowledge of 51 15.7 29.4 54.9 on page 12 should read: “Plans are partly followed” and
project work and “Customers/users and project owners are satisfied.” The
methods errors made in presenting the data do not affect the t-tests
since they are based on the correct data.
On page 15 of the article, the statement was made,
As a consequence, the statement in Figure 5 on page “We are not able to see any biases in the kind of projects
10 should read “Poor knowledge of project work and we have data on, but it is not a statistical stochastic stam-
methods.” ple.” Due to the difficulty of obtaining a random selection
Table 3 on page 11 shows that the project participants of all projects within a country, the selection was actually
for the year 2008 have a good knowledge of project work a sample of convenience. However, the samples collected
and methods. The t-test of Table 4 confirms that the from the years 2000 and 2008 are based on the same prin-
knowledge of project work and methods had significant- ciples and thinking by the same category of students
ly increased from 2000 to 2008. The calculation is based (experienced managers from different companies).
on the correct data as presented above, and the test is not
influenced by the error that was made.

Project Management Journal, Vol. 42, No. 5, 96

© 2011 by the Project Management Institute Published online in
Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/pmj.20266

96 September 2011 ■ Project Management Journal ■ DOI: 10.1002/pmj