Sie sind auf Seite 1von 67

PMI-002 11/5

11/6/03

9:20 AM

Page 1

Project
Management
Journal
The Professional Research Journal
of the Project Management Institute

Volume 34, Number 4

DECEMBER 2003

PAPERS

UNDERSTANDING YOUR PROJECT


ORGANIZATIONS CHARACTER
Erling S. Anderson

12

EARNED VALUE PROJECT MANAGEMENT


METHOD AND EXTENSIONS
Frank T. Anbari

24

A CRITICAL LOOK AT CRITICAL CHAIN


PROJECT MANAGEMENT
Tzvi Raz, Robert Barnes and Dov Dvir

33

PROJECT MANAGEMENT LEARNING:


WHAT THE LITERATURE HAS TO SAY
Debbie Tesch, Timothy J. Kloppenborg and John K. Stemmer

40

JWARS:A CASE STUDY


Jim Metzger

47

PROJECT MANAGEMENT IN THE


AGE OF COMPLEXITY AND CHANGE
Ali Jaafari

PMI-002 11/5

11/6/03

9:20 AM

Page 2

Calendar of Events
DECEMBER 2003
1-2 December
The European Marketing Conference Seven world class thought
leaders and top executives discuss strategy, creativity and how
to put theory into practice. A Management Centre Europe
conference. London K.K. For more information, visit
www.mce.be/events/352.htm
8-10 December
12th Global Symposium, Taming the Future through Project
Management. Organized by Project Management AssociatesIndia and Centre for Excellence in Project Management. New
Delhi, India. For more information, visit www.pma-india.org.
JANUARY 2004
12-13 January
Team Building for Project Management. Las Vegas, Nevada,
USA. Sponsored by The University of Wisconsin-Madison,
Department of Engineering Professional Development. For more
information, visit http://epdweb.engr.wisc.edu/webF307.
Contact custserv@epd.engr.wisc.edu or call +800-462-0876.
1920 January
Project Risk Management. Parsippany, New Jersey, USA.
For more information, visit
www.iil.com/str_link_all_results.asp?select_cartid=384
or call toll-free in the United States+800-325-1533.
2123 January
Managing Technology Projects. Arlington, Virginia, USA.
For more information, visit http://cioi.web.cmu.edu/
or call +412-268-4656.
2223 January
Project Risk Management. Salt Lake City, Utah, USA.
For more information,
visit www.iil.com/str_link_all_results.asp?select_cartid=384
or call toll-free in the United States
+800-325-1533.
2830 January
Technical Project Management. Atlanta, Georgia. USA.
For more information, visit www.amanet.org.
FEBRUARY 2004
1819 February
Project Risk Management. Chicago, Illinios. USA.
For more information, visit
www.iil.com/str_link_all_results.asp?select_cartid=384
or call toll-free in the United States+800-325-1533.

1820 February
Technical Project Management. Washington, D.C., USA. For more
information, visit www.amanet.org.
1820 February
Identifying and Managing IT Requirements. Arlington, Virginia.
USA. For more information, visit http://cio.web.cmu.edu/ or call
+412-268-4656.
MARCH 2004
1011 March
Project Risk Management. Dallas, Texas, USA.
For more information, visit
www.iil.com/str_link_all_results.asp?select_cartid=384
or call toll-free in the United States +800-325-1533.
1517 March
IT Project Cost and Schedule Management. Arlington, Va., USA.
For more information, visit http://cio.web.cmu.edu/ or call
+412-268-4656.
1819 March
Managing Complex Product Development Projects. MIT Sloan
School, Cambridge, Mass., USA. For more information, visit
http://mitsloan.mit.edu/exceed or call Maureen Tracy at
+781-239-1111.
APRIL 2004
1721 April
International Cost Engineering Councils 4th World Congress.
Value Beyond Cost. Cape Town, South Africa. For more
information, visit www.be-events.co.za/
or www.apm.org.uk/events.
1921 April
IT Risk Management. Arlington, Va., USA. For more information,
visit http://cio.web.cmu.edu/ or call +412-268-4656.
MAY 2004
1012 May
Project Management South Africa (PMSA) Conference 2004.
Global Knowledge. For more information, visit
www.pmisa.org.za/conference.
1721 May
ProjectWorld Toronto. Metro Toronto Convention Centre,
Ontario, Canada. For more information,
visit www.projectworldcanada.com/toronto/inforeq.asp.
2426 May
Leadership in a Project Environment. Arlington, Va., USA.
For more information, visit http://cio.web.cmu.edu/
or call +412-268-4656.

PMI-002 11/5

11/6/03

9:20 AM

Page 3

Project
Management
Journal
The Professional Research Journal of the Project Management Institute
Volume 34,

Number 4

DECEMBER 2003
3

From the Editor


Parviz F. Rad, PhD, PMP

PAPERS
4

UNDERSTANDING YOUR PROJECT ORGANIZATIONS CHARACTER


Erling S. Anderson

12

EARNED VALUE PROJECT MANAGEMENT METHOD AND EXTENSIONS


Frank T. Anbari

24

A CRITICAL LOOK AT CRITICAL CHAIN PROJECT MANAGEMENT


Tzvi Raz, Robert Barnes and Dov Dvir

33

PROJECT MANAGEMENT LEARNING:WHAT THE LITERATURE HAS TO SAY


Debbie Tesch, Timothy J. Kloppenborg and John K. Stemmer

40

JWARS:A CASE STUDY


Jim Metzger

47

PROJECT MANAGEMENT IN THE AGE OF COMPLEXITY AND CHANGE


Ali Jaafari

59 Cover to CoverBook Reviews


Kenneth H. Rose, PMP

62 Guidelines for PMJ Book Reviews


63 Notes for Authors

PMI-002 11/5

11/6/03

9:20 AM

Page 2

PROJECT MANAGEMENT JOURNAL


EDITORIAL REVIEW BOARD
John R. Adams, Western Carolina University; Frank
T. Anbari, PMP, The George Washington University;
Bud Baker, Wright State University; Rick Bilbro, The
Innova Group, Inc.; David Christensen, Cedar City,
UT; David Cleland, University of Pittsburgh; Helen S.
Cooke, Cooke & Cooke; Dan H. Cooprider, Creative
People Management; Steven V. DelGrosso, IBM;
Deborah Fisher, University of New Mexico; Vipul
Gupta, Saint Josephs University; Francis T.
Hartman, The University of Calgary; Gary C.
Humphreys, Humphreys & Associates; Lewis
Ireland, PMP, Project Technologies Corp.; Peter
Kapsales, Bellcore; Young Hoon Kwak, The
George Washington University; Lee R. Lambert,
PMP, Lambert Consulting Group, Inc.; Alexander
Laufer, Technion-Israel Inst. of Technology; William
Leban, PMP, DeVry University; Robert Loo, The
University of Lethbridge; Kenneth G. Merkel, PMP,
University of Nebraska; Michael D. Okrent, Agilent
Technologies Inc.; Peggy C. Poindexter, Great Falls,
VA; Tzvi Raz, Tel Aviv Unversity; Paul B. Robinson,
The Eastern Management Group; Arnold M. Ruskin,
PMP, Claremont Consulting Group; Richard L.
Sinatra, PMP, Potomac, MD; Dwight SmithDaniels, Arizona State University; James Snyder,
Springfield, PA; Paul Solomon, PMP, B-2 Earned
Value Management Systems; Robert G. Staples,
Monroe, VA; Charles J. Teplitz, University of San
Diego; Veljko M. Torbica, PMP, Florida International
University; Walter A. Wawruck, Vancouver, BC,
Canada; Itzhak Wirth, Saint Johns University; Janet
K. Yates, San Jose State University.

PROJECT MANAGEMENT JOURNAL


EDITOR
Parviz F. Rad, PhD, PMP
Stevens Institute of Technology

PMI PUBLISHING STAFF


Publisher
David Parker; david.parker@pmi.org
Acquisitions Editor
Richard Schwartz; richard.schwartz@pmi.org
Publishing Support Specialist
Natasha Pollard; natasha.pollard@pmi.org
Bookstore Administrator
Regina Madonna; regina.madonna@pmi.org
Book Publishing Planner
Danielle Moore; danielle.moore@pmi.org
Administrative Assistant
Dotti Bobst; dotti.bobst@pmi.org
General e-mail:
pmipub@pmi.org

Book Review Editor


Kenneth H. Rose, PMP

PUBLICATIONS ADVISORY BOARD


David Parker, PMI Publisher; Michael Hatfield, Los
Alamos National Laboratory; Greg Hutchins, Quality Plus
Engineering; William Leban, PMP, DeVry University;
John Sullivan, Reynolds & Reynolds; Charles J.
Teplitz, PMP, University of San Diego, School of Business
Administration

PUBLICATION & MEMBERSHIP


The Project Management Journal (ISSN 8756-9728/03)
is published quarterly (March, June, September, December)
by the Project Management Institute. PMJ is printed in the
USA by Cadmus Magazine, Richmond, VA. Periodical
postage paid at Newtown Square, PA 19073 USA and
at additional mailing offices. Canadian agreement
#40030957. Postmaster: Send address changes to
Project Management Institute, Headquarters, Four Campus
Boulevard, Newtown Square, PA 19073-3299 USA; tel:
+610-356-4600, fax: +610-356-4647.
The mission of the PMJ is to provide information
advancing the state of the art of the knowledge of project
management. PMJ 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 PMJ 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.
Claims for undelivered copies must be made no later
than two months following month of publication. The
publisher will supply missing copies when losses have been
sustained in transit and when the reserve stock will permit.
PMI is a nonprofit professional organization 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
programs; fostering professionalism in the management
of projects; and advocating acceptance of project
management as a profession and discipline.
Membership in PMI is open to all at an annual dues of
$119 U.S. For information on PMI programs and
membership, or to report change of address or
problems with your subscription, contact:

Project Management Institute, Headquarters,


Four Campus Boulevard, Newtown Square, PA 190733299 USA; tel: +610-356-4600; fax: +610-356-4647;
e-mail: pmihq@pmi.org
PMI Regional Service Centre: Europe Middle East - Africa (EMEA), Avenue des Gaulois
7, B-1040 Brussels, Belgium; tel: +32-2-743-15-73; fax:
+32-2-743-15-50; e-mail: emea-servicecentre@pmi.org

EDITORIAL & ADVERTISING SERVICES


Address manuscripts and other editorial submissions,
advertising and mailing list rental inquiries, and requests
for reprints/bulk copies/reprint permission to: Project
Management Institute, Publishing Department,
Four Campus Boulevard, Newtown Square, PA 190733299 USA. tel: +610-356-4600, fax: +610-356-4647;
e-mail: pmipub@pmi.org
Unless otherwise specified, all letters and articles
sent to the PMI Publishing Department are assumed for
publication and become the copyright property of PMI if
published. PMI is not responsible for loss, damage, or
injury to unsolicited manuscripts or other material.

READER SERVICES
Photocopies. PMJ has been registered with the
Copyright Clearance Center, Inc. Consent is given for
copying of articles for personal or internal use, or for the
personal use of specific clients. This consent is given on
the condition that the copier pays through the Center the
per copy fee stated in the code on the first page of each
article for copying beyond that permitted by Sections
107 or 108 of the U.S. Copyright Law. The appropriate
fee should be forwarded with a copy of the first page of
the article to the Copyright Clearance Center, Inc., 222
Rosewood Drive, Danvers, MA 01923 USA (tel: +508750-8400; fax: +508-750-4744). The fee indicated on
the first page of an article in this issue will apply
retroactively to all articles published in the journal,
regardless of the year of publication. This consent does
not extend to other kinds of copying, such as for general
distribution, resale, advertising and promotion purposes,
or for creating new collective works. Special written
permission must be obtained from the publisher for such
copying.
Permissions. Requests to reprint articles published
in PMJ must be made in writing to the publisher.
Reprints. Individual articles may be purchased
through the Knowledge & Wisdom Center
(www.pmi.org/k&wc)
Glossy Reprints. Requests for glossy reprints of
individual articles in quantities of 100 or more can be
sent to pmipub@pmi.org.
Bulk Copies of Current Issues. Copies of the
current PMJ can be obtained in quantities of 25 or more.
Orders must be placed 40 days prior to date of issue.
The cost is $5.50 per copy plus shipping.
Back Issues. Back issues are available on request
at $20 each. Call +610-356-4600 for availability.

2003 Project Management Institute, Inc. All rights reserved.


PMI is a trade and service mark registered in the United States and other nations; PMP and the PMP logo are registered certification marks in the United States and other nations;
PMBOK is a trademark registered in the United States and other nations; and the PMI logo, PM Network, Project Management Journal, PMI Today, and
Building professionalism in project management. are trademarks of the Project Management Institute, Inc.

2 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 3

F ROM THE E DITOR


Parviz F. Rad, PhD, PMP

In terms of presence, stature, and


recognition, project management is

own sense of right and wrong. Given


that professional responsibility is an

approaching the long established


professions such as engineering, law, and

individual issue, fundamentally it stays


unchanged independent of whether the

medicine. Accordingly, the professional


responsibility aspect of project
management practices is receiving an

professional is a member of a
traditional team or a virtual team.
However, the project management

increasing amount of attention,


primarily because it is being recognized that the

professional may have to use modified


means in order to discharge these responsibilities

behavior and performance of project professionals


impact the profit-loss status of the organization, and
to some extent the public welfare, in significant

when working on a virtual team. The areas of


distinction are founded on those behavioral features
that make virtual teams a different entity from

ways. It is fair to say that the activities of the Project


Management Institute during the past two decades
have had a major impact in advancing and
highlighting this very important profession.
The project management tasks and operations

traditional teams, such as people interaction issues


of the team. There is no question that seasoned
project managers will be able to adapt to the new
ethical situations, brought on by the virtual
environment, reasonably well. However, a set of

will be influenced by two sets of policies and


guidelines. One set addresses the conduct of the
collective project team in managing the areas of the
project management body of knowledge. The
second set relates the project managers
interpretation of the legal, ethical, and moral
implications of the project teams actions and
decisions. In turn, these interpretations are driven by
the behavioral attributes and personal judgment of
the individual members of that team, and to some
degree by the organizational culture of that team.

standards, procedures, and guidelines will


illuminate the path even to those who have recently
entered the profession.
As always, on behalf of the editorial board, I
invite our readers to reflect on their professional
experiences with ethical issues in project
management and to share these documented,
methodical, and empirical observations with the
project management community by way of
submitting articles dealing with professional ethics.
I would like to close this letter on a personal

Appropriate conduct, that is consistent with all of

note. For the past three years, I have had the

these standards, is the foundation of professional


responsibility in project management. Generally
speaking, codes of professional conduct are
formulated to protect the interest of the public, the

privilege of serving as the Editor. As part of


discharging my duties as the Editor, I was in an
invigorating position of being in touch with the
latest innovations and research activities in the field

interest of the client, the interest of the profession,

of project management. I am very grateful for having

and the interest of the colleagues. Guidelines


generally
highlight
integrity,
knowledge
management, individual competence, and
stakeholder issues.

been afforded this unique vantage point on the


profession. Notwithstanding, as I finish my term of
office, it is time for me to devote more time to other
endeavors of personal and professional nature. The

Although normally professional responsibility


guidelines provide tools that highlight many of

search for a new Editor has already begun and the


incoming editor will be named soon. Naturally, in

delicate situations that might be potentially


encountered, the final decision will ultimately
depend on ones own personal values, and ones

order to make a smooth transition, I will be serving


in this position until such time that the incoming
Editor has been fully installed.

December 2003 Project Management Journal 3

PMI-002 11/5

11/6/03

9:20 AM

Page 4

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

UNDERSTANDING YOUR PROJECT


ORGANIZATIONS CHARACTER
ERLING S. ANDERSEN,
Norwegian School of Management BI, P.O. Box 580, Sandvika N-1302 Norway

ABSTRACT
Participants from 175 different Norwegian
projects described the organizational
cultures of both their most recent projects
and their organizations. Their descriptions
are based on a typology distinguishing
between power, role, task, and person
cultures, as outlined and developed in
Harrison (1972) and Handy (1986). This
study demonstrates that projects are more
task culture-oriented than their base
organizations. Further, hierarchical
elements of the project must be eliminated
for a project to move closer to the
prevalent task culture. A stronger task
orientation improves the chances of
staying within the project budget.
Keywords: project culture; organizational
culture; task orientation; project success

n organizations culture strongly influences its achievements. There are


several definitions of organizational culture (Brown, 1995). The wellknown definition by Schein (1985) suggests, in essence, that an organizational culture is the pattern of basic assumptions accepted and used by the
organization. Cleland (1988) as well as Firth and Krut (1991) pointed out the
importance of the organizational culture within projects at an early stage.
A project manager faces two main cultural challenges. First, the project
manager quickly must develop a suitable organizational culture within the
project to achieve proper progress and the best results possible. Second, the
project manager must understand the organizational culture of the associated
base organization and the subcultures of various departments to communicate and interact effectively with those groups (Elmes & Wilemon, 1988).
A project manager cannot establish an adequate project culture easily.
Developing an organizational culture requires time, a commodity already at a
premium in most projects. In addition, people are typically recruited to the
project from the base organization, often implying an organizational culture
at odds with the project culture. Most people from the base organization then
must adapt culturally to the new project to function effectively.
This paper is a study of the organizational culture of projects. It is compared with the organizational culture of the projects associated base organization. The author further explores areas that have room for improvement to
achieve a more positive and productive project organizational culture. Finally,
the author investigates whether projects with a certain organizational culture
achieve better results than other projects.

2003 by the Project Management Institute


Vol. 34, No. 4, 4-11, ISSN 8756-9728/03

4 Project Management Journal December 2003

Typologies of Organizational Cultures


Different typologies can illuminate the organizational culture of an organization (Brown, 1995). Deal and Kennedy (1982) distinguish between four
generic cultures: the tough guy-macho culture, the work-hard/play-hard culture, the bet-your-company culture, and the process culture. Scholz (1987)
has identified three culture typologies based on different dimensions of culture: the evolution dimension (how cultures change over time), the internal
dimension (how the internal circumstances of an organization affect its culture), and the external dimension (how an organizations environment affects
its culture). The last dimension coincides with the Deal-Kennedy typology.

PMI-002 11/5

11/6/03

9:20 AM

Page 5

Based on the nature of the transactions associated with information


exchange in organizations, Quinn &
McGrath (1985) distinguish between
four generic cultures: market (the
rational), adhocracy (the ideological),
clan (the consensual), and hierarchy
(the hierarchical). Elmes & Wilemon
(1988) applied this typology in their
discussion of how project managers
must adjust their communications and
strategies depending on the culture of
the base organization.
Dubinkas (1993) elaborates on
two models of organizational culture:
a Taylorist, control-oriented funnel
model and a contrasting, more chaotic
fermentation-vat model with flexible
learning. He uses these cultural models
in an ethnographic field study of a
manufacturing automation project at
an American assembly plant with a
Japanese contractor.
Another typology was introduced
by Harrison (1972) and further discussed and developed by Handy
(1986). They divide the umbrella term
of organizational culture into four different types: power, role, task, and person. A power culture has a single
source of power from which rays of
influence spread throughout the
organization. A role culture is a
bureaucracy, the organizing principles
of which are logic and rationality. A
task culture is one in which power is
based on expertise rather than position
or charisma; structurally, the task culture may be thought of as a network or
matrix. In a person culture, the development of human potential and welfare is paramount; such a culture
develops when a group of people
decide that it is in their own best interest to organize on a collective rather
than an individual basis. It may be represented as a cluster in which no individuals dominate.
The typology of Trompenaars and
Hampden-Turner (1997) may be quite
close to the Harrison-Handy typology.
It too consists of four cultures: family,
Eiffel Tower, guided missile, and incubator. The status of the family culture
is ascribed to close, powerful parent
figures; thinking is intuitive and holistic. In the Eiffel Tower culture, status is

ascribed to superior roles; thinking is


logical, analytical, vertical, and rationally efficient. Typical of the guidedmissile culture is the achievement of
status as organizational members contribute to targeted goals, while thinking is problem centered and
cross-disciplinary. Finally, in the incubator culture, status is achieved as individuals exemplify creativity and
growth and apply creative thinking.
The Research Approach
In this paper, the author studies the
organizational cultures of various
projects and compares these project
cultures with those of the base organizations. Because all typologies presented may be useful in describing
the culture of a base organization, it
is preferable to utilize a typology of
organizational cultures that applies
to the cultures of both project and
base organizations.
An appropriate project culture has
been characterized as a task culture,
i.e., an organizational culture in which
the dominant objective is to complete
a given job, with the cooperative
efforts and complementary talents of
individuals who possess different
expertise (Graham, 1987). The task
culture of the Harrison-Handy typology is an organizational culture that
may coincide with the desired characteristics of an ideal project organization. According to Harrison (1972),
the achievement of a superordinate
goal is the highest value within a task
culture. The important thing is that the
organizations structure, functions, and
activities all are evaluated in terms of
their contribution to the superordinate
goal. Nothing is permitted to distract
from accomplishing the task.
The author has decided to use
the Harrison-Handy typology to
investigate projects and base organizations. With this model, the research
problems are:
Is the task culture the dominant culture in projects?
Is the task culture more dominant in
projects than in base organizations?
What parts of the project culture
should one develop to create a more
task-oriented culture?

Do projects with a strong task culture achieve better results than other
projects?
Harrison developed a questionnaire to study dominant culture in an
organization. The author has applied
the version as it appears in Brown
(1995). The Harrison questionnaire
originally was used to describe the
existing and preferred organizational
culture of a base organization. The
author has, however, adjusted and
employed the questionnaire as a
framework for project participants to
describe their most recent project and
their
base
organization
(see
Appendix). The respondents were
given 15 questions about the organizational culture of their base organization (Questions 1-15) and 15 similar
questions about the organizational
culture of their project (Questions 1630). In addition, the author asked
guided questions regarding the characteristics of the base organization and
the project and posed questions about
project results.
Participants in various part-time
masters degree programs in project
management in Norway were asked to
respond to the questionnaire. All
respondents either were taking part in
a project at the time or recently had
participated in project work. Though
the author cannot claim that the projects studied are representative of all
projects in the country, the research
did cover 175 separate projects conducted in Norway with a generous
cross-section of objectives and participants, a wide range of industries, small
and large companies, and different
geographical regions. Many of the
projects were not finished by the time
of the information gathering. The
author was able to get information
regarding project results for 50 of the
175 responses.
The respondents were not
informed about the purpose of the
investigation, nor was it revealed to
them that the questions were designed
to identify the culture of their base
organization and of their most recent
project. The layout of the questionnaire was such that respondents could
not access easily their earlier responses

December 2003 Project Management Journal 5

PMI-002 11/5

11/6/03

9:34 AM

Page 6

to questions regarding the base organization while they answered questions


about the project. This ensured that
descriptions of the base organization
and project were given independently
of each other.
The description of a culture
addresses 15 different areas of relevance. For each area, the questionnaire
offers four descriptions (statements)
labeled a through d. The four statements are characteristic of the a) power
culture, b) role culture, c) task culture,
and d) person culture. For each area,
the respondent is asked to rank the
statements from one to four, with 1
designating the statement that best
describes the actual situation in their
base organization or project and, conversely, 4 representing the statement
that least describes their situation.
If an organization or project were
perfectly matched to a particular culture (for instance, the task culture, all
15 c) statements would be first-ranked
(given 1), and the score for the task
culture would be a perfect 15.
However, if no congruence were experienced (only 4s), the final score
would be a 60.

instances, two cultures are ranked


equally as first.)
The task culture proves to be the
dominant (first-ranked) organizational culture in most projects (82.6%). In
that sense, projects generally succeed
in creating a desired project culture.
The task culture is first-ranked in nearly 60% of the base organizations (109

Power
culture

Role
culture

Task
culture

Person
culture

Base organizations
Mean
(Standard deviation)

45.0
(8.9)

33.1
(6.7)

29.4
(6.2)

42.7
(7.5)

175

Projects
Mean
(Standard deviation)

49.2
(7.7)

33.8
(5.4)

24.2
(6.0)

42.9
(6.9)

175

out of 183). This result, however,


should not be generalized to cover all
organizations. All respondents are
from organizations that already use
projects as an organizational supplement to the base organization. It is rea-

Role
culture

Task
culture

Person
culture

Base organizations
Number
(Percentage)

12
(6.6)

56
(30.6)

109
(59.6)

6
(3.3)

183
(100.0)

Projects
Number
(Percentage)

5
(2.8)

23
(12.9)

147
(82.6)

3
(1.7)

178
(100.0)

Table 1. Number and Percentages of Cultures First-Ranked in Base Organizations and Projects

6 Project Management Journal December 2003

Table 2. Scores (Means and Standard Deviations) Given to the Four Organizational Cultures Based on
the Ranking of 15 Characteristics of a Culture

Power
culture

The Project Culture


Results and Discussion
Table 1 shows which culture the representatives of the organizations have
ranked as the dominant culture; that
is, the culture scoring the lowest of the
four measured.
As Table 1 shows, all four types of
organizational culture are first-ranked
among base organizations. (The number of first-rankings exceeds the 175
observations because, in some

Table 2 shows the average scores


given to the different organizational
cultures in base organizations and
projects.
Using the paired samples t-test on
the data from Table 2, a significant difference (on level 0.000) is found
between the base organizations and
the projects task culture regarding the

sonable, therefore, to question


whether the task culture of these projects has influenced the culture of the
base organization, thus making such
companies more task culture-oriented.
It is further reasonable to expect that
many organizations will move toward
a task culture in the future, while
increasing responsiveness and flexibility by integrating more of a task culture
into their traditional base culture
(Firth & Krut, 1991).

dominance of the task culture. This


suggests that projects are generally
more oriented toward a task culture
than are base organizations. Hence,
project managers and project team
members are in general able to
establish an organizational culture
better suited to the projects needs
than the existing culture in the base
organization.
A regression analysis, with project
task culture as the dependent variable
and task culture of the base organization as the independent variable, gives
a standardized Beta coefficient of 0.53
(significance level 0.000). This means
that if the task culture of the base
organization improves by one point,
the task culture of the project tends to
be bettered by 0.53. A more task-oriented base organization will bring
more task culture into a project.
Table 3 shows the scores given to
the task culture in the surveyed projects. There was one perfect score of 15
(fully compatible with the task culture), while the highest score was 51.
Different Characteristics of the Project
Culture Results and Discussion
Harrisons questionnaire is based on
the premise that 15 characteristics constitute a culture. By looking closer at

PMI-002 11/5

11/6/03

Number
(Percentage)

9:20 AM

Page 7

15-19

20-24

25-29

30-34

35-39

> 39

40
(22.9)

69
(39.4)

42
(24.0)

12
(6.8)

8
(4.6)

4
175
(2.3) (100.0)

Table 3. The Scores Given to the Task Culture in Projects Based on the Ranking of 15 Characteristics
of a Culture

these characteristics, one can identify


which culture is the dominant one for
each characteristic and see where projects may be improved, moving toward
a perfect task culture.
Table 4 shows there is generally a
great resemblance between the actual
cultures of the base organizations and
their projects, considering the different
characteristics of a culture. According
to the survey results, the culture that is

organization is role-oriented, while the


project team member should be taskoriented. The legitimate reason for
controlling other people in projects is
superior knowledge, while in the base
organization it is rank.
Even if the task culture is ranked
first for nearly all characteristics of
both the project and base organizations, paired samples t-tests on level
0.05 show that there is a significant

Base
organizations
Number

Culture characteristics

All projects

First ranked

Mean
ranked

First ranked

Mean
ranked

1 (16)

Manager

1.94

1.56

2 (17)

Subordinate

1.96

1.62

3 (18)

Good member

1.59

1.41

4 (19)

Career success

2.02

1.66

5 (20)

Treatment of the individual

1.86

1.65

6 (21)

Means of control of people

1.75

1.42

7 (22)

Legitimate reasons for control

1.86

1.99

8 (23)

Basis of task assignment

1.72

1.42

9 (24)

Drivers of work performance

1.59

1.51

10 (25)

Reasons for cooperation

1.57

1.38

11 (26)

Purpose of competition

2.12

1.58

12 (27)

Handling of conflict

1.97

1.58

13 (28)

Decision-making

1.63

1.87

14 (29)

Communication structure

2.06

1.78

15 (30)

Response to the environment

1.87

1.63

Table 4. First-Ranked Organizational Culture and Mean Values Within the Different Culture Areas for
Base Organizations and Projects

first-ranked in the projects is nearly


always first-ranked in the base organizations as well.
There are only two exceptions
here: cultural characteristics 3 (18) and
7 (22). The ideal member of the base

difference between them for all characteristics but one: drivers of work performance. This suggests that there is a
significant difference between the project and the base organization culture
for the different cultural characteristics.

Further, the most widespread cultural distinctions of project culture as


defined by the lowest mean (closest to
a perfect 1) (see Table 4) are:
People collaborate when their
joint contribution is needed to perform the task (project culture characteristic 25c);
A good member gives priority to
the task requirements for skill, ability,
energy, and material resources (18c);
People are influenced by communication of task requirements leading
to appropriate action that is motivated
by personal commitment to goal
achievement (21c);
The basis of task assignment is the
resource and expertise requirements of
the job to be done (23c).
These factors are most strongly
associated with the project culture and
are well suited for characterizing a
project.
Meanwhile, for projects in general,
the largest discrepancies exist in relation to an ideal task culture in the following areas:
Decisions are made by the person
with the most knowledge and expertise
about the problem (project culture
characteristic 28c);
It is legitimate for one person to
control anothers activities if he/she
has more knowledge that is relevant to
the task (22c).
In an appropriate control and
communication structure, information
about task requirements and problems
flows from the center of task activity
upward and outward, with those closest to the task determining the
resources and support needed from the
rest of the project. A coordinating
function may set priorities and overall
resource levels based on information
from all task centers. The structure
shifts with the nature and location of
the tasks (29c).
The author has identified three
areas where the projects depart the
most from the task culture. Looking
more closely at the three characteristics, the participants responses suggest
that a hierarchical project structure
serves as a barrier to achieving an ideal
task culture. Decisions are taken in
accordance with a hierarchy, control is

December 2003 Project Management Journal 7

PMI-002 11/5

11/6/03

9:20 AM

Page 8

carried out based on the hierarchy, and


information is disseminated on the
basis of the organizational hierarchy,
suggesting that, even in projects, position and status count more than
knowledge and expertise.
If the objective for the project culture is to move toward the ideal task
culture, there may be a trade-off
between the interests of the project
and those of the project owner (the
individuals responsible for the project
in the base organization). For instance,
if a flatter project organization should
prove to be necessary to create a better
task culture, the project owner may be
opposed to it, fearing that such a structure would conceal who is in charge of
the projects different tasks. Even the
project manager may feel that a traditional hierarchy is a safer way of delegating responsibility than leaving it to
a larger group of people.
The Project Results and TaskOrientation Results and Discussion
The research objectives include an
analysis of the correlation between
task-orientation and project outcome.
This requires actual project results
data, in addition to the responses on
the organizational culture questionnaire.
Traditionally, an evaluation of
project results is based on whether the
project achieves its goals on time and
within budget. However, this represents a narrow interpretation of project
results (Atkinson, 1999; Lim &
Mohamed, 1999). For this reason, the
project results are divided into eight
result elements that give a more comprehensive picture of a preferable project outcome. The list of elements is
presented as part of Table 5 and
includes the traditional way of measuring results of a project: finished on
schedule, within budget, and according to planned quality standards.
However, today most project owners
consider that the most decisive feature
of a project is whether the final products are useful for the base organization, so this measurement is included.
It also is important that project results
appeal to all stakeholders. Because
projects should be considered a learn-

8 Project Management Journal December 2003

ing experience and motivation for


future work, facilities for acquiring
knowledge are a prerequisite for continuous development.
Respondents judged the result elements of their projects on a scale from
1 to 6, where 1 represents strong disagreement with the given statement
and 6 represents strong agreement.
Table 5 shows that there is room for
improvement. The Norwegian projects
score rather low on satisfying all the
stakeholders, struggle to keep their
schedule, yet are much better at staying
within budget. Nonetheless, most
project participants are motivated to
engage in new projects.
Table 5 further shows that there
generally is not a strong correlation
between results and the projects task
culture-orientation. There are indications that a stronger task-orientation
might yield better project results, yet
only one correlation is statistically significant. A stronger task-orientation (a
lower score on the task culture)
improves the budget performance of a
project (a higher score on this result
element). Two of the result elements
even have the wrong sign, indicating

Result elements

that the task-orientation itself does not


improve these kinds of results.
It should not come as a surprise
that there are other factors apart from
the projects organizational culture
that contribute to the results of a project. Looking at just a single contributing factor may, in fact, suggest a
different outcome. As shown by Pinto
& Slevin (1987), there are many factors
that affect the outcome of a project.
This study does not aim to explain or
study all these factors. Rather, it shows
that most projects find it beneficial to
establish an organizational culture
marked by more task-orientation than
its base organization. The strength of
task-orientation has a direct influence
on a projects ability to stay within its
budget, but in most respects, task-orientation probably has a more indirect
effect on the results of a project.
Implications for Practitioners
There are significant differences in
organizational culture between base
organizations and the projects that
they establish. Further, projects are different in terms of organizational culture, even though most of them have a

Correlation
Mean Standard with task- Significance
deviation orientation

The project is finished on time

4.4

1.5

-.149

.324

The project is finished within budget

5.2

1.0

-.298

.056*

The project has met its planned


quality standard

4.6

1.2

.059

.702

The projects end product is already


employed or adapted as planned
or designed

4.8

1.0

-.165

.259

All participants regard this project as


a success

4.5

1.1

-.108

.469

The project participants have


significantly learned from this project

5.0

1.3

.022

.883

The project participants are well


motivated for future projects

5.0

1.3

-.099

.497

All relevant documents from this


project are compiled in a separate
report or file

5.1

1.3

-.040

.791

All result elements

4.7

0.7 -

.150

.414

Table 5. Result Elements, Their Means, Standard Deviations and Pearson Correlations with the TaskOrientation of the Project

PMI-002 11/5

11/6/03

9:20 AM

Page 9

task culture. The organizational culture


affects project results, but the existence
of a strong task culture is not the decisive factor in most cases.
For project managers to establish a
preferred culture in their projects, they
must have a comprehensive picture of
the existing culture. Without appropriate knowledge of the present situation,
they will be unable to make definite
changes to the culture. For effective
communication with the base organization, they must be properly
informed of its organizational culture.
Project managers and practitioners may use this studys questionnaire
to explore the different natures of their
project culture and base organizational
culture. In other words, both the
approach and results of this study will
give practitioners material for an evaluation of their present situation.
Utilizing the questionnaire determines
the general characteristic of the culture,
i.e., which culture is the dominant one
within an organization. It also will give
a more detailed description of 15 areas
that are relevant to perceiving an organizational culture.
Within some projects several
members of the project team have
responded to the questionnaire and
given their views on the organizational
culture of the project. The responses
have been compared, and the results
have been utilized in an organizational development effort within the project to create a shared vision of the
desired culture and a common effort to
implement it.
Further Research
In this study, only one participant has
evaluated each project. It would be
interesting to obtain several views on
the same organizational culture to
study if project participants experience
the culture in the same way.
Other typologies than the
Harrison-Handy typology may be
worthwhile to study.
Conducting more in-depth studies
of actual projects that belong to the
various cultures also could be useful.
Handy (1986) states that the person
culture is an unusual one (p. 189).
Because Table 1 indicates that three

projects were characterized as person


culture-oriented, one might learn
more about this culture by closely
studying such projects.
Additional research challenges
prevail. This research has not fully
explained why project managers
choose to establish a strong task culture within their projects and what is
the optimal culture of a project.
Finally, this study takes its empirical
materials solely from Norwegian projects and base organizations. It would
be of interest to see if the findings hold
true for other countries as well.
References
Atkinson, R. (1999). Project management: Cost, time and quality, two best
guesses and a phenomenon, its time
to accept other success criteria.
International
Journal
of
Project
Management, 17(6), 337-342.
Brown, A. (1995). Organisational
culture. London: Pitman Publishing.
Cleland, D. I. (1988). The cultural
ambience of project management Another look. Project Management
Journal, 19(3), 49-56.
Deal, T. E., & Kennedy, A. A.
(1982). Corporate cultures: The rites and
rituals of corporate life. Reading, MA:
Addison-Wesley.
Dubinkas, F. A. (1993). Modeling
cultures of project management.
Journal of Engineering and Technology
Management, 10 (1,2), 129-160.
Elmes, M., & Wilemon, D. (1988).
Organizational culture and project
leadership
effectiveness.
Project
Management Journal, 19, 54-63.
Firth, G., & Krut, R. (1991).
Introducing a Project Management
Culture. European Management Journal,
9(4), 437-443.
Graham, R. J. (1987). Project management as if people mattered. Bala
Cynwyd, PA: Primavera Press.
Handy, C. (1986). Gods of management. London: Souvenir Press.
Harrison, R. (1972). Understanding
your organizations character. Harvard
Business Review 50(3), 119-128.
Lim, C. S., & Mohamed, M. Z. (1999).
Criteria of project success: an exploratory
re-examination. International Journal of
Project Management, 17(4), 243-248.

Pinto, J. K., & Slevin, D. P. (1987).


Critical factors in successful project
implementation. IEEE Transactions on
Engineering Management, 34(1), 22-27.
Quinn, R. E., & McGrath, M. R.
(1985). The transformation of organizational cultures: A competing values
perspective. In P.J. Frost, L.F. Moore,
M.R. Louis, C.C. Lundberg, & J. Martin
(Eds.), Organizational culture (315334). Newbury Park, CA: Sage.
Schein,
E.
H.
(1985).
Organizational culture and leadership.
San Francisco,CA: Jossey-Bass.
Scholz, C. (1987). Corporate culture and strategy - The problem of
strategic fit. Long Range Planning,
20(4), 78-87.
Trompenaars, F., & HampdenTurner, C. (1997). Riding the waves of
culture. London: Nicholas Brearley.
Appendix: Questionnaire
Questions 1-15 explore the organizational culture of the base organization,
and questions 16-30 the organizational culture of the project. (This information was not given to the respondents.)
Instructions
For questions 115, give a 1 to the
statement that best describes the actual
situation in your line organization, a
2 to the next closest to the actual situation, and so on through 3 and 4.
For questions 1630, give a 1 to
the statement that best describes the
actual situation in your most recent
project, a 2 to the next closest to the
actual situation, and so on through 3
and 4.
1 (16) My line manager (project
manager) is:
a. Strong, decisive, and firm, but fair.
He/she is protective, generous, and
indulgent to loyal subordinates.
b. Impersonal and correct, avoiding
the exercise of authority for his/her
own advantage. He/she demands from
the subordinates only that which is
required by the formal system.
c. Egalitarian and capable of being
influenced in matters concerning the
task. He/she uses authority to obtain
the resources needed to complete
the job.

December 2003 Project Management Journal 9

PMI-002 11/5

11/6/03

9:20 AM

Page 10

d. Concerned with and responsive to


the personal needs and values of others. He/she uses the position to provide satisfying and growth-stimulating
work opportunities for subordinates.
2 (17) A good subordinate in my line
organization (project) is:
a. Compliant, hard working, and loyal
to the interests of his/her superior.
b. Responsible and reliable, meeting
the duties and responsibilities of
his/her job and avoiding actions that
surprise or embarrass his/her superior.
c. Self-motivated to contribute his/her
best to the task and is open with ideas
and suggestions. He/she is nevertheless
willing to give the lead to others when
they show greater expertise or ability.
d. Vitally interested in the development of his/her own potentialities and
open to learning and to receiving help.
He/she also respects the needs and values of others and is willing to help and
contribute to their development.
3 (18) A good member of my line
organization (project) gives first priority to the:
a. Personal demands of the boss (project manager).
b. Duties, responsibilities, and
requirements of his/her own role and
to the customary standard of personal
behavior.
c. Requirements of the task for skill,
ability, energy, and material resources.
d. Personal needs of the individuals
involved.
4 (19) People who do well in my line
organization (project) are:
a. Shrewd and competitive with a
strong drive for power.
b. Conscientious and responsible with
a strong sense of loyalty to the organization (project).
c. Technically effective and competent
with a strong commitment to getting
the job done.
d. Effective and competent in personal
relationships with a strong commitment to the growth and the development of people.
5 (20) My line organization (project)
treats the individual as:
a. Though his/her time and energy

10 Project Management Journal December 2003

were at the disposal of persons higher


in the hierarchy.
b. Though his/her time and energy
were available through a contract
with rights and responsibilities for
both sides.
c. A coworker who has committed
his/her skills and abilities to the common cause.
d. An interesting and worthwhile person in his/her own right.
6 (21) People in my line organization
(project) are controlled and influenced
by the:
a. Personal exercise of economic and
political power (rewards and punishments).
b. Impersonal exercise of economic
and political power to enforce procedures and standards of performance.
c. Communication and discussion of
task requirements leading to appropriate action motivated by personal commitment to goal achievement.
d. Intrinsic interest and enjoyment to
be found in their activities and/or by
concern and caring for the needs of the
other persons involved.
7 (22) It is legitimate for one person in
my line organization (project) to control anothers activities if:
a. He/she has more authority and
power in the organization (project).
b. His/her role prescribes that he/she is
responsible for directing the other.
c. He/she has more knowledge relevant
to the task.
d. The other accepts that the first persons help or instruction can contribute to his/her learning and growth.
8 (23) The basis of task assignment in
my line organization (project) is the:
a. Personal needs and judgment of
those in authority.
b. Formal divisions of functions and
responsibilities in the system.
c. Resource and expertise requirements
of the job to be done.
d. Personal wishes and needs for learning and growth of individual organization (project) members.
9 (24) Work in my line organization
(project) is performed out of:
a. Hope of reward, fear of punishment,

or personal loyalty toward a powerful


individual.
b. Respect for contractual obligations
backed up by sanctions and loyalty
toward the organization (project) or
system.
c. Satisfaction in excellence of work
and achievement and/or personal
commitment to the task or goal.
d. Enjoyment of the activity for its own
sake and concern and respect for the
needs and values of the other persons
involved.
10 (25) People in my line organization
(project) work together when:
a. They are required by higher authority or when they believe they can use
each other for personal advantage.
b. Coordination and exchange are
specified by the formal system.
c. Their joint contribution is needed to
perform the task.
d. The collaboration is personally satisfying, stimulating, or challenging.
11 (26) The purpose of competition in
my line organization (project) is to:
a. Gain personal power and advantage.
b. Gain high-status positions in the
formal system.
c. Increase the excellence of the contribution to the task.
d. Draw attention to ones own personal needs.
12 (27) Conflict in my line organization (project) is:
a. Controlled by the intervention of
higher authorities and often fostered
by them to maintain their own power.
b. Suppressed by reference to rules,
procedures, and definitions of responsibility.
c. Resolved through full discussion of
the merits of the work issues involved.
d. Resolved by open and deep discussion of personal needs and values
involved.
13 (28) Decisions in my line organization (project) are made by the:
a. Person with the higher power and
authority.
b. Person whose job description carries
the responsibility.
c. Person with the most knowledge

PMI-002 11/5

11/6/03

9:20 AM

Page 11

and expertise about the problem.


d. Person most personally involved
and affected by the outcome.
14 (29) In an appropriate control and
communication structure in my line
organization (project):
a. Command flows from the top down
in a simple pyramid so that anyone
who is higher in the pyramid has
authority over anyone who is lower.
Information flows up through the
chain of command.
b. Directives flow from the top down
and information flows upward within
functional pyramids that meet at the
top. The authority and responsibility
of a role is limited to the roles beneath
it in its own pyramid. Cross-functional
exchange is constricted.
c. Information about task require-

ments and problems flows from the


center of task activity upward and outward, with those closest to the task
determining the resources and support
needed from the rest of the organization (project). A coordinating function
may set priorities and overall resource
levels based on information from all
task centers. The structure shifts with
the nature and location of the tasks.
d. Information and influence flow
from person to person, based on
voluntary relationships initiated for
purposes of work, learning, mutual
support, enjoyment, and shared
values. A coordinating function
may establish overall levels of contribution needed for the maintenance of the organization (project).
These tasks are assigned by mutual
agreement.

15 (30) The environment to my line


organization (project) is responded
to as though it were:
a. A competitive jungle in which everyone is against everyone else and those
who do not exploit others are themselves exploited.
b. An orderly and rational system in
which competition is limited by law
and there can be negotiation or compromise to resolve conflicts.
c. A complex of imperfect forms and systems that are to be reshaped and improved
by the achievements of the organization
(project).
d. A complex of potential threats and support. It is used and manipulated by the
organization (project) both as a means of
self-nourishment and as a play-and-work
space for the enjoyment and growth of
organization (project) members.

ERLING S. ANDERSEN is professor of Information Systems and Project Management at the Norwegian
School of Management BI. He holds a Master in Economics from University of Oslo. Before joining NSM BI
he was Professor of Information Science at University of Bergen. He has published several books and articles on information technology, systems development, project management and management in general. His book Goal Directed Project Management (written with Kristoffer Grude and Tor Haug) is
translated into several languages.

Do you need participants in a


survey for an upcoming
research project?
Please contact
Highly skilled and trained project management
professionals are perfect candidates for
participating in your questionnaire.
A random-sampling of names is now available
and/or you can select from over 100 industries
and occupations.

Lisa Fisher at
+1-828-293-0421
for more details.

December 2003 Project Management Journal 11

PMI-002 11/5

11/6/03

9:20 AM

Page 12

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

EARNED VALUE PROJECT MANAGEMENT


METHOD AND EXTENSIONS
FRANK T. ANBARI, PHD, PMP Project Management Program, Department of Management Science,
School of Business and Public Management, The George Washington University,
2115 G Street NW, Washington, DC 20052 USA

ABSTRACT
The earned value project management
method integrates three critical elements
of
project
management:
scope
management, cost management, and time
management. It requires the periodic
monitoring of actual expenditures and
physical scope accomplishments, and
allows calculation of cost and schedule
variances, along with performance indices.
It allows forecasting of project cost and
schedule at completion and highlights the
possible need for corrective action.
This paper shows the major aspects of the
earned value method and presents graphical tools for assessing project performance trends. It provides logical extensions
and useful simplifications to enhance the
effective application of this important
method in project management.
Keywords: earned value method (EVM);
earned value management system
(EVMS); cost variance (CV); schedule
variance (SV); cost performance index
(CPI); schedule performance index
(SPI); critical ratio (CR); cost estimate at
completion (EAC); time estimate at completion (TEAC)
2003 by the Project Management Institute
Vol. 34, No. 4, 12-23, ISSN 8756-9728/03

12 Project Management Journal December 2003

Introduction
he earned value project management method is a powerful tool that supports the management of project scope, time, and cost. It allows the calculation of cost and schedule variances and performance indices, and
forecasts of project cost and schedule at completion. It provides early indications
of expected project results based on project performance and highlights the possible need for corrective action. As such, it allows the project manager and project team to adjust project strategy and to make trade-offs based on project
objectives, actual project performance, and trends, as well as the environment in
which the project is being conducted.
The method uses cost and value as the common measures of project performance for both cost and schedule parameters. It allows the measurement of
cost and value in dollars, hours, worker days, or any other similar unit.
This paper shows the major aspects of the earned value method, presents
graphical tools that enhance its effectiveness, and provides useful simplifications
and logical extensions of this important project management method.

Background
A basic form of the earned value analysis project management method (often
referred to as EVA or EVM) can be traced back to industrial engineers on the factory floor in the late 1800s (Fleming & Koppelman, 2000; Kim, 2000). Around
1967, EVM was introduced by agencies of the U.S. federal government as an integral part of the cost/schedule control systems criteria (C/SCSC) and was used in
large acquisition programs. EVM has been widely and successfully used in projects associated with the U.S. federal government, with much less reported use in
private industry. Use of EVM in private industry and support by popular project
management software packages have been limited but have rapidly grown in
recent years.
To encourage wider use of EVM in the private sector, the U.S. federal government decided to discard C/SCSC by the end of 1996 and turned toward a more
flexible earned value management system (EVMS), also called the earned value
project management system (EVPMS). Project Management Institutes A Guide to
the Project Management Body of Knowledge (PMBOK Guide) (Project Management
Institute, 2000) provided the simplified EVM terminology and formulas.

PMI-002 11/5

11/6/03

9:20 AM

Page 13

There has been a high degree of


EVM acceptance among current and
past users of the method. They tend
to agree that EVM can improve cost,
schedule, and technical performance
of their projects. EVM nonusers indicate that the method is hard to use,
that it applies primarily to federal
projects, and that they do not need it
(Fleming & Koppelman, 2000;
Kim, 2000).
This paper simplifies EVM and
shows its applicability to public and
private sector projects, regardless of
size. The paper uses the simplified terminology and provides graphical
tools, extensions, and applications of
EVM to enhance the use and effectiveness of this important project management method.

Actual cost (AC): This is the cumulative AC spent to a given point in time
to accomplish an activity, work package, or project and to earn the related
value. This was previously called the
actual cost of work performed
(ACWP). Figure 2 illustrates a project
in which the planned value as of the
project status date is PV = $50,000 and
the actual cost is AC = $60,000.

Cost

Planned
Value (PV)

($000)

60
50

Actual Cost
(AC)

Budget At
Completion
(BAC)

Status Date

Time

Figure 2. Planned Value and Actual Cost

EVM Key Components


EVM uses the following project parameters to evaluate project performance:
Planned value (PV): This is the timephased budget baseline (Figure 1). It is
the approved budget for accomplishing the activity, work package, or project related to the schedule. It can be
viewed as the value to be earned as a
function of project work accomplishments up to a given point in time. This
graph of cumulative PV is often
referred to as the S-curve (because,
with a little imagination, it looks like
the letter S, or as an abbreviation of the
Spending-curve). This was previously
called the budgeted cost of work
scheduled (BCWS).
Budget at completion (BAC): This is
the total budget baseline for the activity, work package, or project (Figure 1).
It is the highest value of PV and the last
point on the cumulative PV curve.

Cost

Planned
value (PV)

Earned value (EV): This is the cumulative earned value for the work completed up to a point in time. It
represents the amount budgeted for
performing the work that was accomplished by a given point in time. This
was previously called the budgeted
cost of work performed (BCWP). To
obtain EV for an item, multiply its
total budget by its completed proportion. Table 1 shows the work breakdown structure (WBS) of a project with
a total budget of $100,000. Work package 1.1 has a total budget of $20,000
and is 100% complete as of the status
date. Therefore, the earned value for

Figure 1. Planned Value and Budget


at Completion

Performance Measurement
Cost performance is determined by
comparing the EV to the AC of the
activity, work package, or project.
Schedule performance is determined
by comparing the EV to the PV. This
can be accomplished by calculating the

($000)
Project
Phase 1
Work Package 1.1
Work Package 1.2
........
Phase 2
Work Package 2.1
Work Package 2.2
........
........

Budget At
Completion
(BAC)

Time

this work package is EV = $20,000 x


1.00 = $20,000. Work package 1.2 has
a total budget of $40,000 and is 50%
complete as of the status date.
Therefore, the earned value for this
work package is EV = $40,000 x 0.50 =
$20,000. The earned value for the
entire project is EV = $20,000 +
$20,000 = $40,000.
The preceding formula converts
project accomplishments from physical units of measure, e.g., cubic yards
of concrete, linear feet of cable, percent
complete, milestones achieved, or
deliverables completed, to financial
units of measure. These financial
measurements of value can be in dollars (or any other currency), labor
hours, work hours, worker days, or any
other similar quantity that can be used
as a common measurement of the
value and cost associated with project
work. Figure 3 illustrates the above
project, in which the total budget at
completion is BAC = $100,000, the
planned value as of the status date is
PV = $50,000, the actual cost is AC =
$60,000, and the earned value is EV =
$40,000. These are the main basic entities in EVM.

Total

Budget

% Complete

Earned
Value

20
40

100
50

20
20

...
...
...
...
100

40

Table 1. WBS, Budget, % Complete, and Earned Value

December 2003 Project Management Journal 13

Cost

Planned
Value (PV)

($000)
60
50
40

9:20 AM

Actual Cost
(AC)

Earned
Value (EV)

Page 14

Budget At
Completion
(BAC)

Status date

Time

Figure 3. Planned Value, Actual Cost and


Earned Value

variances, the variance percentages,


and the performance indices at the
desired levels of the WBS. It is interesting to note that these comparisons are
made to the EV, rather than to the
baseline PV.
It is important to synchronize the
status date for data in the analysis. This
can be accomplished by using the concept of accrued cost, which includes
expenditures made but not yet reflected in the financial system, to accomplish work up to the status date.
Variances
The following formulas are used to calculate the variances, generally based
on cumulative data, also called inception-to-date data and project-to-date
data (Figure 4, using the data from the
above project):
The cost variance (CV) is a measure of the budgetary conformance of
actual cost of work performed: CV =
EV AC. For the above project, CV =
$40,000 $60,000 = -$20,000.
The schedule variance (SV) is a
measure of the conformance of actual
progress to the schedule: SV = EV PV.
For the above project, SV = $40,000
$50,000 = -$10,000.
Time variance: The average AC per
time period is often called the spend
rate or burn rate. Similarly, the average
PV per time period can be called the
planned
accomplishment
rate,
planned value rate, or the PV rate. It is
defined as the baseline BAC divided by
the baseline schedule at completion
(SAC). As a formula, PV Rate = BAC /
SAC. Thus, SV can be translated into
time units by dividing SV by the PV
Rate. The result is the SV in time units
or the TV. As a formula, TV = SV / PV
Rate. If the above project were scheduled for forty weeks, then:

14 Project Management Journal December 2003

PV Rate = $100,000 / 40
= $2,500 per week
TV = -$10,000 / $2,500 =
-4 weeks
TV measurement also can be performed and reported graphically. This
is accomplished by drawing a horizontal line from the intersection of
the EV curve with the status date to the
PV curve and reading the distance on
the horizontal time axis (Fleming &
Koppelman, 2000), as shown in
Figure 4.
In the above formulas, 0 indicates
that performance is on target. A positive value indicates good performance. A negative value indicates poor
performance.

Cost

Planned
Value (PV)

($000)
60
50
40

SV = -10

Actual Cost
(AC)

Earned
Value (EV)

Budget At
Completion
(BAC)
CV = -20

For the above project, SVP =


-$10,000 / $50,000 = -20 %. This
means that the project is 20%
behind schedule.

CV and SV ($000)

11/6/03

40

Good

20
0

SV
CV

-20

Poor

-40

Time

Figure 5. CV and SV Graph

However, it may be appropriate


to use EV rather than PV in the
denominator of this formula (J. J.
Moder in Cleland & King, 1988). The
SVP based on the earned value
(SVev% or SVPev) would be defined
as: SVPev = SV / EV. For the above
project, SVPev = -$10,000 / $40,000 =
-25%. This indicates that the project is
25% behind schedule.

Status date

Time

Figure 4. Variances

Graphical Displays
Graphs of variances over time provide
valuable indicators of trends in project
performance and of the impact of any
corrective actions (Figures 5 and 6).
Variance Percentages
The following formulas are used to
calculate the variance percentages,
generally based on cumulative data
(Figure 4, using the data from the
above project):
The cost variance percent (CV% or
CVP) is a measure of the budgetary
conformance of actual cost of work
performed: CVP = CV / EV. For the
above project, CVP = -$20,000 /
$40,000 = -50%, which indicates that
the project is 50% over budget.
The schedule variance percent
(SV% or SVP) is a measure of the conformance of actual progress to the
schedule. The following formula has
been generally used to calculate it
(Project Management Institute, 2000):
SVP = SV / PV.

TV (Weeks)

PMI-002 11/5

Good

2
0
-2
-4

Poor
TV
Time

Figure 6. TV Graph

SVPev is consistent with the formula for CVP. It points out that SV
occurred while accomplishing EV.
Therefore, it may be a better indicator
of project schedule status, as shown
later in the calculation of the time estimate at completion (TEAC).
In the above formulas, 0 indicates
that performance is on target. A positive value indicates good performance. A negative value indicates poor
performance.
Performance Indices
The following formulas are used to calculate the performance indices, generally based on cumulative data (Figure 4,
using the data from the above project):
The cost performance index (CPI)
is a measure of the budgetary confor-

9:20 AM

Page 15

mance of actual cost of work performed: CPI = EV / AC. For the above
project, CPI = $40,000 / $60,000 =
0.67.
The schedule performance index
(SPI) is a measure of the conformance
of actual progress to the schedule: SPI
= EV / PV. For the above project, SPI =
$40,000 / $50,000 = 0.80.
Performance indices can be
thought of as efficiency ratios. In the
above formulas, 1.00 indicates that
performance is efficient and on target.
More than 1.00 indicates excellent,
highly efficient performance, and less
than 1.00 indicates poor, inefficient
performance.
The inverse of the formulas given
above has also been used (Anbari,
1980; Egan, 1982; Cioffi, 2002;
Webster, 2002). This facilitates use of
the indices in forecasting. Using the
inverse definition, the CPI for the
above project would be $60,000 /
$40,000 = 1.50, indicating that the
project is running 50% over budget.
Completion of the project would be
forecasted at $150,000, if performance
continues at this rate. Similarly, the SPI
would be $50,000 / $40,000 = 1.25,
indicating the project is running 25%
behind schedule. The project would be
forecasted to take 25% longer than the
original schedule, with completion at
1.25 x 40 weeks = 50 weeks, if performance continues at this rate. These
forecasts are discussed in more detail
in the forecasting section of this paper.
Graphs of performance indices
over time provide valuable indicators
of trends in project performance and
the impact of any corrective actions.
These graphs can be very effective in
project reviews (Figure 7).
The Critical Ratio
The critical ratio (CR) is the product of
CPI and SPI (Anbari, 2001; Lewis,
2001). It can also be called the costschedule index (CSI) (Barr, 1996;
Meredith & Mantel, 2000). It is used as
an indicator of the overall project
health: CR = CPI x SPI. For the above
project, CR = 0.67 x 0.80 = 0.53.
A CR of 1.00 indicates that the
overall project performance is on target. This may result from both CPI and

1.4

CPI and SPI

11/6/03

Good

1.2
1.0
.80
.60

SPI
CPI

Poor

Time

Figure 7. CPI and SPI Graph

SPI being close to target, or, if one of


these indices suggests poor performance, the other must be indicating
good performance. This allows some
trade-offs to reach the desired project
goals.
A CR of more than 1.00 indicates
that the overall project performance is
excellent. This may result from both
the CPI and SPI being better than target, or, if one of these indices is indicating poor performance, the other
must be indicating outstanding performance. This allows extensive tradeoffs to reach the desired project goals.
A CR of less than 1.00 indicates
that the overall project performance is
poor. This may result from both the
CPI and SPI being worse than target,
or, if one of these indices suggests
good performance, the other must be
indicating extremely poor performance. This limits the use of effective
trade-offs, and highlights significant
difficulty in attempting to reach the
desired project goals.
A graph of the critical ratio over
time provides a quick indicator of
trends in the overall project performance, and of the impact of any corrective actions. These graphs may be very
effective in project reviews (Figure 8).

1.4

Good

1.2

CR

PMI-002 11/5

1.0
.80
.60

Poor
CR
Time

Figure 8. CR Graph

Quantifying the Traffic Light Approach


Graphs of CPI, SPI, and CR can be
used to further highlight these meas-

ures of project performance and to


quantify the traffic light approach.
We can include the line that indicates
on target performance with the area
that indicates good performance and
use the color green to indicate on target and good (better than target) performance. We can break the poor
performance area into two and use
the color yellow to indicate somewhat
below target performance, and the
color red to indicate poor performance. It is important for the organization to carefully establish meaningful
thresholds, acceptable tolerances, or
critical limits for action on project
performance. This helps ensure that
when action is needed, it is highlighted, and when action is not needed,
tampering and micromanagement are
minimized.
For example, performance indices
and critical ratios of 1.00 or above can
be considered green; performance
indices and critical ratios equal to or
greater than 0.80, but less than 1.00,
can be considered yellow; and performance indices below 0.80 can be
considered red. In this paper, a black
and white chart depicting this concept
is shown in Figure 9, and is called the
target performance chart. It can be produced in color and may also be nicknamed the rainbow chart.
Other colors can also be added.
For example, orange or amber can be
used between yellow and red, or in the
yellow area to indicate that the item in
trouble has been previously reviewed.
Blue can be used to indicate the superstarsitems with performance indices
above 1.20, for example (Figure 9).
Some may say that such superstar
items must have had inflated baseline
budgets and schedules. However, there
may be important lessons to be
learned from these items in terms of
estimating, budgeting, performance
management, and cost control.
Reallocation
of
organizational
resources may be another outcome
from such analyses (Lewis, 2001).
An activity, work package, or project should be carefully reviewed when
it enters the yellow zone, with the
intent of finding the root cause(s) of
performance or planning problems

December 2003 Project Management Journal 15

PMI-002 11/5

11/6/03

9:20 AM

Page 16

CPI, SPI, and CR

and eliminating them. When an item


in the red zone is reviewed, this should
generally be a status report on
action(s) taken or not taken when that
item was in the yellow zone. When an
item enters the blue zone, it also
would be appropriate to review it, to
obtain information on the root
cause(s) of the super performance, and
incorporate the lessons learned into
future work.

1.4

Super Stars

1.2

Good
1.0
.80
.60

Caution
SPI
CPI
CR

Poor
Time

Figure 9. Target Performance Chart

Forecasting
Project management is primarily concerned with decisions affecting the
future. Therefore, forecasting and prediction are extremely important
aspects of project management. EVM is
particularly useful in forecasting the
cost and time of the project at completion, based on actual performance up
to any given point in the project.
Forecasting of Cost at Completion
The EAC may also be called cost estimate at completion (CEAC). The estimated cost to complete the remainder
of the project is usually called the estimate to complete (ETC). Both can be
developed using various cost estimating methods or calculated mathematically using EVM.
EACs may differ based on the
assumptions made about future performance. The PMBOK Guide (Project
Management Institute, 2000) provides
three such estimates, based on three
different assumptions. In this section,
these estimates are reviewed, simplified and enhanced. They are given a
sequential subscript to differentiate
among them.
When current analysis shows that
the assumptions underlying the original estimate are flawed, or no longer
applicable due to changed conditions

16 Project Management Journal December 2003

affecting the activity, work package, or


project, a new ETC needs to be developed; EAC1 is the sum of the cumulative AC plus the ETC. As a formula,
EAC1 = AC + ETC. For the example
project used in this paper, EAC1 =
$60,000 + ETC. This applies where
ETC is developed for the remaining
work. EAC1 may also be called the
revised cost estimate (RCE), latest
revised estimate (LRE), or current
working estimate (CWE).
Using the above assumption, the
ETC for the remainder of the activity,
work package, or project usually is
developed using various cost estimating methods. Because the work already
is in progress, a detailed, bottom-up
cost estimate for the remaining work is
common in this case.
When current analysis shows that
past performance is not a good predictor of future performance, that problems or opportunities which affected
performance in the past will not occur
in the future, and that future performance will parallel the original plan, the
EAC2 is the sum of the cumulative AC
plus the original budget for the
remaining work (BAC EV): EAC2 =
AC + BAC EV. For the above project,
EAC2 = $60,000 + $100,000 $40,000
= $120,000.
The above formula can be simplified as follows:
EAC2 = AC + BAC EV
= BAC + (AC EV)
= BAC (EV AC)
= BAC CV
Thus:
EAC2 = BAC CV
The definition of EAC2 can therefore be simplified to equal the original
baseline BAC minus the CV. For the
above project, EAC2 = $100,000 ($20,000) = $100,000 + $20,000 =
$120,000.
Using the above assumption, the
ETC for the remainder of the activity,
work package, or project is the original
budget for the remaining work (BAC
EV).
When current analysis shows that
past performance is a good predictor
of future performance, that performance to date will continue into the
future, and that efficiencies or ineffi-

ciencies observed to date will prevail to


completion, the EAC3 is the sum of
the cumulative AC plus the original
budget for the remaining work (BAC
EV), modified by a performance factor,
which is usually the cumulative CPI.
As a formula, EAC3 = AC + (BAC EV)
/ CPI. For the above project:
EAC3 = $60,000 + ($100,000
$40,000) / 0.67
= $60,000 + $60,000 / 0.67
= $60,000 + $90,000
= $150,000
The above formula can be
simplified as follows:
EAC3 = AC + (BAC EV) / CPI
= AC + BAC / CPI EV / CPI
= AC + BAC / CPI AC
= BAC / CPI
Thus:
EAC3 = BAC / CPI
The definition of EAC3 can therefore be simplified to equal the original
BAC divided by the CPI. For the above
project, EAC3 = $100,000 / 0.67 =
$150,000. EAC3 may also be called the
statistical estimate at completion
(EACstat), the mathematical estimate at
completion (EACmath), or simply the
cost at completion (CAC).
Using the above assumption, the
estimated cost to complete the remainder of the activity, work package, or
project is the original budget for the
remaining work divided by the CPI. As
a formula, ETC = (BAC EV) / CPI.
This may be called statistical estimate
to complete (ETCstat) or the mathematical
estimate
to
complete
(ETCmath).
A graph of the EAC over time
provides a valuable indicator of
trends in project cost performance
and the impact of any corrective
actions. This graph can be particularly effective in project reviews. Figure
10 shows a graph of EAC for the
example project used in this paper,
using the above assumption.
Additional Forecasts of Cost
at Completion
Other assumptions can be made about
future performance and may result in
different estimates at completion. In
this section, other assumptions and
the resulting EACs are presented. They

11/6/03

160

EAC ($000)

140
120

9:20 AM

Page 17

EAC
Poor
BAC

100
80

Good

60

Time

Figure 10. EAC Graph

are given a continuing sequential subscript to differentiate among them.


In some organizations, it is common to state that the activity, work
package, or project will meet the original targets upon completion, regardless of prior performance. This
frequently occurs early in the project
when prior performance has been
poor. The EAC4 would be the original
baseline BAC. As a formula, EAC4 =
BAC. Statements such as the following
may be heard: We had some mobilization problems, but we took care of
them. We expect the project to finish
on schedule and on budget. or The
original specs were unclear. So we
took additional time to clarify them.
We are planning to meet project targets at this time.
The above statements should be
challenged firmly, with a response
such as: What we hear you say is that
future performance will be so much
better than the original plan and will
make up for prior cost overruns (and
delays). So far, we have not performed
to the original plan and would like to
know how this superior performance
will be achieved.
EAC 4
is
rarely
achieved.
Unmanaged projects do not fix themselves. They only tend to overrun
their budgets, fall behind their schedules, and often miss other scope and
quality targets.
Heinze (1996) provides the following additional formula for calculating
the EAC: EAC = BAC / CPI x SPI.
Fleming & Koppelman (2000) provide
a similar formula and support it by
indicating that there is a human tendency to get back on schedule, even if
that requires more resources for the
same work. The above formula may be
mathematically questionable. However,

it acknowledges that cost management


and schedule management are inseparable (Kerzner, 2001). As examples:
Project schedules can be crashed at an
additional cost, or less skilled
resources may be used on the project,
which may reduce the cost and possibly extend the duration.
The assumption implied by the
above formula is that if the activity,
work package, or project were behind
schedule, additional cost would be
incurred to bring the project back on
schedule, through the use of overtime,
additional resources, expediting shipments, and similar actions. On the
other hand, if the activity, work package, or project were ahead of schedule,
opportunities for significant cost savings may be pursued, although they
may require more time as a result of
using resources that are fewer in number, less experienced, and/or less
skilled. Additional time may also be
required to find better prices for equipment and material, negotiate better
contract terms, use more economical
shipping methods, or take similar
actions. This formula may provide a
better indication of estimated cost at
completion, when adherence to a
schedule is critical to the organization.
Using the earlier definition of CR
= CPI x SPI, and further defining EAC5
or EACs as the EAC adjusted for schedule performance, the above formula
can be restated as follows: EAC5 =
EACs = BAC / CR. For the above project, EAC5 = EACs = $100,000 / 0.53 =
$187,500.
Using the above assumption, the
ETC for the remainder of the activity,
work package, or project is the original
budget for the remaining work divided
by the CR: (BAC EV) / CR. This may
be called the ETC adjusted for schedule
performance (ETCs). A graph of the
EACs over time provides a valuable
indicator of trends in project cost performance and the impact of any corrective actions. This graph can be very
effective in project reviews. Figure 11
shows a graph of EACs for the example
project used in this paper, using the
above assumption.
A case that is not often mentioned
occurs when the EAC6 is substantially

higher than the original baseline BAC.


As a formula, EAC6 >> BAC. This estimate is generally not quantified, but is
referred to by project team members
with statements such as: If you think
this is bad, wait till you see the next
report! You aint seen nothing yet! or
The cost is going sky high. If this
project ever finishes, it would be a
miracle!
This case may result from delaying
corrective action and believing for too
long that the actual cost at completion
somehow would end up close to the
original baseline BAC, regardless of
prior poor performance. Higher costs,
lower levels of accomplishment, and
inefficient spending patterns become
practically irreversible and the projects
fate is sealed. Statistics of challenged
and failed projects testify that this case
is much more common than we would
like to believe.
EACs
160
140

EACs ($000)

PMI-002 11/5

120

Poor
BAC

100
80

Good

60

Time

Figure 11. EACs Graph

The Standish Group conducted


surveys and interviews to explore what
causes information technology (IT)
software development projects to be
challenged and why these projects fail.
These studies classified projects into
three types:
Successful: The project is completed on time and on budget, with all features and functions as originally
specified;
Challenged: The project is completed and operational but is over
budget, beyond the time estimate, and
offers fewer features and functions
than initially specified;
Failed: The project is canceled
before completion.
The Standish Group study conducted in 1994 and published in 1995
(The Standish Group, 1995) had a
total sample of 365 respondents repre-

December 2003 Project Management Journal 17

11/6/03

9:20 AM

Page 18

senting 8,380 projects. The results of


that research showed that 16% of IT
projects were successful, 53% were
challenged,
and
31%
failed.
Comparisons to subsequent studies
are shown in Table 2 (The Standish
Group, 1999):
Year of Study

Successful

Challenged

Failed

1994

16%

53%

31%

1996

27%

33%

40%

1998

26%

46%

28%

Table 2. Project Resolution HIstory

The Treasury Board of Canada


Secretariat (20002002) supported
findings of The Standish Group, indicated similarities to results of reviews
of Canadian government IT projects
and presented a framework for the
management of these projects.
A survey of IT projects by Sauer
and Cuthbertson (2002) covered various industry sectors and government
in the United Kingdom, and had a
usable sample size of 565 projects. It
showed that 5% of all projects were
reported to have been abandoned
prior to or during implementation,
55% of projects exceeded budget, 27%
came in exactly on budget, and 8%
came in below budget. Performance,
measured by attainment of initially
agreed upon specifications, averaged
above 80%. Across the whole sample,
56% delivered 90% to 99% of the
specifications, approximately 20% of
projects delivered less than 80% of the
specifications, and a sprinkling of projects exceeded the specifications.
Variance at Completion:
The variance at completion (VAC)
gives an indication of the estimated
cost underrun or overrun at the completion of the project. As a formula,
VAC = BAC EAC. For the above project, using BAC = 100,000 and EAC3 =
150,000, VAC = 100,000 150,000 =
-50,000.
In the above equation, 0 indicates that the project is forecasted to
be completed on budget. A positive
value indicates a forecasted underrun. A negative value indicates a
forecasted overrun.

18 Project Management Journal December 2003

A graph of the VAC over time provides a valuable indicator of trends in


project cost performance and the
impact of any corrective actions. This
graph can be effective in project
reviews. Figure 12 shows a VAC graph
for the example project used in this
paper, using the above assumption.
Completion Time Forecasting
EVM has not been widely used to estimate the total time at completion,
total project duration, or schedule for
an activity, work package, or project
based on actual performance up to a
given point in the project. However,
using assumptions and logic similar to
those discussed above, the projects
time estimate at completion (TEAC)
and time variance at completion
(TVAC) can be calculated based on the
baseline schedule at completion (SAC)
and actual performance up to any
given point in the project (Anbari,
2001 and 2002).

40

VAC ($000)

PMI-002 11/5

Good

20
0
-20

Poor

-40

VAC
Time

Figure 12. VAC Graph

In this section, various time estimates are presented and given a


sequential subscript to differentiate
among them, following the same pattern used previously for the cost estimate at completion.
When current analysis shows that
assumptions underlying the original
time estimate were flawed or no longer
applicable due to changed conditions
affecting the activity, work package, or
project, a new schedule, duration estimate, or time estimate to complete
(TETC) needs to be developed, and the
TEAC1 is the sum of the cumulative AT
plus the TETC. As a formula, TEAC1 =
AT + TETC.
The example project used in this
paper has an original baseline SAC of
40 weeks, and its status date is 20

weeks, meaning that the cumulative AT


is 20 weeks. Therefore: TEAC1 = 20 +
TETC weeks. In this case, TETC needs
to be developed for the remaining
work. TEAC1 may also be called the
revised schedule or current schedule.
When current analysis shows that
past schedule performance is not a
good predictor of future schedule performance, that problems or opportunities
which
affected
schedule
performance in the past will not occur
in the future, and that future schedule
performance will parallel the original
plan, TEAC2 is the sum of the cumulative AT plus the original scheduled
time for the remaining work. This can
be simplified to the original baseline
SAC minus the TV (Fleming &
Koppelman, 2000). As a formula,
TEAC2 = SAC TV. For the above project, TEAC2 = 40 (-4) = 40 + 4 = 44
weeks.
The above is the total estimated
schedule duration that would have
been obtained using the critical path
method (CPM) or the program evaluation and review technique (PERT), if
the schedule slippage of four weeks
were on the critical path.
When current analysis shows that
past schedule performance is a good
predictor of future schedule performance, that performance to date will
continue into the future, and that
schedule efficiencies, or inefficiencies,
observed to date will prevail to completion, TEAC3 is the sum of the
cumulative AT plus the original scheduled time for the remaining work,
modified by the cumulative SPI. This
can be simplified to the original baseline SAC divided by the SPI. As a formula, TEAC3 = SAC / SPI. For the
above project, TEAC3 = 40 / 0.80 = 50
weeks.
The above example indicates that
the project is estimated to be completed 25% behind schedule: (40 weeks
50 weeks) / 40 weeks = -10 weeks / 40
weeks = -0.25 = -25%.
A graph of the TEAC over time
provides a valuable indicator of
trends in project schedule performance and the impact of any corrective
actions. This graph can be effective in
project reviews. Figure 13 shows a

11/6/03

9:20 AM

Page 19

graph of TEAC, for the example project used in this paper, using the above
assumption.

TEAC (Weeks)

52

TEAC

48
44

Poor
SAC

40
36

Good

32

Time

Figure 13. TEAC Graph

In some organizations, it is common to state that the activity, work


package, or project will be on schedule
upon completion, regardless of prior
performance. This frequently occurs
early in the project, when prior schedule performance has been poor. The
TEAC4 would be the original baseline
SAC. As a formula, TEAC4 = SAC.
Statements similar to those mentioned
earlier in the cost discussion may be
heard. In some disciplines, such as
software development, it is common
to conclude these statements saying,
Well catch up during the testing
phase! Several modifiers to the word
test have been developed, which may
increase the likelihood of catching up.
They include: alpha test, beta test, user
test, stress test, acceptance test, and
parallel test. Such statements should
be challenged firmly, with a response
similar to that mentioned earlier in the
cost discussion.
TEAC4 is rarely achieved. Again,
unmanaged projects do not fix themselves. They only tend to fall behind
their schedules, overrun their budgets,
and often miss other scope and quality
targets.
Recalling that cost performance
and schedule performance are inseparable, the assumption can be made
that if an activity, work package, or
project were running over budget,
additional time may be needed to
bring the project back on budget. This
may be accomplished by reducing
resources applied to the project, using
fewer paid resources, many of which
are less experienced and less skilled,
taking additional time to find better

prices for equipment and material,


negotiate better contract terms using
more economical shipping methods,
and similar actions. On the other
hand, if an activity, work package, or
project were running below budget,
opportunities for reducing completion
time, reducing cycle time, and expediting time to market may be pursued,
although they may incur more cost.
This may be accomplished through the
use of overtime, additional resources,
and expediting shipments.
Defining TEAC5 or TEACc as the
TEAC adjusted for cost performance,
the following formula would reflect
the above assumption: TEAC5 =
TEACc = SAC / CR. For the above project, TEAC5 = TEACc = 40 / 0.53 = 75
weeks. This formula may provide a better indication of estimated time at
completion, when adherence to budget is critical to the organization. TEAC5
may also be called the time estimate at
completion adjusted for cost performance (TEACc).
A graph of TEACc over time provides a valuable indicator of trends in
project schedule performance and the
impact of any corrective actions. This
graph can be very effective in project
reviews. Figure 14 shows a graph of
TEACc, for the example project used
in this paper, using the above
assumption.
A case that is not mentioned
often occurs when the TEAC6 is substantially higher than the original
baseline SAC. As a formula, TEAC6 >>
SAC. This estimate is generally not
quantified, but is referred to by project team members with statements
similar to those mentioned earlier in
the cost discussion. At times, this case
occurs in the later phases of a project,
when team members have no other
planned assignments, and the organization is right sizing. Quality problems
become
apparent,
and
additional time is requested to fix various problems. Sometimes a lot of
additional time is needed.
Again, this case may result from
delaying corrective action and believing for too long that the project would
somehow be completed close to the
original baseline schedule, regardless

of prior poor performance. Longer


durations, lower levels of accomplishment, and inefficient schedule achievement patterns become practically
irreversible, and the projects fate is
sealed. Statistics of challenged and
failed projects testify that this case is
much more common than we would
like to believe, as previously discussed
in the development of EAC6.
70

TEACc (Weeks)

PMI-002 11/5

TEACc

60
50

Poor
SAC

40
30

Good

20

Time

Figure 14. TEACc Graph

Time variance at completion: The


TVAC gives an indication of the estimated amount of time that the project
will be completed ahead or behind
schedule: TVAC = SAC TEAC. For the
above project, using SAC = 40 and
TEAC3 = 50: TVAC = 40 50 = -10
weeks.
In the above equation, 0 indicates
that the project is expected to be completed on schedule. A positive value
indicates that the project is expected to
be completed ahead of schedule. A
negative value indicates that the project is expected to be completed behind
schedule.
A graph of TVAC over time provides a valuable indicator of trends
in project schedule performance and
the impact of any corrective actions.
This graph can be effective in project
reviews. Figure 15 shows a graph of
TVAC, for the example project used
in this paper, using the above
assumption.
CPM, PERT, and EVM
As mentioned above in the development of TEAC2, an underlying
assumption of the CPM and the PERT
is that future performance will parallel
the original plan, unless changes are
made to the original plan time, logic,
or cost.
The example project used in this

December 2003 Project Management Journal 19

PMI-002 11/5

11/6/03

9:20 AM

Page 20

TVAC (Weeks)

paper has an original baseline SAC of


40 weeks. With a status date of 20
weeks, TV = -4 weeks. If TV represented
a schedule slippage of 4 weeks on the
critical path, CPM and PERT would estimate a completion time of 44 weeks.
This is the same as: TEAC2 = SAC TV
= 40 (-4) = 40 + 4 = 44 weeks.

10

Good

5
0

Poor

-5
-10

TVAC
Time

Figure 15. TVAC Graph

CPM and PERT initially assume


that problems or opportunities that
affected performance in the past will
not occur in the future and that past
performance is not a good predictor of
future performance.
The assumption generally associated with EVM is that past performance is a good predictor of future
performance, that performance to date
will continue into the future, and that
efficiencies or inefficiencies observed
to date will prevail to completion.
Therefore, the EAC3 is generally associated with EVM. Similarly, the TEAC3
can be associated with EVM.
Therefore: TEAC3 = SAC / SPI = 40 /
0.80 = 50 weeks.
Which of the above forecasts will
materialize depends greatly on decisions and actions taken by the project
manager, the project team, and the
organization. Some like to add luck to
the factors affecting project outcomes.
Others observe that good luck tends to
be directly associated with better planning and better decisions.
Project Forecasting
It is advisable to ask work package
managers, project leaders, and functional managers to review cost and
schedule mathematical forecasts and
to provide their own subjective forecasts for their own work areas in
advance of issuing project performance
reports and conducting project review

20 Project Management Journal December 2003

meetings. Both mathematical forecasts


and subjective forecasts would be
included in project performance
reports. This effort highlights performance deviations for work area managers, encourages them to consider
appropriate, timely actions, and incorporates their close, detailed knowledge
of performance in their areas, which
may not be evident from the reported
values. At a minimum, this effort may
help avoid surprises and arguments
over the numbers during project
review meetings.
Forecasting in project management may well be a self-defeating
prophecy, and that may be good for
the organization. Large deviations usually attract managements attention
and result in corrective action. Small
deviations are usually left alone. By
quantifying and highlighting such
deviations, EVM helps focus managements interest on projects or work
packages that need the most attention.
As a result, EVM supports effective
management of projects and work
packages collectively and enhances
management of the enterprises project
portfolio (Anbari, 1983). Forecasting
using these techniques provides a uniform approach to project reviews,
building confidence in the project outcome as time progresses. Changing
project evaluation methods during the
project duration can result in no
meaningful data for decision-making.
Further Extensions, Issues
and Applications
Extensions
Using the above definitions, the following is derived (Slemaker, 1985):
% Complete = EV / BAC
% Spent = AC / BAC
Taking the ratio of the above two
formulas
(Anbari, 1980):
% Complete / % Spent
= (EV / BAC) / (AC / BAC)
= EV / AC
= CPI
Thus:
CPI = % Complete / % Spent
For the example project used in
this paper:

% Complete = $40,000 / $100,000


= 0.40 = 40%
% Spent = $60,000 / $100,000
= 0.60 = 60%
CPI = % Complete / % Spent
= 40 / 60 = 0.67
The above allows a further
simplification
(Slemaker, 1985) of the EAC3:
EAC3 = BAC / CPI
= BAC / (% Complete /
% Spent)
= (BAC x % Spent) /
% Complete
= AC / % Complete
Thus: EAC3 = AC / % Complete
The definition of EAC3 can be further simplified to the AC divided by
the percent complete. For the above
project, EAC3 = $60,000 / 0.40 =
$150,000.
Similarly, the TEAC3 can be simplified to: TEAC3 = AT / % Complete.
The example project used in this paper
has an original baseline SAC of 40
weeks, and the status date is 20 weeks,
which means that the cumulative AT is
20 weeks. Therefore: TEAC3 = 20 / 0.40
= 50 weeks.
Similarly, the following is derived
(Anbari, 1980):
CPI = % Complete / % Spent
= (Actual Production /
Total Scope) /
(Actual Cost /
Total Budget)
= (Actual Production /
Total Scope) x
(Total Budget /
Actual Cost)
= (Total Budget /
Total Scope) x
(Actual Production /
Actual Cost)
= (Total Budget /
Total Scope) /
(Actual Cost /
Actual Production)
= Planned Unit Cost /
Actual Unit Cost
Thus: CPI = Planned Unit Cost /
Actual Unit Cost
The additional formulas developed in this section provide a more
intuitive understanding of CPI based
on information readily available in
many organizations. The first formula

PMI-002 11/5

11/6/03

9:20 AM

Page 21

for CPI uses information widely


known in project environments, and
the second formula for CPI uses information widely known in production
environments:
CPI = % Complete / % Spent
CPI = Planned Unit Cost /
Actual Unit Cost
Issues in the Determination of
Percent Complete
Determination of the percent complete
or proportion complete of an activity,
work package, or project is a necessary
but challenging task in many organizations. This task becomes even more
demanding when dealing with new,
emerging, or softer technology projects, such as telecommunications, software development, architectural or
engineering design, and research and
development.
Alternatives to using the percent
complete to determine physical
accomplishments have been used. The
50/50 rule specifies that 50% of an
items budget is recorded at the time
that the work is scheduled to begin,
and the remaining 50% is recorded
when the work is scheduled to be completed. If the project had a large number of items, the distortion from the
50/50 rule would be minimal
(Kerzner, 2001), because these items
would be at various stages of completion. This allows us to calculate PV.
Similarly, to calculate EV, 50% of an
items budget is recorded when the
work begins, and the remaining 50% is
recorded when the work is completed.
To make the 50/50 rule work successfully, the project should be broken
down into very detailed, short-span
work
packages
(Fleming
&
Koppelman, 2000).
The 50/50 rule is a common practice in a number of contractual
arrangements, such as those for home
repair. Half of the contract price is
paid up front, and the remaining balance is paid upon completion of the
work. It should be noted that when
the 50/50 rule is used in a contractual
arrangement and the contractor is
paid based on this rule, it is reasonable to expect that the contractor will
tend to start as many items as possi-

ble, collecting 50% of the contract


price for each of these items.
The 0/100 rule can also be used.
This rule specifies that the value is
earned only when the item is completed and is usually used in work packages having a short duration (Kerzner,
2001). This rule can also be called the
weighted milestone method, where the
value is earned only when the milestone is physically completed, and one
or more milestones are planned in
each performance-reporting period
(Fleming & Koppelman, 2000).
Contractors may consider the 0/100
rule harsh. When a contractor is paid
based on this rule, it is reasonable to
expect that the contractor will strive to
have a very detailed WBS that breaks
the project down to as many items as
possible, so that completion of item(s)
can be shown regularly and payment
can be authorized.
Other alternatives for determining
physical accomplishments can be
used. For example, the 10/90 rule,
20/80 rule, and 25/75 rule acknowledge that to start a work package, a certain amount of preparation and
mobilization are needed. Therefore,
10%, 20%, or 25% of the value would
be considered earned when the work is
started, and the remaining amount
would be earned when the work is
completed. If the work package were
front-end loaded, as might be the case
with certain equipment acquisitions,
then the inverse of these rules might be
appropriate. For example, the 75/25
rule might specify that 75% of the
value would be considered earned
when the equipment is delivered, and
the remaining amount is earned when
installation, testing, and commissioning are completed.
The percent complete method can
be used with a buffer that sets a ceiling
of about 80% or 90% upon reported
completion. A work package may earn
only up to the specified percent ceiling
based on subjective estimates. When
the work package is 100% complete,
the balance is earned. A variation of
this approach is using a combination
of the percent complete and a milestone gate. A work package may earn
only up to a maximum specified per-

centage of the value associated with


the milestone based on subjective estimates. When the predefined, tangible
criteria for the milestone are met, the
balance of the value associated with
the milestone is earned (Fleming &
Koppelman, 2000). These approaches
may help alleviate the 95% complete
and stays there forever syndrome.
For level of effort items such as
project management, customer support, and other support work during a
given period of time in a project, the
effort itself is the end product.
Therefore, the earned value can be considered to be equal to the effort
applied or the actual cost.
Applications
EVM provides project managers and
the organization with triggers or early
warning signals that allow them to take
timely actions in response to indicators
of poor performance and enhance the
opportunities for project success. Such
indicators have been found to be reliable as early as 15% into a project.
Better planning and resource allocation
associated with the early periods of a
project might be the cause of this reliability (Fleming & Koppelman, 2000).
EVM can be used for progress payments to contractors based on the EV
of contracted or outsourced work.
Because such contractual arrangements
create legal and financial obligations, it
is important to consider the method
specified for evaluating progress. The
previously discussed alternatives for
determination of percent complete
should be carefully considered and
negotiated to achieve a fair and equitable environment that encourages successful accomplishment of contracted
or outsourced project items.
For long-term projects, it may be
appropriate to consider incorporating
the time value of money and time-discounted cash flows into EVM. Inflation
can be explicitly considered in EVM,
and the inflation variance (IV) can be
calculated (Farid & Karshenas, 1988).
However, these considerations add
complexity to the method and may be
justifiable only for very long-term projects or in very high inflation periods or
economies.

December 2003 Project Management Journal 21

PMI-002 11/5

11/6/03

9:20 AM

Page 22

An organization may elect to


apply EVM uniformly to all of its projects, or only to projects exceeding its
own thresholds for cost and schedule
reporting and control. EVM can be
applied to projects of various types and
sizes in the public and private sectors.
It can be applied at various levels of a
projects WBS and to various cost components, such as labor, material and
subcontractors.
Comprehensive Example
A project has a baseline BAC of
$100,000 and a baseline SAC of 40
weeks. The baseline indicates that by
the end of week 20, the project is
planned to be 50% complete. At the
end of week 20, it is reported that 40%
of the project work has been completed at a cost of $60,000. Using the EVM
method:
BAC = $100,000
SAC = 40 weeks
PV = 50% x $100,000
= $50,000
AC = $60,000
EV = 40% x $100,000
= $40,000
AT = 20 weeks
Therefore:
% Complete = EV / BAC
= $40,000 / $100,000 = 40%
% Spent = AC / BAC = $60,000 /
$100,000 = 60%
CV = EV AC = $40,000
$60,000 = -$20,000
SV = EV PV = $40,000
$50,000 = -$10,000
PV Rate = BAC / SAC = $100,000 /
40 weeks = $2,500 per week
TV = SV / PV Rate = - $10,000 /
$2,500 per week = -4 weeks
CPI = EV / AC = $40,000 /
$60,000 = 0.67
CPI = % Complete /
% Spent = 40% / 60% = 0.67
SPI = EV / PV = $40,000 /
$50,000 = 0.80
CR = CPI x SPI = 0.67 x 0.80
= 0.53
EAC3 = BAC / CPI = $100,000 /

22 Project Management Journal December 2003

0.67 = $150,000
EAC3 = AC / % Complete = 60,000 /
0.40 = $150,000
VAC = BAC - EAC = $100,000 $150,000 = -$50,000
EAC5 = EACs = BAC / CR = $100,000/
0.53 = $187,500
TEAC3 = SAC / SPI = 40 weeks /
0.80 = 50 weeks
TEAC3 = AT / % Complete = 20 /
0.40 = 50 weeks
TVAC = SAC TEAC = 40 weeks
50 weeks = -10 weeks
Conclusion
EVM helps focus managements interest on projects that need most attention and may aid the prioritization and
emphasis management gives projects
within a portfolio, enhancing the
enterprises project portfolio management. EVM provides important information for project or work package
decision-making. Its wider acceptance
and effectiveness may depend on better understanding of its capabilities.
Simplification of EVM calculations,
use of graphical tools to enhance
understanding of performance trends,
and successful application of EVM in
industry are important factors for the
growth and effective use of this valuable method in project management.
References
Anbari, F.T. (1980). An Operating
Management Control System for Large
Scale Projects. Unpublished paper presented at The Decision Sciences Institute
Ninth Annual Meeting, Northeast
Regional Conference, Philadelphia, PA.
Sponsored by the Northeast Decision
Sciences Institute.
Anbari, F.T. (1983). An Operating
System for Forecasting Project Cost at
Completion. Unpublished paper presented at The Third International
Symposium on Forecasting, Philadelphia,
PA. Abstract in Program sponsored by
The International Institute of
Forecasters in collaboration with the
Wharton School, University of
Pennsylvania, Philadelphia, PA.
Anbari, F. T. (2001). Applications
and Extensions of the Earned Value

Analysis
Method
[CD-ROM].
Proceedings of the Project Management
Institute 2001 Seminars & Symposium,
November 1-10, 2001, Nashville, TN,
USA. Newtown Square, PA: Project
Management Institute.
Anbari, F.T. (2002). Quantitative
Methods for Project Management, Second
Edition. New York, NY: International
Institute for Learning.
Barr, Z. (1996). Earned Value
Analysis: A Case Study. PM Network, X
(12), 31-37.
Cioffi, D. F. (2002). Managing
Project Integration. Vienna, VA:
Management Concepts.
Cleland, D.I., & King, W.R.
(Editors). (1988). Project Management
Handbook, (2nd. Ed.). New York, NY:
Van Nostrand Reinhold.
Egan, Jr., D.S. (1982). The
Performance Index: Combining Cost
and Production Data to Show How
Good (or Bad) Your Project Really Is!!
Proceedings of the 7. Internet World
Congress on Project Management, 1982,
Copenhagen, Denmark, PROJEKTPLAN,
The
Danish
Project
Management Society, The Danish
Technical Press, Denmark, 355-364.
Farid, F., & Karshenas, S.
(November, 1988). Cost/Schedule
Control Systems Criteria Under
Inflation. Project Management Journal,
XIX (5), 23-29.
Fleming, Q.W., & Koppelman, J.M.
(2000).
Earned
Value
Project
Management, (2nd Ed.). Newtown
Square, PA: Project Management
Institute.
Heinze,
K.
(1996).
Cost
Management of Capital Projects. New
York: Marcel Dekker, Inc.
Kerzner, H. (2001). Project
Management: A Systems Approach to
Planning, Scheduling, and Controlling,
(7th Ed.). New York, NY: John Wiley &
Sons.
Kim, E.H. (2000). A Study on the
Effective Implementation of Earned Value
Management Methodology, Unpublished
doctoral dissertation. The George
Washington University, Washington,
DC.
Lewis, J.P. (2001). Project Planning,
Scheduling, & Control: A Hands-On
Guide to Bringing Projects In On Time

PMI-002 11/5

11/6/03

9:20 AM

Page 23

and On Budget, (3rd Ed.). New York,


NY: McGraw-Hill.
Meredith, J.R., & Mantel, Jr., S. J.
(2000). Project
Management:
A
Managerial Approach, (4th Ed.). New
York, NY: John Wiley & Sons.
Project Management Institute
(PMI). (2000). A Guide to the Project
Management Body of Knowledge.
Newtown
Square,
PA:
Project
Management Institute.
Slemaker, M.S. (1985). The
Principles and Practice of Cost/Schedule

Control Systems. Princeton, NJ: Petrocelli


Books.
Sauer, C., & Cuthbertson, C.
(2002). UK project management is
healthier
than
supposed,
CW360.com
survey
suggests.
Retrieved June 29, 2003, from
www.cw360ms.com/pmsurveyresults/index.asp#
The Standish Group. (1999).
Chaos: A Recipe for Success.
Retrieved June 29, 2003, from
www.standishgroup.com/sample_re

search/PDFpages/chaos1998.pdf.
The Standish Group. (1994). The
Chaos Report. Retrieved June 29, 2003,
from www.standishgroup.com/sample_research/chaos_1994_1.php.
Treasury Board of Canada
Secretariat. (2000-2002). About the
Enhanced Management Framework.
Retrieved on June 29, 2003, from
www.cio-dpi.gc.ca/emf-cag/about/abuans01_e.asp.
Webster, J.S. (2002). Meaningful
Metrics. PM Network, 16 (11), 34-39.

FRANK T. ANBARI, is a faculty member of the Project Management Program at The George Washington
University. He has taught in the graduate programs at Drexel University, Pennsylvania State University,
University of Texas at Dallas, and at the International Institute for Learning.
Dr. Anbari gained extensive industrial experience serving in project leadership positions at the National
Railroad Passenger Corporation (Amtrak), Day and Zimmermann, and American Water Works Service
Company. He served as examiner (1993-1995) and alumni examiner (1999-2000) for the Malcolm
Baldrige National Quality Award, as member of the Editorial Review Boards of Quality Management Journal
(1993-1998) and Project Management Journal (2000-Present), and as member of the Panel of Referees of
the International Journal of Project Management (2003-Present).

C A L L

F O R

P A P E R S

Project Management Journal solicits unpublished


papers in project management and allied fields.
The Editor of the Project Management Journal is actively seeking submissions
of previously unpublished research papers, commentaries, and dissertations
as related to all aspects of project management.
For more information on publishing in PMJ, please see the Notes for Authors published in
this issue of the journal, or access them from the PMI website at www.pmi.org.
Questions about submissions may be addressed to the PMJ Editor at
Natasha.pollard@pmi.org
or via mail to:
PMJ Editor
PMI Publishing Department
Four Campus Boulevard
Newtown Square, PA 19073

December 2003 Project Management Journal 23

PMI-002 11/5

11/6/03

9:20 AM

Page 24

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

A CRITICAL LOOK AT CRITICAL CHAIN


PROJECT MANAGEMENT
TZVI RAZ, Faculty of Management, Tel Aviv University, Ramat Aviv 69978, Israel
ROBERT BARNES, Consultant, The iE3 Group Ltd, 162 Chelsea View Drive,
Birkenhead, Auckland, New Zealand
DOV DVIR, School of Management, Ben Gurion University of the Negev, P.O.Box 653,
Beer Sheva 84105, Israel

ABSTRACT
Critical Chain Project Management
(CCPM) has emerged in the last few years
as a novel approach for managing projects. In this paper the authors analyze the
principles of CCPM, starting with a review
of its key elements: reduction of duration
estimates; buffer calculations; task completion notification; progress measurement; and priority setting. The authors
continue with a CCPM critical analysis
using evidence in the research literature
and in practice. The points addressed
include duration estimation practices,
project network structure, stability of the
critical chain, resource productivity under
multi-tasking, and the projects organizational and operational environment. The
place that CCPM occupies in the broader
project management context and the
costs associated with its adoption are
also considered. The authors conclusion
is that although CCPM has a number of
valuable concepts, it does not provide a
complete solution to project management
needs, and that organizations should be
very careful about the exclusion of conventional project management techniques.
Keywords: scheduling; critical chain

2003 by the Project Management Institute


Vol. 34, No. 4, 24-32, ISSN 8756-9728/03

24 Project Management Journal December 2003

Introduction
ritical Chain Project Management (CCPM), which was developed and publicized by Dr. Eliyahu M. Goldratt (1997) in his book Critical Chain, is a
novel approach for managing projects. Goldratt is well known in the operations management community as the inventor of the Theory of Constraints
(TOC). TOC is a tool for managing repetitive production systems based on the
principle that every system has a constraint, and system performance can only be
improved by enhancing the performance of the constraining resource. CCPM is
an extension of TOC designed specifically for project environments. In the original book, as well as in the writings of its proponents, e.g., Newbold (1998),
Simpson and Lynch (1999), Homer (1998), and Leach (1999), CCPM is presented as an alternative to the classical methods for project planning and control,
such as those contained in the management and engineering textbooks and those
in professional standards, such as PMIs A Guide to the Project Management Body of
Knowledge (PMBOK Guide).
The publication of Goldratts book generated some controversy in the project
management community (Globerson, 2000). CCPM proponents claim it is a
totally new, revolutionary way of thinking that can lead to superior performance
in terms of reducing delivery time and increasing the ability to meet schedule and
budget commitments. Others dismiss this as hype, arguing that experienced project managers have known the principles behind CCPM for decades, and CCPMs
uniqueness is in the terminology rather than in its substance.
In addition to departing from the commonly accepted practice of project
management, CCPM application requires the use of specialized software currently offered by a small number of vendors that are not necessarily the market leaders. As a result, any organization considering CCPM adoption as a way for
improving project performance faces significant costs, both in economic terms
and in changes to its culture and work procedures. Consequently, a careful evaluation and assessment of CCPM and its potential to bring about significant and
sustainable performance improvements is in order.
The purpose of this paper is to provide some guidance to organizations considering CCPM as an addition or a substitute to their current project management
practices. The paper is organized as follows. The authors begin with a brief
overview of CCPM and a discussion of its key concepts and techniques. This is followed by a critical examination of the assumptions behind CCPM that considers

PMI-002 11/5

11/6/03

9:20 AM

Page 25

relevant results from the published research literature and


from the authors own consulting practices. Next, the
authors examine the place CCPM occupies in the PMBOK
Guide and conclude with an assessment of the benefits and
limitations of CCPM.
An Overview of the CCPM Method
CCPMs starting point is a list of tasks along with their duration estimates and dependencies. The first step consists of
developing an initial schedule for project tasks. This is done
while taking into account the dependencies among the tasks
(as reflected in the project network) and the availability of
resources. Because at least some of the resources have limited availability, the resulting schedule is likely to be longer
than the schedule obtained with the basic Critical Path
Method algorithm, as critical activities are delayed while
waiting for the resources they require.
At this point, CCPM identifies the critical chain as the
set of tasks that results in the longest path to project completion after resource leveling. The critical chain yields the
expected project completion date. Resources required by the
tasks on the critical chain are defined as critical resources. So
far, CCPM is the same as conventional project management
except for the terminology critical chain, which would
otherwise be called the leveled critical path. The next step
in CCPM planning consists of recalculating the project
schedule based on shortened task duration estimates. The
rationale for shortening the original duration estimates is as
follows:
All tasks in the project are subject to some degree of
uncertainty;
When asked to provide an estimate of the duration, the
task owner adds a safety margin in order to be almost
certain of completing the task on time. This means that,
in general, task durations are overestimated;
In most cases, the task will not require the entire
amount of safety margin and should be completed
sooner than scheduled;
Because the safety margin is internal to the task, if it is
not needed, it is wasted. The resources for the next
task are not available until the scheduled time.
Therefore, when it becomes obvious that the buffer is
unnecessary, the task owner will use the buffer time
anyway, because there is little incentive to finish early.
On the other hand, any delays in the completion of
tasks on the critical chain propagate to the successor
tasks. Thus, gains are lost, delays are passed on in full,
and the project is likely to finish late even if, on average, there are enough buffers hidden in the tasks.
CCPM states that original duration estimates are such
that the likelihood of completion is 95%, and they should
be reduced to the point where the likelihood of completion
is 50%. The difference between the project duration based
on new estimates and the original project duration is called
the project buffer and should be displayed on the project
Gantt chart as a separate task. Figure 1 illustrates the rela-

Conventional Project Schedule


Task suffers are hidden
with in individual tasks

Job 1
Job 2

Job 3
CCPM Schedule

Job 4
Buffers are pooled,
and made explicit

Figure 1. Conventional Schedule and CCPM Schedule With Time Buffers


Shown Explicitly

tionships between the original schedule and the CCPM


schedule based on the shortened task durations.
The buffers, which were previously hidden in each task,
have been made explicit and pooled. This pooled buffer is
called the project buffer. Note that by calculating the project
buffer, the total duration of the project did not increase.
Under CCPM, the project buffer is considered part of the
project and, as such, must be scheduled and assigned
resources. A Gantt chart showing the project buffer serves to
communicate the inherent uncertainty in the project as
opposed to a conventional Gantt chart that presents a spurious air of certainty.
It is improbable that all the critical chain tasks will
exceed their 50% likelihood duration estimates. Under the
assumption of statistical independence, about half the tasks
will exceed the 50% mark, while the other half will be completed at less than 50%. By pooling together the safety margins of the individual tasks, the protection against
uncertainty is improved, so CCPM suggests that the combined project buffer can be less than the sum of the safety
margins of the individual tasks. This argument is supported
by statistical theory that states that the standard deviation of
the sum of a number of mutually independent random variables (in this case, the actual durations of the tasks on the
path) is less than the sum of the individual standard deviations. Although the assumption of statistical independence
of task durations is questionable, this justifies reducing the
overall duration of the project. In practice, it may be easier
to gain task owners acceptance of pooling their individual
task buffers if the total is not reduced.
The same process of making safety margins explicit and
pooling them can be applied to noncritical paths. As before,
the safety margin in each task is identified, taken out, and
pooled at the end of the path. Because this buffer is placed
where the path feeds back into the critical chain path, it is
called a feeding buffer. Figure 2 shows a simple project network where the feeding buffer has been identified. Note that
noncritical paths still can have slack, as well as a buffer.

December 2003 Project Management Journal 25

PMI-002 11/5

11/6/03

9:20 AM

Page 26

Project Buffer

Date 1

Date 2

Feeding Buffer
Figure 2. Project Network With Feeding Buffer

According to CCPM, a feeding buffer represents the


extent of the critical chains protection against the uncertainty in the feeding noncritical chain, and its size may be
adjusted as desired. Once the size of the feeding buffer has
been determined, if there is still some slack on the feeding
chain, CCPM prescribes that the task be scheduled as late as
possible. This is justified on the basis that it reduces waste of
time and work in process on the noncritical tasks while preserving the desired degree of protection of the critical chain.
The third type of buffer used by CCPM is called a
resource buffer, which is a virtual task inserted prior to critical chain tasks that require critical resources. Its purpose is
to issue a signal to the critical resource that a critical chain
task to which they are assigned is due to start shortly.
According to CCPM, this wake-up call will cause the critical
resource to wrap up any noncritical work and be ready to
start work on the critical chain task as soon as its predecessors are completed. The resource buffer does not actually
consume any resource, and it adds neither time nor cost to
the project.
At this point, CCPM has created a new project schedule,
which consists of the original tasks with reduced durations
and various types of buffers: the project buffer, the feeding
buffer and the resource buffer.
For project plan execution, CCPM prescribes the
following principles:
Resources working on critical chain tasks are expected to
work continuously on a single task at a time. They do not
work on several tasks in parallel or suspend their critical
tasks to do other work;
Resources are to complete the task assigned as soon as possible, regardless of scheduled dates;
If the task is completed ahead of schedule, work on its successor is to begin immediately. If the task successor utilizes
a critical resource for which a resource buffer has been
defined, advance warning is provided to that resource at
the point in time where the resource buffer begins;

26 Project Management Journal December 2003

If the task is completed past its planned completion


date, as shown on the CCPM schedule, this is no reason for immediate concern, as the buffer will absorb
the delay.
As progress is reported, the CCPM schedule is recalculated, keeping the final due date of the project constant by
adjusting buffer sizes. Project control focuses on consumption of the buffer. Out of proportion buffer consumption is
a clear indication for implementing corrective actions, such
as reassignment of resources to the tasks on the chains leading to the buffer in question. In this manner, the extent of
buffer utilization serves to monitor the likelihood of project
completion by its committed due date.
CCPM also provides some guidelines for managing
multiple projects sharing a common pool of resources.
While scheduling the various projects, CCPM suggests that
we first identify the resource whose availability constrains
the system (the drum, according to TOC terminology) and
then schedule the projects around it. During execution, if a
given resource is required to work simultaneously on several tasks, CCPM prescribes that priority should be given to
the task of the one project that is in the greatest risk of missing its committed date, as measured by the remaining fraction of project buffer. Of course, working concurrently on
tasks that belong to different projects is not allowed.
CCPM Critique
In this part of the paper the authors consider the main elements of CCPM and analyze them in terms of the validity of
the underlying assumptions and the availability of supporting empirical evidence.
Task Duration and Safety Margins
CCPM assumes that all task owners overestimate task duration by a certain safety factor, and that the duration of the
actual execution of each task will expand to fill the time
allotted. In other words, actual task duration is a self-fulfill-

PMI-002 11/5

11/6/03

9:20 AM

Page 27

ing prophecy. These two assumptions are plausible, but


CCPM theorists fail to provide any supporting scientific evidence. In fact, a recent study of task duration estimation in
software development by Hill, Thomas, and Allen (2000)
provides some contradictory results. The study analyzed
estimated and actual durations of more than 500 tasks carried out by the information systems development department of a major international financial organization. Only
in 8% of the tasks was the actual duration equal to the estimated duration, while in about 60% of the tasks the actual
duration was less than the estimated duration. These findings, in effect, contradict the assumption that task owners
use up all allocated time. Further, in 32% of the tasks, the
actual duration exceeded the estimate, indicating that the
safety factor, if it existed at all, was certainly not sufficient for
the 95% confidence level.
However, let us leave aside the contradictory evidence
and proceed under CCPM assumptions. There are still two
important issues that CCPM does not address satisfactorily.
The first issue is how does the project manager determine
the safety factor that the task owner presumably built into
the duration estimate. The only way for obtaining the correct answer is to have another method for estimating task
durations that provides an accurate estimate and to subtract
that estimate from the one provided by the task owner. Of
course, if such a method is available, it should have been
used in the first place, and the issue remains. CCPM suggests reducing the estimates by a certain percentage, typically 33%. Such an approach is problematic, not only due
to the need to justify the percentage reduction chosen, but
also due to the fact that not all people overestimate by the
same amount. There are bound to be variations based on
personality, job experience, nature of the task, workload, or
other reasons.
Even if project managers are willing to accept that there

is an appropriate formula to reduce duration estimates provided by task owners, the second issue still remains: Will
they agree to shorten their duration estimates and merge
their individual safety factors into the project and feeding
buffers? Imposing shortened duration estimates on task
owners will reduce their commitment to the estimates. In
addition, the knowledge that their estimates will be reduced
is likely to encourage task owners to add larger margins so
they still have the safety margin they prefer after the correction,. At any rate, the behavioral aspects of identifying the
precise amount of safety margin and taking it away from the
task owner are dealt with only superficially by CCPM literature and still require empirical support.
Use of Buffers in Planning and Control
The various types of buffers play a key role in CCPM theory.
In principle, the size of the project buffer should reflect the
amount of protection required against the uncertainty of the
sum of the durations of the tasks on the critical chain, while
the sizes of the feeding buffers should reflect the amount of
protection appropriate for the feeding chains. In order to
contribute to the reduction in the overall project duration,
the size of the buffer has to be less than the sum of the safety margins extracted from the tasks on the corresponding
chain. However, CCPM does not provide any scientific or
objective basis for determining the buffer size. This raises
several problems.
First, the feeding chain concept is based on the assumption that the project network consists of several paths that
start in parallel and proceed to merge into each other, eventually leading to the final product of the project, as shown
in Figure 3.
This network structure is applicable to projects that consist of construction, assembly, and integration tasks, which
are common in manufacturing environments. But many

Figure 3. Typical Project Network According to CCPM

December 2003 Project Management Journal 27

PMI-002 11/5

11/6/03

9:20 AM

Page 28

Figure 4. General Case of a Project Network

projects begin with a small core of central activities, i.e.,


design and analysis, which split into parallel tracks that
merge at various intermediate review points before producing the various project deliverables. This leads to more complex network flows where a given task may have both
predecessors and successors from several chains (Figure 4).
In such cases, it is not clear how much of a feeding buffer
should be allotted to each merging task.
Schonberger (1981) has shown that projects will always
be laterelative to the deterministic critical path. The
amount of delay is contingent on the time variability of
activities and the amount of parallel paths in the network.
In that respect, the critical chain is no different from the critical path, especially in nonarborescent networks.
Critical Chain

Job 1 (4)
Job 2 (6)

Project
Buffer

Job 3 (4)

NC 1

Job 4 (4)

Job 5 (12)

(6)

(1) (1)

NC 2

Job 6 (12)

Feeding
Buffer
Non Critical Chain

Figure 5. The Effect of the Time Variability on Project Duration

28 Project Management Journal December 2003

Figure 5 provides an example of such a network. In


addition to the critical chain that consists of activities 1
through 4, there are three more activities: Job 5 and job 6
run parallel to each other and feed into job 7, which in turn
feeds into the critical chain at the beginning of job 4. For the
sake of the example, let us assume that the durations (after
reductions of up to 33% as recommended by CCPM) are 12,
12, and 1 time unit for jobs 5, 6, and 7, respectively.
Thus, the feeding buffer has a length of 1 time unit, as
shown in Figure 5. In order to examine whether the feeding
buffer is adequate and effective, the authors follow the same
method used by Schonberger (1981). Assuming a variability
of +/- 3 units for each of the two longer activities, job 5 and
job 6, calculate the expected length of time required for the
two to complete. Because the two run parallel, the amount
of time required for both to complete is the maximum of
the actual durations of each of the two. There are seven possible duration values for each activitya total of 49 combinations. Table 1 shows the combinations in a matrix, with
the cells containing the maximum value. The average across
the entire matrix is 13.14. Adding to this the duration of job
7, which is 1 time unit (and ignoring its own variability),
the authors come up with the result that the variability of
the noncritical chain exceeds its feeding buffer. In effect, this
causes the noncritical chain to become critical. More parallel chains will increase the estimated duration even further.
A second issue pertains to the validity and stability of
the schedule that serves as the basis for determining the
buffers. According to CCPM, the critical chain and associated buffers are identified from a schedule obtained with a
resource-leveling algorithm. The mathematical problem of

PMI-002 11/5

11/6/03

9:20 AM

Page 29

scheduling the project tasks under resource constraints is


known to be very difficult to solve optimally. In fact, this
problem belongs to the class of problems for which it has
been shown that there are no efficient algorithms for finding the optimal solution for large projects. A comparison of
three exact approaches for solving the constrained resource

Duration of Job 6

Duration of Job 5
99

110

111

112

113

114

115

99

99

110

111

112

113

114

115

110

110

110

111

112

113

114

115

111

111

111

111

112

113

114

115

112

112

112

112

112

113

114

115

113

113

113

113

113

113

114

115

114

114

114

114

114

114

114

115

115

115

115

115

115

115

115

115

Table 1. Joint Duration of Parallel Activities Job 5 and Job 6

project scheduling problem and their limitations can be


found in Patterson (1984). Consequently, resource-leveling
algorithms use heuristic rules to generate solutions that are
hoped to be close to the optimum (Wiest, 1967).
CCPM theory does not prescribe a specific resourceleveling algorithm out of the numerous algorithms that
have been published in the operations research literature
and vary in terms of average distance from the optimum.
Thus, it is hard to assess how good is the schedule upon
which the buffers are based. Project networks are not
arborescent, and because determination of the appropriate
buffer size has to take into account the variability of activity durations and the number of parallel paths in the network of the network, simulation studies are required, as
Schonberger (1981) suggests.
In addition, the critical chain itself may change for
several reasons. Hoel and Taylor (1999) show that if the
overall uncertainty on a given feeding chain is such that
the project planner defines a feeding buffer greater than
the free slack of the feeding chain, that chain becomes
part of the critical chain. Further, during project execution, the critical chain may change as a result of changes
in resource availability or in buffer utilization. Changes in
the set of tasks that constitute the critical chain are likely
to affect the meaning of the buffers of various types,
bringing us to the third issue, which is related to the use
of buffers for project control.
According to CCPM, schedule control is based on monitoring the extent of buffer penetration, which is defined as
the amount of time running from the original start date of
the buffer on the critical chain or one of the feeding chains,
as appropriate, to the projected end date of the last task on

the corresponding chain. The projected dates are based on


estimates of the duration left for the tasks. The estimation
of how much work remains to be done is also subjected to
inflation by safety marginsthe very same problem CCPM
attempted to solve by using buffers. However, let us assume
that buffer penetration data is indeed valid and accurate
and can be trusted to serve as an indication of the likelihood that the task chain will be completed by the end date
of the buffer. CCPM prescribes that, in case of contention
for limited resources, priority should be given to the task
belonging to the chain with the highest buffer penetration
rate. The rationale for this rule is clear: Chains of tasks
where a higher percentage of their buffers have been used
are at a higher risk of missing their committed dates and,
consequently, ought to be given higher priority in resource
allocation decisions. However, this consideration is not the
only one and may not be the most relevant one. For example, we may prefer to give priority to tasks that belong to a
project with very high penalties for missing deadlines, or to
those that have a key strategic impact, regardless of the
amount of remaining buffer.
A final point regarding time buffers deserves attention.
Buffers of various types are shown on the project schedule
and Gantt chart as special types of activities. Because there is
one feeding buffer at the end of each chain of tasks in the
project network (if we assume that typically a chain consists
of eight to ten tasks in series before each merging point and
take into account resource buffers as well), buffers add at
least 10% to 15% to the number of items on the Gantt chart.
These additional items, which have to be interpreted differently from the others, add clutter to the schedule and
increase the potential for confusion.
Overall, although feeding and project buffers have
some intuitive appeal, one ought to be aware of the limitations in their validity and usefulness as the main decisionmaking criterion in project control.
Resource Utilization
CCPM is against assigning more than one task to be carried
out concurrently by a given resource. The organization could
reduce the extent of multitasking without switching to
CCPM, but it is not clear at all that eliminating multitasking
is actually a good idea. In fact, a study of 64 high technology firms carried out by McCollum and Sherman (1991)
presents some evidence to the contrary. The researchers
examined the effectiveness of matrix organizations and
found that there was a relationship between the number of
projects to which research and development personnel were
assigned and key performance indicators of the firm.
Specifically, they found that for two of the most important
measures of performancereturn on investment (ROI) and
rate of sales growthassignment to two projects seems to be
optimal, while up to three may not be problematic.
Resource buffers are a unique feature of CCPM. They are
fictitious tasks that provide advance notice to the critical
resources that the prerequisites for assigned tasks are about
to be completed and that they should complete whatever

December 2003 Project Management Journal 29

PMI-002 11/5

11/6/03

9:20 AM

Page 30

they are doing and become ready to start working on their


tasks shortly. Further, they are asked to complete assigned
tasks as soon as possible in order to allow successor tasks to
start as soon as possible. This method of coordination
among project team members seems to us rather chaotic
and requires a great deal of unscheduled communication. It
may not be feasible at all if some of the resources are outside contractors who may not have the flexibility to drop
their ongoing jobs and invest their full attention on their
assigned project task. There is value in alerting resources to
important (critical chain activities) early-start opportunities, and CCPM is correct to point out that managing to
complete tasks on time is not the same as managing to
complete the project on time. However, it is the authors
opinion that this is a supplement, rather than a substitute,
for the traditional way of publicizing a schedule to which
all task owners have committed. The schedules integrity
still needs to be maintained through an effective change
management process.
Overall, the authors fail to see any advantage that this
approach gives to the traditional way of publicizing a schedule to which all task owners have committed, and to maintaining its integrity through an effective change
management process.
Multi-Project Management
CCPM deals with a multi-project environment by staggering the projects around the constraining resource (the
drum in TOC terminology). In principle, at any given
point in time there could be several constraining resources,
each leading to a different schedule. Further, at different
points in time we could have different constraining
resources, so that there could be conflicting schedules. The
premise that there is a single drum is based on a steady
state view of the work mix in the organization and is applicable to manufacturing and operations environments. In
most project environments there is no steady state and,
consequently, the authors doubt the applicability of the
solution obtained with CCPM.
CCPM Scope
Project success and project management success are not necessarily equivalent. For many project managers, success
means meeting predefined planning goals stated in terms of
schedule, budget and scope commitments. To customers,
however, success relates primarily to whether the project
contributes to the goals of the organization. The relative
importance of the various dimensions of project success was
documented by Lipovetzky, Dvir, and Shenhar (1997) in a
study of 110 projects in Israel. Their analysis revealed that
benefit to the customer was by far the most important
dimension, almost twice as important as meeting planning
goals. Nevertheless, a sound project management process
well executed by a qualified project manager enhances the
likelihood of project success in the eyes of the customer.
Like conventional project management, CCPM deals
with project management success, rather than project suc-

30 Project Management Journal December 2003

cess. Furthermore, CCPM focuses on a single aspect of project managementmeeting the schedule goals. The relative
importance of this aspect is not universal: A project that
exceeded its original schedule by 10%, but still earned ten
times its cost in increased profits, would be considered
more successful that a project that was completed on time
and budget but added little to the customers business
effectiveness.
Within the narrow scope of meeting project schedule
objectives, CCPM focuses mainly on the uncertainty inherent in the schedule. Rather than addressing the root cause of
duration uncertainty, CCPM accepts it as a given and
attempts to overcome it by means of buffer management. In
contrast, most project risk management methodologies
work at identifying and reducing the sources of uncertainty
or by estimation methodologies that work to improve the
quality of the duration estimates. Although CCPM does not
preclude the application of other, more comprehensive risk
management approaches, its limited focus makes it ill suited to serve as the single tool for dealing with project uncertainty. At best, it can help manage the schedule uncertainty
that remains after the application of risk analysis and risk
mitigation tools.
Further, because CCPM is presented as a revolutionary
concept that replaces, rather than complements, current
project management knowledge and practices, it is not
properly integrated with the accepted body of knowledge
and state of the practice. This situation poses a certain
dilemma to organizations that are new to project management methodologies and are asked to choose between
CCPM and mainstream methodologies, such as those contained in the PMBOK Guide.
CCPM Adoption
An organization that considers the adoption of CCPM as its
main project management methodology has to take into
account two major sources of cost: software tools and culture change. CCPM implementation requires project personnel to use a software tool that supports the concept of
buffer creation and management. Currently, only one of the
mainstream mid-size project management software tools is
compatible with CCPM and two add-in products are available for the leading tool in the marketone of which
requires a specific database server. Thus, the range of software tool options is limited and bound to be relatively
expensive.
However, the costs of acquiring, deploying and applying software that supports CCPM are likely to be secondary
relative to the costs resulting from the need to change the
culture of the organization. CCPM is presented as a
methodology that has to be adopted in its entirety, ranging
from buffer calculation, personnel assignment, and
progress reporting, up to the criteria for determining delivery dates in a multi-project environment. As such, CCPM
requires massive education at various levels and functions
throughout the organization and may even require experienced project managers to forget some of their convention-

PMI-002 11/5

11/6/03

9:20 AM

Page 31

al knowledge in order to absorb the new methodology.


Some of the key points that involve a change in the organizational culture are:
Giving up ownership of the task duration and relying
on the schedule buffers to absorb deviations in individual task performance;
Replacing the concept of due date with estimated
completion date range, as represented by the feeding and project buffers;
Avoiding multi-tasking.
Clearly, CCPM is a departure from traditional project
management and its adoption by any organization will
require a concerted effort at all levels.
Concluding Remarks
Project performance is often less an issue of managing the
constraints on the schedule and more a function of the personal skills and capabilities of the leaders, such as articulating customer requirements, understanding future needs,
enlisting cooperation throughout the organization, etc.
CCPM is based on the premise that uncertainty in activity
duration is the major factor affecting the ability to complete
the project on time. But, there are other relevant mismanagement practices that affect schedule expectations, such as
external pressures, internal politics, and distorting estimates
to win the project, which should also be addressed.
CCPM leads us to believe that management of projects
can be accomplished through the same rational process that
works for production management. In order to accomplish
this, CCPM adapted the concepts of bottlenecks and material buffers that were developed within the framework of
Goldratts Theory of Constraints, calling them critical
chain and time buffers in the realm of projects. These
concepts and other elements of CCPM are not necessarily
new. For instance, the impact of resource availability on critical path calculations has been known for quite some time
(Raz, 1996). However, the issue of intellectual innovation is
not the main one, even though it is emphasized in the
CCPM literature. The authors already presented their concerns about the validity of the assumptions and the adequacy of the scope covered. The key question is: Is CCPM
indeed superior to the currently accepted project management methodologies?
CCPM seems to hold answers to problems that have
challenged project managers for many years, and presentations on it are enthusiastically received. CCPM proponents
have claimed some dramatic successes, but from the
authors personal experiences, these appear to be mainly in
organizations that started out with weak or nonexistent
project management methodologies. However, the authors
are not aware of any comparative studies that provide scientific evidence to the effect that organizations that have
adopted CCPM perform better than organizations that
apply a conventional project management methodology. In
addition, CCPM has been out for a short period of time, and
it is impossible to assess any sustainable long-term benefits.
Although the bulk of this paper has been devoted to a

critical analysis of CCPM, it is important to point out its


positive side. First, CCPM is a methodology, and any
methodology is better than no methodology at all. Even if
CCPM is simplistic and oversold, it is worth studying for its
several pieces of good advice. In this respect, CCPM:
Accounts for duration uncertainty by making buffers
explicit, sharing the knowledge of buffer sizes and
placement with workers, management, and sponsors;
Considers resource availability;
Focuses on the key tasks and resources;
Constantly monitors the amount of buffer in
your schedule;
Provides advance notice of upcoming work to
critical resources;
Does not split your attention among numerous tasks.
Some CCPM principles do make sense in certain situations and their careful application can improve performance, provided the preconditions and assumptions are fully
understood. However, to the question of whether your
organization should adopt CCPM as its project management methodology, the authors offer the following qualified answer. If your organization lacks effective project
planning and control processes, you run a relatively large
number of quite similar projects in a matrix environment,
and your main concern is meeting deadlines, CCPM could
be beneficial. Otherwise, the authors suggest carefully
weighing the limitations of CCPM and its costs against the
potential for contributing to the long-term business success
of your organization. Perhaps the optimal solution is to
incorporate those CCPM principles that are applicable to
your environment within a broader conventional project
management methodology.
References
Globerson, S. (2000). PMBOK and the critical chain.
PM Network 14 (5), 6366.
Goldratt, E.H. (1997). Critical Chain. Great Barrington,
MA: North River Press.
Hill, J., Thomas, L.C., & Allen, D.E. (2000). Experts estimates of task durations in software development projects.
International Journal of Project Management, 12 (1), 1324.
Hoel, K., & Taylor, S.G. (1999). Quantifying buffers for
project schedules. Production and Inventory Management
Journal, 40 (2), 4347.
Homer, J.L. (1998). Applying the theory of constraints
to projects. Proceedings of the 29th Annual Project Management
Institute 1998 Seminars & Symposium. CD-ROM, Newtown
Square, PA: Project Management Institute.
Leach, L. (1999). Critical chain project management
improves project performance. Project Management Journal,
30 (2), 3951.
Lipovetsky, S., Tishler, A., Dvir, D., & Shenhar, A.
(1997). The relative importance of project success dimensions. R & D Management, 27 (2), 97106.
McCollum, J.K., & Sherman, J.D. (1991). The effects of
matrix organization size and number of project assignments

December 2003 Project Management Journal 31

PMI-002 11/5

11/6/03

9:20 AM

Page 32

on performance. IEEE Transactions on Engineering


Management, 38 (1), 7578.
Newbold, R.C. (1998). Project Management in the Fast
Lane. Boca Raton, FL: The St. Lucie Press.
Patterson, J.H. (1984). A comparison of exact approaches for solving the multiple constrained resource, project
scheduling problem. Management Science, 30 (7), 854867.
Raz, T., & Marshall, B. (1996). Float calculations in project networks under resource constraints. International Journal
of Project Management, 14 (4), 241248.
Simpson, W.P., & Lynch, W. (1999) Critical success factors in critical chain project management. Proceedings of the
30th Annual Project Management Institute 1999 Seminars &

Symposium. CD-ROM, Newtown Square, PA: Project


Management Institute.
Schonberger, J.R. (1981). Why projects are always late:
a rationale based on manual simulation of a PERT/CPM network. Interfaces, 11 (5), 6670.
Wiest, J.D. (1964). Some properties of schedules for
large projects with limited resources. Operations Research, 12,
(MayJune), 395418.
Wiest, J.D. (1967). A heuristic model for scheduling
large projects with limited resources. Management Science, 13
(6), B359B377.
Wiest J.D., & Levy F.K. (1977). A management guide to
PERT/CPM. Englewood Cliffs, NJ: Prentice-Hall.

Tzvi Raz holds B.Sc, M.A.Sc and Ph.D degrees in Industrial and Management Engineering. He is a
Professor of Technology and Information Systems Management and Assistant Dean at the Leon Recanati
Graduate School of Business Administration at Tel Aviv University. Previously, he managed a technology
insertion program at an IBM software development laboratory, and was on the Industrial Engineering faculties of the University of Iowa, US and Ben Gurion University, Israel. Dr. Raz has published over 60
research papers in refereed international journals and is on the editorial boards of Computers and
Operations Research and the Project Management Journal. In the last five years he has served as consultant to several technology firms in Israel on project and risk management, and has conducted short
courses and workshops on these topics in Israel, Europe and South America. Dr. Raz has been certified
as a Project Management Professional by the Project Management Institute and was the founding president of the Israel Chapter of the Project Management Institute.

Dov Dvir is a senior lecturer at the Ben-Gurion University in Beer Sheba. Previously he was the head of the
Management of Technology (MOT) department at the Holon Center for Technological Education, Israel. He
also lectured at the Faculty of Management, The Leon Recanati Graduate School of Business
Administration at the Tel Aviv University. He holds a B.Sc. in electrical engineering from the Technion Israel Institute of Technology, M.Sc. in operations research and an MBA from Tel Aviv University; and a
Ph.D. in management (specialization in MOT) from Tel Aviv University.
In his military service as a senior officer in the Israeli Defense Force (IDF) he was a commander of a large
Technological Development Center.

Robert Barnes has an MSc and a Diploma of Management from the University of Auckland, and holds PMP
certification. He guest-lectures on Information Technology topics at Auckland University's Business
School, and is the author of an authoritative textbook on PL/I programming. He is a director of the iE3
Group, and a National Councillor of the New Zealand Computer Society, as well as an active consultant.

32 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 33

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

Project Management Learning:


What the Literature Has to Say
DEBBIE TESCH, Department of Information Systems, Williams College of Business,
Xavier University, 3800 Victory Parkway, Cincinnati, OH 45207-5161 USA
TIMOTHY J. KLOPPENBORG, Department of Management and Entrepreneurship,
Williams College of Business, Xavier University, 3800 Victory Parkway, Cincinnati, OH 45207-5161 USA
JOHN K. STEMMER, Xavier University, 3800 Victory Parkway, Cincinnati, OH 45207-5161 USA

ABSTRACT
This paper describes the methodology
and results of research designed to
extract useful professional project management information from recent research
literature in the information systems and
information technology (IS/IT) fields. The
resulting database of 784 journal, thesis,
and conference proceedings abstracts
represents research from 1999 through
2001 in the IS/IT field related to project
management. A lessons learned executive
seminar was conducted to allow experienced, active project managers to examine selected findings for lessons learned
and research opportunities that might
benefit project managers.
Keywords:
information
systems;
research; teams; communication; risk

2003 by the Project Management Institute


Vol. 34, No. 4, 33-39, ISSN 8756-9728/03

hat is the current state of project management research? In the past three
years, a significant component of the Project Management Institute
(PMI) research focus has concerned examining existing project management research for its contribution to practitioners learning. In a previously funded PMI initiative, Kloppenborg and Opfer (2002) presented the results of an
examination of project management research since 1960. Their study explores
trends, major issues, and research contributions from each of the nine (PMBOK)
knowledge areas.
Funded by PMI, this current study represents the final deliverable of a series
of activities designed to extract project management information useful to the
practice of the profession from recent research literature in the information systems and information technology (IS/IT) fields. The grant investigators developed
a database of journal, thesis, and conference proceedings abstracts that represent
IS/IT project management research from 1999 through 2001. The project provides
a focused review with the intention of extracting information useful to practice in
the area of IS/IT project management.
Results reported here represent a review accomplished through a two-part
process: creating an annotated bibliography of research articles on project management in the IS/IT field and hosting a special lessons learned executive seminar
that allowed experienced, active project managers to examine selected findings for
lessons learned and research opportunities that they believe will benefit project
managers.

Methodology
Initial creation of the annotated bibliography began with a review of the efforts
of Kloppenborg and Opfer (2002). This research had been a broad-based review
of project management literature that also relied on an annotated bibliography to
develop trends and recommendations in project management research. The
process was initiated by applying the project management research definition previously developed in Kloppenborg and Opfer (2002) to identify for IS/IT project
management research.
With a satisfactory research definition guiding the researchers efforts, the
next step was to identify appropriate databases for review and appropriate keywords for finding articles. Eight commercial databases were searched to conduct
a thorough literature review. The four databases used in the earlier project were

December 2003 Project Management Journal 33

PMI-002 11/5

11/6/03

9:20 AM

Page 34

Project management
Program$ management
Acquisition management
Systems management
Logistics management
Performance management
Configuration management
Program$ control
Project control
Human resource management
Integration management
Scope management
Cost management

Communication management
Risk management
Procurement management
Contract management
Schedule management
Project life cycle
Project lifecycle
Project manager
Project leader
Project success
Project failure
System$ development
SDLC

$ Indicates the use of truncation in the search, e.g., system$ would retrieve system or systems.
communication management

Table 1. Database Search Terms

used again (ABI/Inform, Compendex,


Business & Company ASAP, and
Digital Dissertations, i.e., Dissertation
Abstracts. Two additional databases
were added to increase the retrieval of
materials from resources that focused
on IS/IT technology (Applied Science
and Technology Index and INSPEC).
Two new general business/management databases also were added
(Business & Industry and Business &
Management Practices). Additional
items were selected from PMI conferences from 1999 through 2001.
Standardized searches using predetermined search terms determined
the selected articles, starting with the
list of keywords created from the earlier project adjusted to capture IS/IT
results. See Table 1.
These database terms then were
combined with IS/IT keywords (and
information system$ or information
technology or computer system$,
where $ indicates the use of truncation
in the search) to focus the searches on
this particular project management
topic. Date restrictions limited search
results to materials published in 1999
or later. These searches provided a
thorough literature review of English
language periodicals and dissertations
and provided some coverage of masters theses and conference proceedings. Only materials with pre-existing
abstracts to which the project manage-

34 Project Management Journal December 2003

ment research definition could be


applied were selected.
To conduct these database searches, the principal investigators recruited
student assistants, primarily selected
based on previous coursework or experience in project management and
information systems aptitude. The students then followed the predetermined
plans for searching in the selected
databases. They extracted relevant articles from the databases, which then
were imported into distinct source
index databases created in Reference
Manager 9.5. Having created separate
source index databases, duplicates
were removed, and the materials were
reviewed for other items that could be
eliminated quickly.

Advertising Age
American Medical News
Asia Pulse
Automotive News
Business Insurance
Business Marketing
Communications News
Computer Technology Review
Computer World
Crains Chicago Business
Eweek

Table 2. Selected Publication References Removed

Based on experience from the


prior project and a review of titles in
the source index databases, selected
publications were deleted for not
being research-oriented. Table 2 represents an illustrative list of sources
deleted. We quickly deleted abstracts
from sources that were not research
based, such as brief articles, company profiles, columns, financial profiles, editorials, news briefs, book
reviews, software reviews, and
authorless articles.
From an initial database of 9,332
records, preliminary editing results
yielded a database of 4,428 records.
The research definition was applied to
the remaining items through an individual review of each abstract. The
resulting database contains 784
records. The other records were deleted
because they violated at least one part
of the research definition.
Executive Seminar
To parse the database into logical, yet
manageable groups, a number of
queries were conducted. Based on
analysis of these results, five focus
groups were established to consider
findings. Table 3 indicates the groups
and number of abstracts investigated.
Five individuals were selected to
facilitate the seminars based on their
previous experience and genuine interest in advancing project management
in the IS/IT profession. All of the facilitators were either Project Management
Professionals with at least a masters
degree or were PhD-qualified. Four

Financial Times
InfoWorld
InterActive Week
Marketing News
Nations Restaurant News
New York Times
PC Week
PC World
PC Magazine
Supermarket News
Wall Street Journal
Womens Wear Daily

PMI-002 11/5

11/6/03

9:20 AM

Page 35

Cost,
Leadership,
Quality, Risk,
Procurement, Teamwork, HR,
Integration
Life Cycle
Communications
130

137

79

Schedule,
Scope
170

Information
Systems
Success/Failure
165

Table 3. Total Abstracts Examined by Focus Group

have extensive consulting experience,


while three have college faculty experience. Facilitators were assigned to focus
groups based on experience and interest
in a given area. Facilitators for each of
the focus groups were given a database
of abstracts that matched the keyword
searches for their area. The facilitators
selected a subset of those research documents to represent a major contribution toward advancing the state of
project management in IS/IT.
Seventy-six documents were
selected for discussion, including 11
duplications. Despite the potential for
bias among articles selected for discussion, researchers considered the
potential contribution of more indepth findings to outweigh the associated bias.
Seminar participants received a
binder with the citation and abstract
for each research document. Given
time constraints, each group discussed four to seven of the selected
documents, for a total of 28 documents. Online scribes for each focus
group attempted to capture the most
significant discussion of each abstract,
and 35 pages of notes were transcribed. A complete list of abstracts
selected for consideration may be
obtained from the authors, who summarize and interpret the more useful
comments from that transcription in
the Findings section.
Database Analysis
Of the 784 records in the database,
499 records (64%) represent abstracts
from journals. A total of 223 different
journals are represented. Eighty-one
journals (36%) contain more than one
citation. Journals referenced 10 or
more times include: European Journal
of Information Systems (EJIS), Journal
of Management Information Systems
(JMIS),
Information
Systems

Management (ISM), Journal of


Systems and Software (JS&S),
Information Systems Journal, and
International Journal of Project
Management. Table 4 describes the
most frequently cited journals. The top
five journals represent top-tier academic journals, as academicians seem
to have the most to say about IS/IT
project management research issues.
The remaining records in the database consist of 253 conference proceedings
and
33
theses
or
dissertations. Table 5 lists conferences
by count with more than two citations.
Fourteen different conferences are represented in this list. These citations
account for 61% of conference proceedings references. Three conferences
provided 20 or more abstracts (34%):
the Hawaii International Conference
on System Sciences (HICSS), the
Information Resources Management
Association International Conference
(IRMA), and the Association for
Information
Systems
Americas
Conference on Information Systems
(AIS AMCIS).
Since 1968, the Hawaii International
Conference on System Sciences (HICSS)
has been a unique forum for the interchange of ideas in all areas of information systems and technology. The
Information Resources Management
Association (IRMA) is an international
professional organization dedicated to
advancing the concepts and practices of
information resources management in
modern organizations. The Association
for Information Systems (AIS) is a new
professional organization whose mission is to advance knowledge of how
information technology can improve
organizational performance and individual quality of life. The Project
Management
Institutes
Global
Congress (formerly Annual Seminars &
Symposium) is a largely practitioner-

focused forum, in which all aspects of


project management are discussed.
Findings
Relevant issues, identified as lessons
learned in this investigation, were
identified by examining database
abstracts and collecting practitioner
input in the executive seminar. In reality, these research findings form a continuum from very well proven to very
preliminary. In addition, examined
contributions were described from
quite innovative to quite mundane.
Based on these observations, the
authors grouped the findings into lessons learned and future research suggestions. Many of the lessons learned
tend to confirm common wisdom.
General Comments
Many of the practitioners at the executive seminar expressed concern that
some of the more advanced research
does not necessarily closely relate to
everyday project issues and demands.
Practitioners asked repeatedly how
they could use a particular finding
especially those that were published in
the more highly regarded academic
journals. This finding is consistent
with research by Benbasat et al. (1999)
that explains why there is a tendency
to describe IS research as lacking relevance to practice. Five explanations for
the lack of relevance of current IS literature described in Benbasat et al.
(1999) include:
1. Emphasis on rigor over practical
relevance;
2. Lack of a cumulative research tradition;
3. Rapid/continuous change associated with information technologies;
4. Degree to which IS academicians
are exposed to current business and
technological contexts;
5. Failure of the institutional environment to encourage the pursuit
of relevance. Benbasat et al.
(1999) suggest procedures that IS
researchers might employ to
introduce relevance into their
research efforts.
A second general observation is
that much of what is published in conference proceedings is, by its nature,
preliminary, exploratory research.

December 2003 Project Management Journal 35

PMI-002 11/5

11/6/03

9:20 AM

Page 36

Journal

Description

European Journal of Information Systems (EJIS)

The official journal of the Operational Research Society.


The EJIS audience represents information systems
professionals in industry, commerce, government and
academic departments of management, business, and
computing.

Journal of Management Information Systems


(JMIS)

JMIS is a widely recognized forum for presenting


research that advances the practice and understanding
of organizational information systems. Attempts to
bridge the gap between theory and the practice of
management information systems.

Information Systems Management (ISM)

ISM views its audience as both practitioners and


academicians and aims to bridge the gap between trade
and academic research publications, providing guidance
in innovative management of information technology
and related resources. The journal's articles, written by
IT professionals and academicians, appear as case
studies, research papers, surveys and white papers.

Journal of Systems and Software

The Journal of Systems and Software publishes papers


covering all aspects of programming methodology,
software engineering and related hardware/software
systems issues to an audience of researchers, scholars,
and managers in software engineering, computer
science, information systems, computer programming,
computer hardware, and MIS.

Information Systems Journal (ISJ)

ISJ publishes papers on any aspect of information


systems with a particular emphasis on the relationship
between information systems and people, business and
organizations. Articles published cover research,
practice and experience. Its audience includes
academicians in computer science, business studies,
and management departments as well as computer
users in business and industry.

International Journal of Project Management


(IJPM)

IJPM offers comprehensive coverage of all facets of


project management from systems to human aspects.
IJPM provides a focus for worldwide expertise in the
required techniques, practices and areas of research.
It provides a forum for its readers to share common
experiences across the full range of industries and
technologies in which project management is used.

Table 4. Most Frequently Referenced Journals

36 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 37

Future examination should reveal, in


many cases, that previously exploratory studies have been confirmed and
results published in academic journals.
Lessons Learned
Based on database abstracts examined
in the executive seminar, this paper
presents the findings as lessons
learned.
Lesson 1. The deployment of
virtual teams does not replace the
occasional necessity of face-to-face
meetings.
Lesson 2. Requirements negotiation may be significantly facilitated by
virtual team configurations.
In an exploratory study of the
effects of multimedia communication
systems on group negotiation performance and behavior, Damian et al.
(2000) suggest that groups in face-toface meetings perform no better than
videoconference groups. Their findings
examine the collaborative work of virtual teams as they negotiate system
requirements. However, in executive
sessions with practitioners, discussion
confirmed that virtual teams must continue to plan meetings with agendas
and minutes and stressed the necessity
of face-to-face meetings when projects
are troubled. In addition, Damian et
al. (2000) identify a distributed virtual
team configuration that is qualitatively
more conducive to requirements negotiation than face-to-face meetings.
Lesson 3. IS projects require
both business and technically
trained project leaders as well as generally qualified project management
professionals.
Thite (2000), in acknowledging
that no one style is appropriate for all
project environments, suggests that
successful IS organizations require
both project leaders and project managers. The project leader is a member
of the project team who understands
both business and technical issues
associated with a specific project and is
concerned primarily with immediate
project task accomplishment. The project manager employs a variety of leadership skills that consider personal
growth and development of the individuals and organizations. On a broad-

er scale, the project manager considers


all nine project management knowledge areas within the scope of the current project.
Lesson 4. Different perceptions
of the importance of written and oral
communications skills by IS staff and
end users have an effect on end user
satisfaction.
Lesson 5. Different perceptions
of the importance of interpersonal
skills by IS managers and IS staff affect
job performance evaluations.
Miller (2000) considered perceptions of written and oral communications and interpersonal skills from the
perspective of managers, IS staff, and
end users. Using matched observations
from survey participants working on
the same project, results indicate that
differences in perceptions of IS staff
and users, with respect to the importance of written and oral communications, lead to lower user satisfaction
levels. Similarly, differences in perception of the importance of interpersonal skills by IS staff and managers lead
to lower job performance evaluations.
Lesson 6. An empirically tested
software risk assessment model, SRAM
allows the prediction of outcomes of
software projects.
Foo and Murugananthan (2000)
introduce a model for assessing software project risk. The Software Risk
Assessment Model (SRAM) makes use
of a comprehensive questionnaire. Test
results indicate that using the risk indicator in SRAM, it is possible to accurately predict outcomes of software
projects. Use of a tested model such as
SRAM allows for project managers to
avoid late occurring risk events that
have higher costs associated costs.
Lesson 7. The top three IS project risk factors are lack of top management commitment, failure to obtain
user commitment, and misunderstanding of commitment (Schmidt,
Lyytinen, Keil, and Cule, 2001).
Advocates of software risk management claim that by identifying and
analyzing threats to success, i.e., risks,
the chance of project failure can be
reduced. Schmidt et al. (2001) deploy
a rigorous data collection method to
produce a rank-order list of risk fac-

tors. This data collection method is


designed to elicit and organize opinions of a panel of experts through iterative, controlled feedback. Using
surveys in Hong Kong, Finland, and
the United States with experienced
project managers from each country,
53 IS project risk factors are identified.
Lesson 8. IS/IT academic research
should be examined frequently for the
possibility of existing successful models
that may offer relevance for IS project
management issues and ranked.
Chatzoglou (1999) introduces a
theoretical framework to assess the
efficiency of the requirements capture
and analysis (RCA) process in software
development. Results from an
exploratory field study using a technique called data envelopment analysis (DEA) show that the framework
and methodology employed allow
users to assess RCA process inefficiencies and offer useful direction for
improvement of the RCA process and
overall software development.
Future Research Suggestions
Many suggestions were made for
important future IS/IT project management research. Discussion centered
largely on describing factors related to
the success of project management
efforts. These discussions considered:
the roles of trust and effective communication (Damian et al., 2000); patterns of leadership behavior in IS
organizations (Stewart & Gable,
2001); the effect of IS project manager
business competencies on project success (Gottschalk, 2000, Gottschalk,
2000; Haggerty & Nance, 2000); and
the nature of specific project management knowledge, skills, and behaviors
that represent success factors (Kempis
and Ringbeck, 1999). Alternately, discussion considered an examination of
factors contributing to project failure
(Oz & Sosik, 2000): methods for rescuing troubled projects (Montealegre
& Keil, 2000); and risk reduction
strategies for IS/IT projects (Hackbarth
& Kettinger, 2000).
Summary and Recommendations
There has been tremendous growth in
IS/IT project management in recent

December 2003 Project Management Journal 37

PMI-002 11/5

11/6/03

9:20 AM

Page 38

Number
Hawaii International Conference on System Sciences (1999, 2000, 2001)
Information Resources Management Association International Conference (1999, 2000, 2001)
Americas Conference on Information Systems (1999)
Project Management Institute Annual Seminars and Symposium
Computer Personnel Research Conference (2000)
European Conference in Information Systems (1999, 2000)
IEEE Conference on Management of Innovation and Technology (2000)
ACM SIGUCCS (2000)
Portland International Conference on Management of Engineering and Technology (1999)
International Conference on Information Systems Methodologies (1998)
Conference on the Social and Organizational Perspective on Research and Practice in
Information Technology (2000)
IEEE International Conference on Engineering of Complex Computer Systems (1999, 2000, 2001)
International Conference on Software Engineering and Applications (1999, 2000)
Medical Imaging (2000)
Proceedings of Gita Conference (1999)
Project Management Institute Research Conference (2000)
Advanced Information Systems Engineering Conference (2001)
Computers in Cardiology (2000)
IEEE Conference on Software Engineering Education and Training (2001)
IEEE International Conference on Systems, Man, and Cybernetics (1999, 2000)
International Computer Software and Applications Conference (1999)
International Conference on Electricity Distribution (2001)
International Conference on Product Focused Software Process Improvement (1999)
Medical Infobahn for Europe Proceedings (2000)
UK Academy for Information Systems Annual Conference (1999)
Western Power Delivery Automation Conference (2001)

33
32
20
14
12
10
7
6
4
3
3
3
3
3
3
3
2
2
2
2
2
2
2
2
2
2

Table 5. Conference Proceedings by Count 3 or More Abstracts

years, as more organizations realize


project management can greatly
improve the success of IS/IT ventures.
A research effort designed to extract
project management information useful to the practice of the profession
resulted in identification of 784
records directly related to IS/IT project
management research. Approximately
10% of the resulting records were
examined and one-third of those were
discussed in detail for their contribution to project management in the
IS/IT field. Active practitioner participants offered their experience in considering the contribution of research
discussed.
Some of the identified IS/IT
research reflects the considerable academic rigor required to ensure that
the quality of this research matches
that of other business school disciplines. As such, the practical relevance
of
this
research
was
questioned. Much research lacks evidence that it has been exposed to the
real world. Alternately, many of the
nuggets or lessons learned often
confirmed common wisdom.
Significant findings were extracted from this body of literature and
further considered by project management practitioners.

38 Project Management Journal December 2003

Practitioners need to deploy virtual teams on IS/IT projects while continuing to consider how to use them
most effectively and under what
constraints.
IS/IT projects require project leaders who are business-oriented and
technically trained, as well as generally qualified project management
professionals.
Different perceptions of written
and oral communication and other
interpersonal skills have an effect
on project performance. Project
leaders must control for effects of
perception differences.
Significant project risk factors
include lack of top management
commitment, failure to obtain user
commitment, and misunderstanding
of commitment.
IS/IT practitioners and academics
need to frequently examine IS/IT academic research for the introduction
of success models relevant to IS project management issues.
Both the practitioners and
researchers on this project have
expressed that they should collaborate to ensure future research is theoretically sound and relevant.
Offering recommendations to produce more relevant IS research,

Benbasat et al. (1999) suggest selecting topics based on future interest of


stakeholders, looking to IS/IT practitioners to identify research topics,
and choosing research with potential
to influence practice.
Many of the most useful pieces
of research appealed to both groups.
This research identified many
proven findings, some contradictory
findings, and many suggestions for
further research. The authors
encourage academics and practitioners to improve the collective knowledge of IS/IT project management.
References
Benbasat, I., Zmud, R. W.,
Applegate, L. M., King, J. L., Davenport,
T. H., & Markus, M. L. (1999).
Empirical research in information systems: The practice of relevance. MIS
Quarterly, 23(1), 3-23, 25-7, 29-33.
Chatzoglou, P. D., & Soteriou, A.
C. (1999). A DEA framework to assess
the efficiency of the software requirements capture and analysis process.
Decision Sciences, 30(2), 503-31.
Damian, D. E. H., Shaw, M. L. G.,
Gaines, B. R., Hansen, H. R., Bichler,
M., & Mahrer, H. (2000). A study of
requirements negotiations in virtual
project teams. Proceedings of the

PMI-002 11/5

11/6/03

9:36 AM

Page 39

European Conference on Information


Systems, 2, 937-44.
Foo, S. & Muruganantham, A.
(2000). Software risk assessment
model. Proceedings of the 2000 IEEE
International
Conference
on
Management of Innovation and
Technology, 2, 536-544.
Gottschalk, P. (2000). Information
systems executives: the changing role of
new IS/IT leaders. Informing Science,
3(2), 31-9.
Gottschalk, P. (2000). Information
systems leadership roles: an empirical
study of information technology managers in Norway. Journal of Global
Information Management, 8(4), 43-52.
Hackbarth, G., & Kettinger, W. J.
(2000). Building an e-business strategy. Information Systems Management,
17(3), 78-93.
Haggerty, N., & Nance, W.
(2000). Understanding the link

between IT project manager skills and


project success. Research in progress.
In Proceedings of Computer Personnel
Research 2000 Conference, (pp. 192195). New York: ACM.
Kempis, R., & Ringbeck, J.
(1999). Information Technology Best
Practices. Industry Week Growing
Companies Edition, 2(9), 16-17.
Kloppenborg, T. J., & Opfer, W. A.
(2002). The current state of project
management research: trends, interpretations, and predictions. Project
Management Journal, 33(2), 5-18.
Miller, R. A. S. (2000). The importance
of
communication
skills:
Perceptions of IS professionals, IS managers, and users. Doctoral dissertation,
Louisiana Tech University.
Montealegre, R., & Keil, M.
(2000). De-escalating information
technology projects: lessons from the
Denver International Airport. MIS

Quarterly, 24(3), 417-20, 439-47.


Oz, E., & Sosik, J. J. (2000).
Why information systems projects
are abandoned: a leadership and
communication
theory
and
exploratory study. Journal
of
Computer Information Systems, 41(1),
66-78.
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.
Stewart, G., & Gable, G. (2001).
Emancipating IT leadership: an
action research program. Journal of
Information Technology Cases and
Applications (JITCA), 3(2), 7-20.
Thite, M. (2000). Leadership
styles in information technology
projects. International Journal of
Project Management, 18(4), 235-41.

JOHN STEMMER is the Assistant Director for Collections and Systems Services at Xavier University. He
participated in the original project management research investigation that developed the Project
Management Research: An Annotated Bibliography 1960-1999 database. As the projects Research
Librarian, he assisted in the selection and location of sources, as well as the design and creation of
the database. He has ten years experience in academic and research libraries; he is knowledgeable
on the types, availability, and use of electronic resources and has conducted research on electronic
journal availability.

DEBBIE TESCH is an Assistant Professor of Information Systems at Xavier University. She obtained her
DBA in Quantitative Analysis and Management Information Systems at Louisiana Tech University
awarded in 1992. Her current research interests include project management, system development,
and curriculum outcomes assessment. She has recent publications in Decision Science and
Communications of the ACM as well as numerous conference proceedings and a Visual Basic projects
text. She is a member of AITP.

TIMOTHY J. KLOPPENBORG is a Professor of Management at the Williams College of Business at Xavier


University in Cincinnati, OH. Dr. Kloppenborg has been on the faculties of University of North Carolina at
Charlotte and Air Force Institute of Technology. Tim earned his Ph.D. in operations management at University of
Cincinnati. He is a PMP. Tim has published in both Project Management Journal and PM Network as well as presented papers at numerous PMI Seminar/Symposiums and the Project Management Research Conferences.
Dr. Kloppenborg recently published two books, Managing Project Quality and Project Leadership. Tim has
hands-on and consulting experience in construction, information systems, and R&D project management.

December 2003 Project Management Journal 39

PMI-002 11/5

11/6/03

9:20 AM

Page 40

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

JWARS: A CASE STUDY


JIM METZGER, Northrop Grumman Information Technology
c/o Missile Defense National Team C2BMC 261,1 Jefferson Davis Highway, Suite 700
Arlington, VA 22202

ABSTRACT
This paper is a management-oriented
review of a large-scale government software development project. The product is
the Joint Warfare System (JWARS), a theater-level warfare simulation intended to
support U.S. Department of Defense decision-making. This paper discusses all
aspects of the JWARS development project from 1995 until 2002. Unique features
included object-oriented development, an
integrated government-contractor environment, and involvement of users and
subject matter experts in development
and testing.
Keywords: organizational planning; scope
definition; simulation
2003 by the Project Management Institute
Vol. 34, No. 4, 40-46, ISSN 8756-9728/03

40 Project Management Journal December 2003

Introduction
his paper is a management-oriented review of a large-scale government software development project. The Joint Warfare System (JWARS) is a theaterlevel warfare simulation that was developed as a tool to support U.S.
Department of Defense decision-making. This paper covers the period when the
author directed the projectfall 1995 through summer 2002. It discusses all
aspects of the project, including history, management oversight, requirements,
infrastructure, technical approach, development team, data, user participation,
evolution of processes, and insights. Unique features of the project included:

Object-oriented (OO) development, employing an OO language for implementation and a case tool that adheres to the Unified Modeling Language
for design;
An integrated government-contractor environment;
Involvement of users and subject matter experts in development and testing.
History
In May 1995, the Deputy Secretary of Defense established the Joint Analytic
Model Improvement Program (JAMIP) to improve the modeling and simulation
tools available to support U.S. Department of Defense (DoD) decision-making,
and directed the development of JWARS as the centerpiece of JAMIP. The Director,
Program Analysis and Evaluation (DPA&E), who serves in the Office of the
Secretary of Defense (OSD), was assigned to lead JAMIP in general and to develop JWARS in particular.
In November 1995, the JWARS office was created to develop JWARS. In June
1996, Joint Data Support (JDS) was established as the primary data support
organization for JAMIP and JWARS. Both the JWARS office and JDS are within the
Office of the DPA&E (ODPA&E).
During 19951997, the JWARS office constructed a prototype. Since 1997, it
has constructed the first production version, Release 1, and its subsequent iterations. (Beta testing of Release 1.4 began in July 2002.)
Because JWARS will be used to support important decisions, the project
enjoyed the interest of three diverse groups, all of which made significant contri-

PMI-002 11/5

11/6/03

9:20 AM

Page 41

butions in time and intellectual effort


to development and testing:
Senior DoD officials;
User organizations;
Proponents for capabilities to be
represented in the simulation.
Management Oversight
Project success depended on DoD
officials maintaining awareness of
JWARS and on obtaining their guidance. As shown in Figure 1, two committees oversaw JWARS and other
JAMIP activities:
JAMIP Executive Committee.
This Lieutenant General and Generallevel group acted as the senior advisory group. The DPA&E chaired the
committee, at which the OSD, Joint
Staff, services, and Defense Agencies
were represented. The committee met
several times during early stages of the
project.
JAMIP Steering Committee.
This Brigadier General and Major
General-level group provided regular
guidance. The Deputy Director, Theater
Assessments and Planning, ODPA&E,
chaired the committee. Organizations
on the Executive Committee, plus several others organizations, such as U.S.
Special Operations Command and
U.S. Joint Forces Command, were represented on the Steering Committee.
In the early stages of the project, the
Steering Committee met approximate-

ly six times per year; later, it met two to


three times per year.
Requirements
From 1995 to 1998, JWARS requirements were defined and refined by several groups led by the Joint Staff / J-8.
In late 1996, the Joint Requirements
Oversight Council directed that the
requirements be recast as an
Operational Requirements Document
(ORD). That ORD was approved in
August 1998.
Per the ORD, JWARS will be an
analysis tool to support decision-making in four major areas:
Force assessment (and, hence,
force structure);
Planning and execution;
System effectiveness and tradeoff analysis (and, hence, system
acquisition);
Concept and doctrine development and assessment.
User organizations will include
the OSD, Joint Staff, combatant commanders, services, and defense agencies.
Warfare
functionality
requirements are central to the ORD.
At a macro level, the warfare representations must be joint; must be based
on the representation of command,
control, communications, computers,
intelligence, surveillance, and reconnaissance (C4ISR); and must account
for the contributions of the services in
a balanced manner. The statements of
warfare functionality requirements in
the ORD were obtained with assistance

Overall
guidance

Executive
Committee

Routine
guidance

Steering
Committee

Near Term
Enhancements
Joint Staff / J-8
lead

JWARS
Development
PA&E lead

Figure 1. Management Oversight

JWARS Working IPT


PA&E lead
JWARS Study Team
PA&E lead

Joint Data Support


PA&E lead

Field Support
Joint Staff / J-8
lead

from the JWARS office. To permit specification and prioritization of those


requirements, the JWARS office
grouped them into software development threads, each a unit of work in a
particular functional area with a measurable level of effort for JWARS development personnel. Figure 2 displays
the 55 software development threads
that were incorporated in Release 1
and, at the same time, illustrates the
scope of JWARS. (The Iteration column will be explained under Technical
Approach.)
Infrastructure
Funding, billets, contractors, facilities,
and computer hardware, software, and
support are essential to a successful
project.
From 1995 to 1996, funding for
JAMIP and JWARS was obtained from
the Office of the Undersecretary of
Defense (Comptroller). Thereafter,
funding was incorporated into the
Defense Planning, Programming, and
Budgeting System, and is maintained
and administered by the Joint Staff.
The JWARS office was established
as a government organization led by a
team of two civilians and four military
officers. The civilian positions,
Director and Assistant Director, and
the individuals to fill them, were
obtained from the ODPA&E. The military positions were obtained from the
services (one per service) through the
intercession
of
the
Director,
Washington Headquarters Services.
These positions were filled through
standard procedures. Additionally, a
Deputy Director position was filled on
a rotational basis by one of the military officers.
The JWARS office utilized a firm
already under contract with the
ODPA&E to develop the prototype.
Full and open competition yielded two
prime contractors for development of
the production versionthe two contracts were cost-plus-fixed-fee. That version was developed by the two firms
working as one team. Each year, parallel delivery orders were written for the
two firms, wherein each task was
assigned to both firms and one firm or
the other was assigned the lead for the

December 2003 Project Management Journal 41

PMI-002 11/5

11/6/03

9:20 AM

Page 42

Module

Title of Software Development Thread

Strategic
Logistic

Schedule Strategic Transportation Resources(Planning)


Schedule Strategic Transportation Resources (Replanning)
Move Forces from Port of Embarkation to Port of Debarkation (Air)
Move Forces from Port of Embarkation to Port of Debarkation (Sea)
Conduct Theater Aerial Port and Seaport Operations (Initial)
Establish Strategic Transportation Network

1
2
2
2
5
4

Theater
Logistic

Determine Intratheater Movement Requirements


Schedule Intratheater Transportation
Distribute Support to Land-Based Forces
Distribute Support to Sea-Based Forces
Conduct Integration of Units
Posture/Concentrate Forces (In-Place Forces)
Posture/Concentrate Forces (Deploying Forces)
Establish Intratheater Multi-Modal Network
Control Intratheater Multi-Modal Network

4
3
5
5
3
1
2
3
4

Perception

Collect Information and Determine Enemy Course of Action


Assess Operational Level Situation (Initial)
Assess Operational Level Situation (Additional)
Prepare a Collection Plan
Publish Air Tasking Order (for Collection Operations)
Conduct Sensor Operations (Initial)
Conduct Sensor Operations (Additional)
Produce and Provide Intelligence Products
Communicate Information
Maintain and Enhance Communications

1
1
3
2
2
3
4
1
1
1

Operations Provide Target Intelligence


Develop Operational Targets
Exercise Theater Level Command and Control
Exercise Land Command and Control
Exercise Maritime Command and Control
Exercise Air Command and Control
Publish Air Tasking Order (for Defensive Operations)
Publish Air Tasking Order (for Offensive Operations)
Prepare Directives
Conduct Forcible Entry (Initial)
Conduct Forcible Entry (Additional)
Conduct Offensive Land Operations (Initial)
Conduct Offensive Land Operations (Additional)
Conduct Defensive Land Operations
Conduct Land Retrograde Operations
Provide Firepower in Support of Land Maneuver
Provide Close Air Support
Conduct a Naval Blockade
Conduct Surface Warfare
Conduct Under-Sea Warfare
Attack/Interdict Operational Targets (by Air) (Initial)
Attack/Interdict Operational Targets (by Air) (Additional)
Attack/Interdict Operational Targets (Surface-to-Surface Missiles)
Suppress Enemy Air Defenses
Counter Air Attack (Sea-Based Air-to-Air)
Counter Air Attack (Land-Based Air-to-Air)
Counter Air Attack (Surface to Air Defense)
Provide Maritime Theater Ballistic Missile Defense
Conduct Integrated Joint Theater Ballistic Missile Defense
Chemical Defensive Operations
Figure 2. Release 1 Warfare Functionality

42 Project Management Journal December 2003

Iteration

2
3
1
5
2
5
4
5
1
4
5
3
4
2
3
4
4
4
3
4
2
3
5
5
2
4
5
1
5
5

task. This lead role carried with it


responsibility for associated deliverables. Conceivably, this approach
could have led to shirking of responsibilities and finger pointing. In practice,
however, it worked wellthe two firms
coordinated effectively and supported
each other in accomplishing the tasks.
JWARS was developed in government-leased commercial office space
with government-furnished computer
hardware, software, and support. This
approach permitted compensation of
development contractors at government site rates. The facility was located
in Arlington, VA, USA. ODPA&E procured the necessary computer hardware and software. Contractors
separate from the developers provided
computer support, again through the
ODPA&E.
A JWARS user site utilizes a
client-server environment with the
simulation executing on a UNIX server,
and the user accessing the simulation
on a Windows NT workstation through
a local area network (LAN). Because
JWARS input data generally are classified up to the secret level, the servers,
workstations, and LAN must be certified for processing to the secret level.
The JWARS office facility where the
simulation was developed is a largescale version of a user site. It included
multiple UNIX servers, multiple
Windows NT workstations (one or
more for each government or contractor individual), and a LAN. The JWARS
office facility, servers, workstations,
and LAN are classified secret.
Technical Approach
The development process had to permit parallel design and implementation, along with periodic integration
and testing. The approach was selected
and demonstrated during the prototype period, and then refined when the
concept of software development
threads was introduced for the ORD.
The process included OO design and
implementation and parallel development of multiple threads in iterations.
Development was subdivided
chronologically into iterations. Each
iteration involved the development of
a set of threads (typically, 10). Five

PMI-002 11/5

11/6/03

9:20 AM

Page 43

Operational
Requirements
Document (ORD)
Software Development
Threads

Threads
Specify warfare functionality
Functional area-related
Resource-constrained
Relarse 1: 55 threads

Iteration 1
Assignment to Iterations
Sequence threads logically
Balance developer workload

Iteration 2
Iteration 3
Iteration 4

Iteration 5

Figure 3. Overview of the Warfare Functionality Development Process

iterations plus several smaller incremental releases were necessary to


develop the warfare functionality of
Release 1. Figure 3 illustrates how
threads were assigned to iterations. The
actual assignment of threads to iterations is shown in Figure 2. For
instance, the 10 threads identified in
Figure 2 as having Iteration = 1 were
developed during that first iteration.
Figure 4 illustrates the development process for one iteration. For
each thread, development involved
refinement of requirements, high-level
design, detailed design, implementation, and testing at the thread level.
The appropriate code was then integrated and tested, followed by extensive developer testing.
Several aspects of the process displayed in Figure 4 are noteworthy:
Requirements Refinement
was needed because the warfare functionality requirements were stated
only broadly in the ORD. For example, the functionality associated with
thread Collect Information and
Determine Enemy Courses of Action
was specified in the ORD in the intent
statement:
This thread provides the functionality to permit a command and
control headquarters to receive
sensor reports, conduct fusion of
intelligence information derived
from the sensor reports, and to
add, delete, or update information

contained in the command and


control headquarters perception.
The thread also provides the functionality for the command and
control headquarters to perform
an assessment of its perception to
determine the likely enemy
Courses of Action. [Joint Warfare
System (JWARS) Operational
Requirements Document (ORD),
Joint Staff / J-8, August 27, 1998,
p. C-6]
During development, the JWARS
office refined the intent statement for a
thread. The need for such refinement
rendered resource estimation imprecise and risky. In fact, for many
threads, the resource estimates applied
in the original decomposition of warfare functionality into threads were
found, during development, to be
understated.
Design employed a case tool that
adheres to the Unified Modeling
Language. The specific tool, Unified
Modeling Language Designer, supported OO development and provided
multiple viewsobject, event trace,
dynamic, and data flow. This tool provided excellent support to design;
Implementation utilized an OO
languagethe VisualAge Smalltalk
language. It included a virtual machine
interface, just-in-time compilation,
stop-edit-start capability, and a com-

plete development environment. This


language was an effective, efficient
enabler to implementation and testing;
Integration involved combining the
new functionality from threads developed during the iteration with the
code from the prior iteration;
Development included three types
of testing:
Testing of functionality occurred
during implementation.
Testing of overall simulation, to
ensure that it executes properly
with the newly added functionality, occurred during integration.
Extensive developer testing of
the overall simulation, to ensure
that it operated as intended, was
conducted after integration.
The term Problem Domain
applies to warfare functionality for
JWARS. The following are two other
areas parallel to, and facilitating,
Problem Domain development:
Platform Domainthe graphical user interface
Simulation Domainthe simulation infrastructure, including the
Spatial Manager, Movement
Manager, Interaction Manager,
Environment
Manager,
Adjudication Manager, Event
Manager, Data Collection Manager,
and Simulation Manager.
Development Team
Central to development were the
JWARS government staff and development contractor personnel. Figure 5
shows the organization of these personnel.
The following features of the
organization are noteworthy:
The government staff of six (see
top of Figure 5) bought operational
experience as well as modeling and
simulation expertise, to the project;
The Problem Domain Teams
(see left side of Figure 5) developed the
warfare functionality. Based on functional area expertise, one government

December 2003 Project Management Journal 43

PMI-002 11/5

11/6/03

9:20 AM

Page 44

Thread
Thread
Intent
Statement

Requirements
Refinement
- Mission Space
Analysis
- Requirements
Specifications

External
Review

High-Level
Design

Code from
Prior
Iteration

Data
Requirements
Review

Detailed
Design

Unified Modeling
Language
Case Tool

Implementation
and Testing

Integration
and
Testing

JWARS Code

Developer
Testing

VisualAge
Smalltalk
Language

Test Data Sets


JDS Data Support (JDS)
Verification and Validation (V&V)

Figure 4. Warfare Functionality Development ProcessOne Iteration

staff member was assigned to provide


guidance to each team. For example,
the U.S. Army representative to the
JWARS office provided guidance to the
land team. For each iteration, each
team generally developed two software
development threads;

facilitated the development, testing,


and verification and validation (V&V)
of JWARS.

The success of the project was due


to a sound technical approach and an
effective organization. But, more
importantly, it was due to the combined capabilities of a diverse group of
smart, well-trained, dedicated personnelboth government and contractor.

damental. The availability of input


data must be considered throughout
the development process. A scenario
provides the context for input data and
is necessary for testing.
Input data are important to JWARS
development and application. For
development, the availability of data
affects whether a particular design can
be implemented. For application,
study-quality data must be obtained
from appropriate sources. Joint Data
Support (JDS) assisted in identifying
input data requirements, judged
whether such requirements could be
satisfied, identified data sources, provided data for testing, and began the
process of obtaining study-quality
data. The interfaces between JDS and
developer personnel were primarily
through the problem domain teams
and the data architect team (Figure 5).
For Release 1 development
and testing, a major theater warfare
scenario was constructed. For that scenario, JDS supplied most of the data,
and JWARS developers, acting as users,
supplied the remainder of the data.

Data
Input data and scenario are both fun-

User Participation
Many organizations and individuals

JWARS Study Team (Figure 1).


This group, established in 1999, con-

The development personnel


(approximately 50) were drawn from
both of the prime contractors and their
subcontractors. They were, for the
most part, software engineers and
functional specialists. The software
engineers were assigned to the problem domain teams, the data architect
team, and the teams supporting the
software architect. Personnel from
both prime contractors were interspersed throughout the organization.

44 Project Management Journal December 2003

Several groups participated directly or provided individuals who participated:


JWARS User Groups. There were
17 such groups. Each was functional or
area-specific, e.g., land warfare, environment, and contained users and
subject matter experts. These groups
assisted in refining requirements and
then reviewed those requirements
(Figure 4). In some cases, they also
supported design by providing algorithms consistent with the resolution
of JWARS and approved by proponents. Meetings and Internet-based
correspondence were utilized for communication;
JWARS Working Integrated
Product Team (IPT) (Figure 1). This
group oversaw V&V activities and planning for external testing. It met approximately six times per year;

PMI-002 11/5

11/6/03

9:20 AM

Page 45

Government Staff
Contractor
Management Lead
Quality Assurance and
Requirements Management
Problem
Domain Lead

Technical
Manager

Land Team
Maritime Team
C4ISR Team

Joint Cata Support (JDS)

Air and Space


Team

Transportation
and Log Team

Data Architect
Team

System
Architect

Support Teams
Software
Architect

Training Team

Software Integration Team

Scenario
Development

Object Analysis Integration Team

External Support

Platform Domain
Simulation Domain Team

Information
Security

Developer Testing Team

Internal Support

Figure 5. Organization of the Development Team

tained users drawn from future user


sites in the Washington, DC, USA area.
It reviewed and exercised the simulation, examined documentation, and
provided detailed feedback to the
JWARS office in the form of change
requests. It met at least biweekly
through summer 2002.
Test Sites. Beta testing was performed by the future user sites listed in
Figure 6. Members of the JWARS study
team provided the nuclei for test sites
in the Washington, DC, USA area (the
first six sites on the list).
A V&V agent performed V&V for
JWARS. This contractor facilitated V&V
reviews of design products and code by
users and subject matter experts, and
provided results and findings to the
JAMIP Steering Committee.
Evolution of Processes
As development proceeded, several of
the processes described above changed.
Listed here are significant adjustments
that occurred during the period mid2000 through summer 2002.

Development was bid on again


in 2001, this time through the blanket
purchasing agreement contracting
mechanism. The two incumbents were
the successful bidders.

1. ODPA&E Simulation and


Analysis Center
2. Joint Staff / J-8 / Warfighting
Analysis Division
3. Air Force Studies and
Analysis Agency
4. Center for Army Analysis
5. U.S. Navy N-81
6. Marine Corps Combat
Development Command
7. U.S. Central Command
8. U.S. Special Operations
Command
9. U.S. Transportation Command
10. United States Forces Korea
Table 6. Test Sites

Iterations were replaced with


smaller incremental Releases, such as
Release 1.4 that was distributed for
Beta testing in July 2002.
Software development threads
were replaced with smaller units of
work, known as work packages. An
example of a work package is
Incorporate Attack Helicopters.
During development, external
review occurred after high-level design,
rather than before it (Figure 4).
Integration only at the end of
an iteration or at the end of an incremental Release resulted in significant
cross-functional
area
difficulties. Therefore, integration
was performed more frequently
every few weeks.
Insights
This project offers the following
insights that may be applicable to
other large-scale software development efforts:

December 2003 Project Management Journal 45

PMI-002 11/5

11/6/03

9:20 AM

Page 46

Object-oriented design and


implementation for a large-scale simulation development, such as JWARS, is
feasible and practical. For design, use
of a case tool that adheres to the
Unified Modeling Language is effective. The object-oriented design and
implementation process may be applicable to software development projects
for customers other than the DoD, and
for software other than simulations.
Integrating government and contractor personnel in a single development facility yields productive, if
occasionally contentious, discourse
and minimizes surprises. The utility of
this approach for other projects should
be judged on a case-by-case basis.
Involvement of users and subject
matter experts in development and

testing has both positive and negative


impacts. As an advantage, insights on
what must be represented and how it
should be represented are valuable. As
a disadvantage, proponents seek everincreasing detail, which can delay
development and extend runtime.
Again, the utility of this approach for
other projects should be judged on a
case-by-case basis.
Predicting a schedule for development of a simulation with the
scope of JWARS, and with only broadly stated functionality requirements,
is imprecise and risky.
Input data and scenario are fundamental to the development, testing,
and application of a simulation such
as JWARS. This area should have been
given greater emphasis from the

beginning of development. For any


simulation development project,
input data and scenario must be considered from the beginning.
Epilogue
After the author departed in summer
2002, many changes occurred to the
JWARS development project, including:
Beta Testing of Release 1.4, which
had begun in July 2002, was completed
successfully in December 2002. Release
1.5 was distributed to user sites in
September 2003.
A new Study Team was formed
in May 2003, and was charged with
formal testing of the simulation, development of scenarios and data, and performance of a study using the
simulation.

JIM METZGER has been an operations research analyst for 27 years. During that period, he has developed
and applied simulations for the U.S. Army Materiel Systems Analysis Activity, Army Concepts Analysis
Agency (now Center for Army Analysis), and Office of the Secretary of Defense (OSD). From 1995 until
October 2002, he was the Director of the JWARS Office, which reports to the Director, OSD Program Analysis
and Evaluation. He is now an employee of Northrop Grumman Information Technology, serving as a member
of the National Industry Team supporting the Missile Defense Agency.

PMJ WANTS TO HEAR


FROM YOUR COMMENTS
Did you find a recent paper particularly useful to your project management growth?
Do you disagree with an authors viewpoint or have something to share that will further
the message? PMJ welcomes any and all responses concerning content or furthering
a dialogue on project management issues and topics.
All reader feedback that includes references to an article or column should cite the full
authors name, paper title and issue date. In addition, letters must be signed and include
the writers company, title and location for verification of intent. This information will be
withheld upon request. PMJ reserves the right to edit letters for clarity and style.
Make your views known by sending correspondence to pmipub@pmi.org

46 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 47

This article is copyrighted material and has been reproduced with the permission of Project
Management Institute, Inc. Unauthorized reproduction of this material is strictly prohibited.

PROJECT MANAGEMENT IN THE


AGE OF COMPLEXITY AND CHANGE
ALI JAAFARI Project Management Research Programme, Building J05
The University of Sydney, NSW 2006, Sydney, Australia.

ABSTRACT
This paper presents a study of complex
society and its relationship to project
management. The complex society is
characterised by open systems, chaos,
self organisation and interdependence.
Accelerated change drives instability and
chaos following an autocatalytic process.
The conventional project management
approach assumes a world of order and a
predictable environment in which one can
set and deliver a clear set of goals in a
defined manner. The traditional approach
is open to challenge. The author argues
that a paradigm shift in project management is essential for it to be relevant and
effective in a complex society of this century. Research is needed to further define
a fresh understanding of project management and how it that can respond to the
challenges of the complex society. This
necessitates working globally to advance
the field.
Key words: complexity theory, open
systems, chaos, project management

2003 by the Project Management Institute


Vol. 34, No. 4, 47-57, ISSN 8756-9728/03

omplex society is a state of society in its evolution that sociologist call


take-off stage. It exhibits the following characteristics:

Open systems. A complex society is made of a complex web of interacting open systems that are subject to instability and in throes of constant
change within of an Internet like network of interconnections and interrelationships;
Chaos. The complex society is affected by uncertainties that are beyond
long term contemplation and thus defy the classical management approach of
orderly planning and control. Social systems change when the conditions are
right following an autocatalytic process;
Self-organisation. In a complex society the tendency is for self organisation to take place following the autocatalytic process leading to autonomous
organic (self steering) organisation units, based on insights and competence
of the actors as well as synergy, flexibility and teamwork; and
Interdependence. The growth of interdependence makes it increasingly
difficult, if not impossible, to make any predictions on the basis of previous
experience. Thus, it is important to avoid development and use of a linear
reductionist model for forecasting the behavior of future events.
These characteristics illustrate the rising complexity in the society that
stem from rapid technological, social, economical and global change, considered by many as irreversible (Geyer, 1998; London, 1996). The science of
complexity has shown that systemic change is not a mechanistic, progressive,
and linear phenomenon whose causes and effects can be clearly isolated.
The science of complexity has now developed to the extent that it is
applied to many fields such as natural and social sciences, management and
the arts. For example, Tyson (1998) argues that it has changed the worldview
of science in all spheres including social sciences. There is a growing body of
literature on this subject and a number of Internet portals serve the interests
of the research community (e.g.http://www.brint.com/Systems.htm).
CIO Magazine in its issue of 15 April 1998 (as quoted in the above portal) states: However, most traditional management literature has focused on
control as a means of compliance instead of self-regulation and self-control
and on extraneous rewards and incentives instead of intrinsic motivation.

December 2003 Project Management Journal 47

PMI-002 11/5

11/6/03

9:20 AM

Page 48

However, a better understanding of


autonomous human behavior underpinning individual, group and social
interactions is required for appreciating the notions of self-adaptive and
emergent systems. (CIO, April 15,
1998, quoted in the above portal)
Knowledge-Based Society and Change
Knowledge-based society is the manifestation of the accelerated technological, social and economic change
embodied within a complex society.
While change has been in progress
since the dawn of creation, it has seldom been felt so drastically as in current times (Geyer, 1998; London,
1996). In the past, the rate of change
was rather slow, so in a persons lifetime change was virtually imperceptible. But now in a lifetime one
experiences significant change influencing all aspects of life. Change is
not only here to stay, but the rate of
change itself is increasing, also as a
result of increasing global interdependence in all imaginable areas of
human activity, and shows no signs of
ever slowing down. This leads not only
to change in existing procedures, institutions, ideologies, etc., but also to the
emergence of completely new phenomena in the present information
age. (Geyer, 1998:2)
The modern society has come a
long way from that which existed
200 years ago at the dawn of industrial revolution (Kelly, 1997). The
rate of change will accelerate even
further as the boundaries between
national and global economies will
merge and as the free trading blocs
will evolve into integrated social and
economic communities, such as that
of European Union (Jaafari, 2001). A
look at the economies of advanced
nations is most revealing in comparison with the smoke stacks of the
19th century, as articulated by Sorrell
(2001):
People and organisations producing wealth from innovation and
ideas, intellectual property, workforce
competencies, research and development, rather than wealth production
being primarily dependent on the control of physical or financial assets

48 Project Management Journal December 2003

Information and communications


technology driving both economic and
social growth (and productivity)
The creation of web-like value
chains in a global marketplace rather than
linear, geographically narrow value
chains. Increased opportunities for export
and greater availability of imports.
An increase in the trade of intangible goods and services (know how,
design, branding etc) and increased provision of customised as opposed to commodity goods/services.
A regulatory environment which
encourages people and organisations to be
entrepreneurial, to innovate and to takeup technological advances.
Capital markets which value innovation and know-how and actively stimulate growth in this area of the economy
Change has thus transformed and
continues to transform the world in
which we live. How can we understand
and model change? Without a proper
perspective on change as a phenomenon we cannot understand what possible role project management can play
in the complex societies of the 21st
Century and how the less advanced
societies can be assisted in their quest
to achieve accelerated economic and
social progress.
Herbert Spencer, Karl Marx, and
August Comte have all subscribed to
an evolutionary view of change
(London, 1996). These authors conviction of irreversibility of change was
typical of the late 19th Century widely
held scientific belief that progress was
natural. Commenting on the contemporary view of that time, London (1996:3)
states: The dynamic force in progress was,
like that in biological evolution, the competitive struggle for existence in which the
fit survive and the unfit perish. This interpretation of social change was especially
popular among the so-called Social
Darwinists (even though Darwin himself
was no Social Darwinist and Spencers
theory of social evolution preceded
Darwins theories of biological evolution
by several years.)
A study of change as a phenomenon will bring with it the question of
who directs the change and what sort
of reaction it generates among those

who experience change. The theory of


complexity has shown that change
takes place spontaneously and as a
result of what is referred to as an autocatalytic process.
The concept of autocatalytic
process generating change is rather
new and relates to Prigogine and
Stengers (1984) and later Kauffman
(1991, 1992 and 1995) and a number
of other researchers working at the
Santa Fe Institute. The advent of the
new science of complexity has been
largely attributed to Prigogine, a
noble laureate in Chemistry in 1977,
who in his landmark book: Order out
of Chaos explored the nature of
change through dissipative structures which are nowadays referred to
as open systems.
Researchers since have found that
there are surprising similarities
between natural and social systems
when it comes to the study of change.
The science of complexity postulates
that the advent of life and evolution of
biological complexity from simple
organisms to what can be observed
today, were not the product of chance
but as part of a natural evolutionary
order following the autocatalytic
process.
Geyer (1998:3) states: Under an
autocatalytic process simple chemical laws
coupled with the presence of a sufficient
number of frequently interacting elements
produce ever more complex elements, with
new characteristics, that often turn out to
be part of new catalytic processes at higher levels of molecular complexityprocesses which in turn boost the emergence of
still higher levels of complexity.
The economist Arthur (1990), collaborating closely with Kaufmann at the
Santa Fe Institute, applied the concept of
autocatalytic sets to the economy: the
economy too bootstraps its own evolution,
as it grows more complex over time.
Beyond a certain critical threshold, phase
transitions occur; stagnant developing
countries can enter the take-off stage when
their economy has diversified sufficiently.
Increased trade between two countries in a
subcritical state can similarly produce a
more complex and interwoven economy
which becomes supercritical and explodes
outward. Catalytic effects might also oper-

PMI-002 11/5

11/6/03

9:20 AM

Page 49

ate in phase transitions that are considered


negative, where critical thresholds of violence are passed as in Northern Ireland or
Bosnia.
Thus, according to the autocatalytic view, economic and social
orders both cause and experience
change and that what we observe and
measure in a particular time is a snapshot of what otherwise is a continuum
of evolution. Change is always at
work, chiseling at the base of stability
of a system and preparing the system
for a sudden and rapid shock, called a
phase transition.
Examples of phase transitions
can be observed in nature, e.g. when
ice reaches the melting temperature
it turns into water, which in turn
converts into steam when it reaches
the boiling point. While we only see
the sudden change of water turning
into steam, the reality is that water
molecules would have been heated
continuously thus paving the way
for a phase transition at a critical
point. This analogy applies to social
systems, driven by technological,
political and social catalysts.
Perception of Complex Society
The contemporary view in sociology
is that there is an outside reality (i.e.
as opposed to what is residing
inside peoples mind) but not necessarily an objective reality, and that
individuals, depending on their
mental models, normally perceive
this reality in their own way. (Geyer,
1998) Mental models are observerdependent, time-dependent and
problem-dependent. In addition to
these dependencies and to grasp the
complexity of the environment, a
certain amount of internalization of
the outside reality or complexity
reduction of the environment is
needed. This is a function of the
competency of the individual concerned. Luhmann (1978 and 1986)
calls this a complexity differential
between the individual and the
environment. If this reduction is
not optimal, then the observer
views the world either too complex
or too simple, both of which may
lead to sub-optimal reactions.

Responses to Societal Complexity


How does an accelerated change (and
rising social complexity) influence the
society as a whole or the individual
and groups within it? Research has
shown that increased social complexification has resulted in increased selfreference at individual level and a rise
in self-organisation at group level.
(Geyer, 1998; Kirshbaum, 1999)
Individual Self-Reference
Self consciousness or self reference is
a natural human trait which can be
enhanced through linguistic abilities
for codification of information, internalization and processing of the same
and subsequent communication and
reflection. Self reference is on the rise
and as a reaction of individuals to the
rising environmental complexity. Self
reference assists an individual to
develop capabilities to understand
and digest environmental complexity
and to apply an appropriate degree of
environmental complexity reduction
internally in order to better handle
external complexity and uncertainty
in decision making. Geyer (1998)
states that self reference is on the rise
in tandem with rising environmental
complexity.
Normally those who have developed a high degree of self reference are
those who thrive on change and have
developed adequate capacity to handle environmental complexity. These
are the people who will not only be at
the forefront of change, but will be its
driving force, adapting quickly to new
circumstances they have themselves
helped to create. Usually, they come
from the rich countries, have had a
nurturing early-life environment, and
have a high degree of education. Self
reference can be further developed
through reflective learning and evaluation of the behavior (or feedback)
from the immediate environment to
ones internal model; the latter being
updated regularly in response to a rapidly
changing
environment.
Development of reflective practice is a
long process and requires a high level
of education and professional development, not normally attainable
through short term training.

Group Self Organization


At group level, autonomous organisations tend to grow both as a natural
response to the environmental complexity and due to individual complexity reduction capabilities. Self
organisation runs opposite to hierarchies. Geyer (1998:9) states that:
However, like the iterative sequence of
variety-selection-stabilization has become
a more or less accepted paradigm in evolutionary studies, societal evolution likewise
seems based on, first, proliferation of variety (i.e. self-organization), then selection
of those self-organized units that can stand
the test of time, and finally emergence of a
new hierarchical level to coordinate these
self-organized units.
Sociology has always been rather
ambivalent about hierarchy, and an
important issue in social science has
always been whether one should opt for
the katascopic or the anascopic view
of society; in other words, should the
behavior of individuals and groups be
planned from the top down, in order for a
society to survive in the long run, or
should the insight of actors at every level,
including the bottom one, be increased
and therewith their competence to handle
their environment more effectively and
engage more successfully in goal-seeking
behavior?
Chin and Benne in their classic
textbook: The Planning of Change
have offered 3 approaches to triggering
change or as they call these general
strategies for effecting changes in
human systems: rational-empirical, normative-reeducative and power-coercive
The rational-empirical approach
states that provided the appropriate
conditions are in place, people will
behave rationally and will embrace
change. Chin and Benne offer the following strategies to effect change
under a rational-empirical approach:
Provide the right information,
education or training to allow individuals to change of their own volition.
Ensure that the right people
are in the right place to bring about
needed changes.
Invite the perspectives or expertise of outsiders.
Engage in research and
development.

December 2003 Project Management Journal 49

PMI-002 11/5

11/6/03

9:20 AM

Page 50

Promote utopian thinking to


stimulate creativity and best-case
scenarios.
Clarify the issues and/or reconceptualize the situation in order to
bring about greater overall understanding among members of the group.
The normative-reeducative approach
is founded on the assumption that
change begins from the bottom up,
not top down. Under this approach it
is appropriate to focus on changing the
individuals who make up a social system. Chin and Benne offer the following strategies for applying this
approach:
Improve the problem-solving
capacities of a system by encouraging
individuals to be self-diagnosing.
Release and foster growth in the
persons who make up the system.
The third approach, power-coercive is for effecting change through
political movements and social
activism. Strategies offered by Chin
and Benne are:
Using political institutions to
achieve change.
Shifting the balance of power
between social groups, especially ruling elites.
Weakening or dividing the
opposition through moral coercion or
strategies of non-violence.
The recent trend is for self organisation to proliferate in tandem with the
increased environmental complexity.
Witness the rise of SMEs and their economic
influence
in
advanced
economies of the world. As a matter of
fact, the growth of self organising units
within clusters of such units in
advanced economies is taken as indicators for economic strength in this century. Kotkin and Devol in their book
The Renewed City in the Digital Age
(2000) state Under the new regime of
geography, wherever intelligence clusters
small towns, big city or any geographic locationthat is where wealth will
accumulate. Such concentrations are far
less constrained by traditional determinants
such as strategic location near waterways or
raw materials, or by the proximity to dense
concentrations of population. (quoted in
http://www.livable.com/Programs_pag
es/CCResourcePaper.htm)

50 Project Management Journal December 2003

However, self organisation is not


confined to new and technology-based
enterprises. It is a post-war phenomenon and appears to be the basis for
advanced societies functioning more
efficiently and effectively. The role of
governments has changed to that of
facilitator not driver of economic and
even social progress.
Self organisation in management
manifests itself mostly in the form of
learning organisations in the sense
that these are self-designing, selfassessing, self-renewing and entrepreneurial organisations. (Senge, 1990;
Kanter, et al, 1992) Learning organisations are flexible and open. Systemic
change occurs simultaneously and synergistically, based on the competence
and perceptions of individuals, teams
and larger groups and in response to
environmental change. Has there been
a huge rush to embrace the concept of
learning organisations in management? The reality is that learning
organisation is little understood or
applied in a meaningful way. Most
organisations are reluctant to embrace
change unless these are externally driven. (Kanter et al, 1992).
A learning organization is one in
which five learning disciplines are continually pursued: personal mastery,
improving individual mental models,
building a shared vision, team learning
and thinking systematically. According
to Senge (1990), the fifth discipline
systems thinking ties all these disciplines together. Senge (1990) notes
that the really significant and enduring
innovations he has observed have
grown out of people from multiple
constituencies working together. In
education, for instance, its been a few
committed teachers with some bright
ideas, in concert with a principal who has
a particular view of his or her job, in concert with a superintendent who is in line
with that principal, and in concert with
people in the community who are very
much part of the innovation process.
(London, 1996)
Self organisations can function in
response to complex rules and principles, ranging from the constitutions
of nations through to fiscal and economic policies and regulations of

regions, or social and civic codes of


communities and self-imposed moral
standards or ethics. It appears that
these self-organising groups of people
form the building blocks of a knowledge-based society.
Individual Behavior and Response
to Change
According to Geyer (1998:5) people
can be classified into 4 basic types in
terms of their responses to change:
those who thrive on change; those
who try to abstain from change as far
as possible; those who resist change;
and those who experience change
unknowingly and somehow cope with
it or are oblivious to it. Obviously it is
possible for a person to experience or
exhibit more than one type of response
during his or her life. Also, humans
can exhibit more than one reaction to
complex situations, depending on
their mental models, information and
media manipulation, social norms and
accepted standards, peer group pressure or group think phenomenon.
Nevertheless, the classification offered
by Geyer is very useful in the sense that
it provides an insight into, and an
explanation of the underlying causes
for the social, political and economical
tensions that currently beset the world.
Table 1, developed by the author,
contains a detailed point comparison
of the 4 types of people in terms of
their behavior and reaction to change.
As seen, the ideal advanced knowledge-based society is the one whose
members are partial to change and
possess considerable social and economic skills. That is a society based on
well-educated, self-organising, competent citizenry, not on tribalism or religious affiliation or ethnicity. This is
hard to achieve when even in the case
of advanced societies the majority of
the population tend to be uncomfortable with change, withdrawing from
the complex society as far as they can.
Hofstede in his book Culture and
Organizations: Software of the Mind
(1991) states that basic human mental
programming
determines
our
approaches to personal relationships,
business transactions and management. He developed the Lily Pond

PMI-002 11/5

11/6/03

9:20 AM

Page 51

the large scale issues over which they


cannot
have
any
influence.
Sometimes they are referred to cynically as the silent majority. While
they pose no immediate danger to
societal stability their apathy can be a
threat to the long term evolution of
the society (Geyer, 1998).

Behaviour

Attitudes/beliefs

Values/basic programming

Unquestioned assumptions:
What is right and wrong/ethics.
Figure 1. The Lily Pond Model (Hofstede 1991)

model (Figure 1) to provide a visual


representation of the interrelationships. Values are based on the
ingrained assumptions about what is
right or wrong. He found that the
underlying human assumptions are
based on family, education, linguistic,
gender, social, regional, religious and
ethnic backgrounds (cultural and family influences). Values influence the
attitudes and perceptions, which in
turn influence our behavior.
Of course, what is seen is the surface of
the pond or our exhibited behavior; what
should be taken into account in any cultural transformation studies is the entire value
system. Thus, early socialization plays a key
role in personal formation and development. The agents of socialization include
the family, school, peer groups, the media
and religious and political institutions.
These agents make individuals aware of
what is acceptable behavior and what constitutes the norms, values and the prevailing culture of their society.
One has minimally to take into
account ones programming through
early-life socialization, the myriad subjective filters, prejudices, experiences, etc.
which one has accumulated in the course
of a lifetime, and has to reckon also with
the limited factual knowledge and computing capacity of the human brain
which can hold only so many variables
simultaneously. (Geyer, 1998:5)

Considering the complex society,


the relentless pace of change, the
unequal division of affluence, wealth
and opportunity around the globe,
what should be the role of project
management at both individual and
organisational levels?
Take the example of stakeholders
management. An essential project
management competency must surely
concern the assessment and effective
management of the different types of
reaction that change can generate, in
the context of a project or a business
unit operation. The literature on stakeholders management (c.f. Manivong,
2000) holds that managing stakeholders is no more than devising a process
of engaging and effective communication with the stakeholders. This
process management perspective
implicitly assumes that all stakeholders are Type 1 persons and embrace
change easily.
The majority of the people, even
in the advanced societies of the West,
are not interested in active involvement in the life of their communities.
They seek gratification from involvement in niche areas of their interest,
sports, arts or things that they can
relate to and or receive an immediate
feedback from their engagement.
These are Type 2 people who feel it is
pointless to involve themselves with

Project Management in the


Age of Accelerated Change
In many countries of the world where
the dominant view is that of strong
religious or cultural affiliation, there
will be a predominance of Type 3 persons, who not only resist change but
may in fact mount a concerted battle
against it. Thus, there may be inherent
resistance to any project that threatens
the traditional values of the affected
communities or the power base of
their leaders. How should project
managers approach change in this type
of setting?
Type 4 persons are also of contemporary concern, as they are normally
the forgotten people of the third world
whose focus is on survival, finding
enough to eat or shelter for themselves
and their families. They are neither
aware of nor in a position to influence
their society. How should project managers approach projects in these and
any other disenfranchised sections of
the world communities?
The example of stakeholders
management highlights the complexity of project management in a complex
society and management of change.
Contrary to the common belief that
project management is the tool to
change management, there is no evidence to suggest that the current models of project management are capable
of assisting change management or
aiding planning, creation and delivery
of complex value chains globally. One
thing is clear: a classical approach to
management of projects as taught in
project management courses or
espoused in the literature, may have a
limited utility on the face of accelerated change and increased complexity.
The prevalence of failure currently
experienced on many technologybased projects has been studied widely
and found to be generally related to

December 2003 Project Management Journal 51

PMI-002 11/5

11/6/03

Point

9:20 AM

Page 52

Type 1

Type 2

Type 3

Type 4

(Nerds)

(Average citizens)

(Fanatics, extremists)

(Outcasts,downtrodden)

Character

Reflective, aware &


attuned to the
surrounding
environment, in
search of new
information &
experiences, outcome
focussed, goal driven
behaviour

Introvert, withdraws
from complexity,
limits confrontation
with change, seeks
simplistic pursuits,
likes quick response
from own actions,
feels cannot influence
complex situations

Reactive, resists
change, follows
group thinking,
threatened by
complexity, in search
of pure ideologies,
character defined by
absolute beliefs, as
in religion, driven by
hate

Un-involved,
disinterested, not
concerned with
change or passively
accepts it,
submissive,
downtrodden, feel
not counted or
accepts exploitation
& abuse of all sorts

Capability

Leading change,
competent in the
application of
professional tools and
techniques, competent
to practice in a field of
endeavour, possesses
social cultural
competencies

Competent in narrow
areas, e.g. simple
intellectual tasks or
trades. Able to read
and write but not to
understand the
complex societal
issues over which
they feel have no
control

May have expertise


in a field but
generally not
worried about
keeping up to date,
guided by
fundamentalism in
all spheres of
activity, generally
engages in antiestablishment
activities

Not generally
articulate, no
definitive skills,
mostly engaged in
subsistence living,
concerned with
immediate survival
issues of food and
shelter

Approach

Open minded, follows


an open systems
thinking, mental
models are time,
problem & observer
dependent

Superficial, finds it
easier to follow
dominant lines, open
to manipulation,
follows simple and
ingrained mental
models

Follows oversimplistic philosophies,


fanatical as of
religious extremists,
white supremacists,
or other similar fringe
groups

Mostly fatalistic,
accepting
wretchedness as
natural, feeling
powerless, follows
survival instincts

Criteria

Fitness of purpose,
fitness for purpose,
value, harmony in
relationships, personal
ethics, resolution of
conflicts, faith

Emotional & socioethnic bias, closed


value system, seeks
immediate feedback,
ok to live with high
ambiguity, wary of
change

Blind belief in own


ideologies, absolute
and resolute in ones
righteousness,
guided by group
reaction & engage in
endorsed activities

Survival and keeping


alive, not overly
concerned with
criteria as feels
powerless to change
own destiny or the
environment

Self reference

Changing & renewing


own mental models,
aware of and self
referential

A low degree of self


reference as relates to
interaction with a
small circle of friends
and work mates, in
pursuit of hobbies

Non-existent as one
is guided by others
expectation,
standards,
established wisdom
and an absolute truth

Practically nonexistent, guided by


social order and class
systems (as in India),
knows own place in
the society

Development

Normally from a rich


country, well educated
& enculturated, well
nurtured family,
professional
development,
independent thinker
and learner

Forms possibly the


majority in Western
democracies, well
schooled but not
empowered, may even
be a professional
society member,
highly dependent
thinker & learner

Normally from
developing countries
with low education &
formation, strong
religious and ethnic
enculturation, or
extreme groups in
developed countries
with low education &
no proper formation

Normally from third


world countries
without even basic
education, health or
other developmental
benefits taken for
granted in developed
countries

Table 1. Characteristics of 4 types of People in terms of Reaction to change

52 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 53

managerial approaches to the human


and organisational factors rather than
technology, per se. Many IT/IS projects
are highly complex projects that seek
to transform organisations in a profound way. The author submits that
this is a manifestation of the failure of
the contemporary project management
model to respond to the challenges
faced by this class of projects.
The Four Types of Project
Management Models
In this paper, the author uses the term
model to refer to the underlying
approach or philosophical framework
that guides the formation of professionals (professional development)
and their approach to planning and
management of projects (professional
practice). The author has used the
environmental complexity and project
managers capability in complexity
reduction (including stakeholders
management) to define 4 typical
approaches or models as shown in

dynamics of the complex society.


Essentially this classification reflects
the evolution of project management
over time and in response to rising
environmental and project complexity.
Type 1: Ad-hoc Model
This approach was typical when project management was not recognised as
a systemic approach and when organisations used to apply ad-hoc methods
to achieve their desired outcomes. At a
time when both environmental complexity and project complexity were
low, projects could be defined as
departmental initiatives and handled
informally by any person who happened to be closest to the action without any due concern about the
persons competence or management
of environmental complexity. Most
professionals who landed this role
were (and some still are) accidental
project managers. They tended to use
their experience and intuition to steer
the project to a conclusion.

High
Low

Project Complexity

Environmental Complexity
Low

High

Normative model

Creative-reflective
model

Ad-hoc model

Bureaucratic model

Figure 2. Broad Classification of Project Management Models

Figure 2: (1) ad-hoc model; (2)


bureaucratic model; (3) normative
model; and (4) creative-reflective
model. This approach enables us to
identify whether or not the contemporary models of project management
are capable of responding to the complex society and also whether or not
approaches to professional development of project managers reflect the

Type 1 model is prone to conflicts.


On the face of observed unacceptable
deviations in project functionality or
cost or duration, the search for the
guilty party will begin and normally
end up in messy and protracted litigations. The premise in this methodology is that all facts are known and
project deviations are the result of
default on the part of the participants

in the process.
This model of project management is typically characterised by
absence of any formal systems and or
consideration of the competence of the
individual players. Most decisions and
the rules are made on the run, and
decision makers positions can vary
considerably depending on their gut
feelings of the situation.
Type 1 approaches work when the
environmental complexity is rather
low and when project is also simple
enough that the players can get their
minds around it and or the project is
really of a similar line. Figure 3 shows
its limitations.
Type 2: Bureaucratic Model
This approach is common on many
public sector projects and undertakings. It is the next step in the evolution
path and a reaction to the often spectacular project failures under the previous models when significant
complexities are present. Many organisations have typically sought to influence the project outcomes by
imposing bureaucratic controls,
involving over-elaborate procedures,
administrative processes, approvals
and maintenance of records. Typically
the project is run for full bureaucratic
compliance rather than for achieving
optimal results. Such approaches tend
to be either overcomplicated and or
oversimplified, both of which are due
to the managers inability to apply an
appropriate degree of environmental
complexity reduction and or due to a
set of rigid organisational policies and
methodologies.
The author speculates that project
managers of this approach are typically those who resist change and despise
environmental complexity intruding
their routine decision making and
operational freedom. They are in
search of stability and imposition of
order (command and control) mode
of management. They feel that their
power base can be threatened by the
introduction of change and or deviation from established procedures. This
model has a lot to do with maintenance of power and imposition of control than good management practices.

December 2003 Project Management Journal 53

PMI-002 11/5

11/6/03

9:20 AM

Page 54

POINT

MODEL A

MODEL B

Character

Technical, logical; problem-solving

Creative, interpretive; design

Capability

Solvable, convergent problems

Congruent futures; messes, problematic


situations, divergent problems

Approach

Solving problems; applying knowledge


competently and rationally

Understanding problematic situations and


resolving conflicts of value; framing and
creating desired outcomes

Criteria

Logic, efficiency, planned outcomes;


cause-effect, proof

Values, ethics, congruence of both


methods and outcomes; systemic
interrelationships, theory, faith

Epistemology

Objectivism: knowledge is stable and general;


precedes and guides action

Constructivism: knowledge is transient,


situational, personal and unique; both
informs action and is generated by it

Validation

By reference to others expectations:


standards, accepted wisdom, established

By questioning fitness for purpose,


fitness of purpose and systemic
discourse; truth validity; value

Thinking

Primarily deductive / analytical; sceptical of


intuition

Inductive, deductive and abductive;


uses intelligent intuition

Profession

A bounded, externally-defined role,


characterised by norms, values and a
knowledge-base common to the profession

A portfolio of learningful activity


individual to the practitioner,
integrated by personal identity,
perspectives, values and capabilities

Professionalism

Objectivity, rules, codes of practice

Exploration of own and others' values,


personal ethics, mutual enquiry,
shared expectations

Professional
standards

Defined by the employer, professional body or


other external agency according to its norms

Negotiated by the participants and


situation in accordance with their
and values other stakeholders in the
practice values, beliefs and
desired outcomes

Professional

Initial development concerned with acquiring


development knowledge, developing
competence and enculturation into the
professions value system; continuing
development concerned with maintaining
competence and updating knowledge

Ongoing learning and practice through


reflective practice, critical enquiry
and creative synthesis and action;
continual questioning and refinement of
personal knowledge, understanding,
practice, values and beliefs

Table 2. Point Comparison between 2 Principle Models of Professionality (Lester 1994)

54 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 55

Environmental Complexity

Very
High

High
Type 4 Creative-Reflective

Medium
Type 3 Normative

Low

Type 2
Bureaucratic

Type 1 Ad-hoc
Low

Medium

High

Very High

Project Complexity
Figure 3. Schematic Comparison of 4 Models of Prject Management in terms of Complexity

Most practitioners of this model work


with the same model, irrespective of
the nature of their projects.
As with the Type 1 model, the
capacity of this approach to handle
both environmental and project complexity is really limited; at best it can
work when both environmental complexity and project complexity are in
the range of low to medium (Figure 3).
Type 3: Normative Model
This type is the contemporary model
of project management (the so-called
best practice model), which according
to Lester (1994) falls within Type A of
professions that are technical / bureaucratic in nature and knowledge-based
(the Industrial Revolution model,
embracing both the professionalisation of the mediaeval trade guilds and
the 20th century managerial professions). Based on the work of Schn
(1983) and Fish (1995), Lester (1994)
has defined the normative model as
Model A professionalism (see Table 2
for details).
This model works best when the
environmental complexity (or extent
of uncertainty) is low and when project managers are able to apply an opti-

mal degree of environmental complexity reduction. Type 3 is the rational


approach and assumes that there is
sufficient certainty and stability in
environment that it will be possible to
define a set of goals and a framework
for orderly planning and delivery of
projects. Nearly all published bodies of
knowledge, approach by professional
bodies and their certification schemes
underlie this model.
The Type 3 model has a limited
capacity in handling environmental
complexity though it can handle a
high degree of project complexity
(Figure 3). Its limitation has already
been reflected in reported project failures in complex IT and software systems, new complex products and
organisational transformation (to
name a few).
Type 4: Creative-reflective Model
Type 4 is well suited to projects that are
typically conceived and delivered within a complex society. It relies on the
ability of professionals to apply an
optimal degree of environmental complexity reduction to handle a high
degree of uncertainty and even thrive
on the edge of chaos. This model relies

on the principles of self organisation


and the insights and competence of
the players in the project value chain.
Practitioners in this model are empowered individuals, who possess a high
degree of self-referential skills and are
partial to change. Their functions transcend that of a rational process-driven
approach to that of a creative approach
through which they are able to achieve
breakthrough solutions to optimally
respond to both environmental and
project complexity.
Project managers are necessarily Type 1
people when it comes to handling
complexity and change. Geyer (1998:5)
characterizes them as follows:
1. They will be fully aware that their models are observer-dependent, i.e. they are
open to new information from those with
different models, and will engage in a sufficient amount of self-reference to be at least
roughly aware how their own models have
originated, depending on their early-life
conditioning, subsequent socialization and
resulting psychological make-up;
2. They will be sufficiently flexible to realize that their models are not eternally
valid, but time-dependent, and therefore
should be updated regularly as new information becomes available, or is even
actively sought;
3. Realizing that their models are also problem-dependent, they will certainly not strive
to obtain a single, monolithic model of their
world, but will develop a set of different
models to deal with different situations.
Lester (1994) refers to this class of
professionals as Model B. He has provided
an interesting point comparison between
the normative (Model A) and creativereflective (Model B) included in Table 2.
Creative-reflective project managers are not necessarily members of a
particular professional body, but those
who engage in lifelong learning and
continuous personal development, act
autonomously, believe in shared values and follow strong personal ethics.
Preparation of Individual
Project Managers
The emergence of the complex society as a manifestation of rapid and
irreversible change signifies that
models for project management
preparation cannot be based on past

December 2003 Project Management Journal 55

PMI-002 11/5

11/6/03

9:20 AM

Page 56

practices, as the bandwidth within


which an appropriate degree of environmental complexity reduction can
be applied is moving in parallel to
the rise in environmental complexification. As was put by Jarvis (1983)
using a list of empirically-derived criteria without an underlying theory can be
arbitrary (and provides rules based on
past practices rather than principles
applicable to future ones).
Robinson (2000) argues that a
new style of leadership- dubbed transformational leadership-, is emerging in
order to allow individuals and organizations to thrive at the edge of chaos, inspiring the innovation and creativity needed
to develop new products and technologies,
even new business models that can lead to
sustainable competitive advantage in the
new economy. The context for transformational leadership includes a kind of
visionary acumen that can articulate winning and success in a way that captures
the imagination of others. In doing so,
like-minded contributors can be invited to
add their views to amplify the meaning
and purpose of the company such that
everyone is inspired to do their best work
and serve the greater needs of the enterprise and its customers.
The author postulates that the
transformational leadership is reflected in the creative-reflective approach
to management of projects, and that
development of project managers
needs to change from the current preoccupation with learning techniques
for the application of the so-called best
practice to competency for management of both project and environmental complexity. The professional
competence of the project managers
must thus be the basis for the determination of optimal approach to projects, based on the extent of
environmental and project complexity
and within a flexible framework. As
seen, in addition to the core emphasis
on creative-reflective skills, leadership
and socio-cultural competencies
become critical, compared to planning
and control competencies emphasised
in the normative project management
literature and practice (Lester, 1994;
Robinson, 2000).
Empirical research is needed to

56 Project Management Journal December 2003

shed light on the proportion of project


managers in each category in terms of
reaction to change and also project
management models subscribed to.
The authors experience in the development of project managers through the
graduate programme at The University
of Sydney and numerous research
work undertaken suggest that the current models for professional preparation and certification tied to the
normative approach are ill-suited to
the emerging complex society.
The Need For International
Collaboration In Research
The emergence of the sciences of complexity as studied in this paper brings
with it the question of project management relevance in the age of open systems, chaos, self organisation and
interdependence. The author put forward a progressive perspective of project management evolution and argued
that the creative-reflective model is
best suited to handling complexity and
chaos. However, this model is not
known as the contemporary view of
project management is that of a rational and normative approach driven by
techniques.
As noted the normative approach
cannot handle environmental complexity well. There is an acute need to
develop the creative-reflective model,
including the relevant bodies of
knowledge that enable management of
projects in the age of complexity. The
same sort of concerted multi-disciplinary efforts that led to the creation of
the sciences of complexity at Santa Fe
Institute in the latter part of the 20th
Century needs to take place in project
management to develop the creativereflective model of project management. This is the reason for the author
advocating international collaboration
and coalition of institutions to
advance project management body of
knowledge and mindsets to their next
level of development.
Conclusions
The author attempted to present a
study of change and its relationship to
rapid growth of complex society following the autocatalytic process as part

of the new sciences of complexity.


Research has confirmed that generally
speaking the world is subject to an
accelerating rate of change and that the
emergence of the complex society is a
stage in the process of continual evolution. This stage has been referred to as
a take-off state, exhibiting instability
and chaos and characterised by open
systems, self organisation and interdependence. Individuals react differently
to change depending on their internal
model and the context and time. In
addition, rapid rise complexity has
given rise to a rise in self reference and
self organisation. Not everyone perceives the complexity in the same manner even when the context remains the
same. Each person needs to apply an
appropriate degree of complexity
reduction to understand and internalise an image of environmental
complexity.
Project management is supposedly a systemic approach to management
of change but its foundation lies in the
traditional rational managerialism
thus facing an increasing threat of irrelevance unless newer models are developed to respond to change and
complexity. The author has put forward a concept for a creative-reflective
model that is effective in the age of
complexity. The elements of this
model as yet remain to be researched
and developed.
References
Arthur, W. B. (1990), Positive
feedbacks in the economy. Scientific
American, February, 92-99.
Chin, R. and Benne, K. D. (1985).
General strategies for effecting change
in human systems. in Warren Bennis
et. al. (eds.), (The Planning of Change,
New York: Holt, Rinehart, and
Winston, 1985. 528) 22-45.
Fish, D. (1995). Quality learning
for student teachers: university tutors
educational practices London, David
Fulton.
Geyer, F. (1998). From simplicity
to complexity: adapting to the irreversibility of accelerating change.
14th World Congress of Sociology,
Montreal, July 26 - August 1, 1998
WG01 Session 13 (see also:

PMI-002 11/5

11/6/03

9:40 AM

Page 57

http://www.unizar.es/sociocybernetics/chen/pfge12.html).
Hofstede, G. (1991). Cultures and
Organizations: Software of the mind.
Maidenhead, Berkshire, UK: McGrawHill Book Co.
Jaafari, A. (2001). Project management and the third revolution: can we
deliver? PM-Research
Conference
Proceedings. 21 22 November 2001,
Vienna, Austria. PM Group, Vienna
University of Economics and Business
Administration, Vienna, Austria, 8.
Jarvis. (1983) referred to in Lester,
S. (1994). On professionalism and
professionality,
published
at:
http://www.devmts.demon.co.uk/prof
nal.htm
Kanter, R. M., Stein, B., and Jick, T.
D. (1992). The Challenge of
Organizational Change: How Companies
Experience It, and Leaders Guide It. New
York: Free Press.
Kauffman, S. A. (1991). Antichaos
and Adaptation. Scientific American,
August, 78-84.
Kauffman, S. A. (1992). The
Origins of Order: Self-Organization and
Selection in Evolution. Oxford: Oxford
University Press.
Kauffman, S. A. (1995). At Home
in the UniverseThe Search for Laws of
Complexity. Harmondsworth, UK :
Penguin Books.

Kelly, E. (1997). The knowledge


age: a fad or a fundamental change?
Strategic Futures Team, Scottish
Enterprise.
March
1997.
At:
h t t p : / / w w w. s c e n a r i o - p l a n n i n g .
com/art5.htm.
Kirshbaum, D. A. (1999).
Emotional reactions to complexity,
confusion and chaos. Published at:
http://www.calresco.org/kirshbm/reac
tion.htm April 2002
Kotkin, J. and Devol, R.
(2000). The Renewed City in the Digital
Age. Santa Monica, California: Milken
Institute.
Lester, S. (1994). On professionalism and professionality. published at:
http://www.devmts.demon.co.uk/prof
nal.htm.
London, S. (1996). Understanding
change: the dynamics of social transformation. Published at: http://www.scottlondon.com/reports/change.html
Luhmann,
N.
(1978).
Temporalization of complexity. in:
Sociocybernetics, 2 (R.F. Geyer and J. van
der Zouwen, eds.) pp. 95-111. The
Hague: Martinus Nijhoff.
Luhmann, N. (1986). The
autopoiesis of social systems. in:
Sociocybernetic
Paradoxes
Observation, Control and Evolution of
Self-steering Systems (R.F. Geyer and J.
van der Zouwen, eds.). pp. 172-192.

London and Beverly Hills: Sage.


Manivong, K. (2000). Synthesis
and Design of Smart Project
Management Information Systems for
Life Cycle Project Management. PhD
Thesis, University of Sydney, Australia.
Prigogine, I. and Stengers, I.
(1984). Order out of ChaosMans new
Dialogue with Nature. London:
Heinemann.
Robinson,
M.
S.
(2000).
Transformational leadership defined.
Published at: http://www.ethoschannel.com/personalgrowth/new/1msr_transformational.html
Schn, D. A. (1983). The reflective
practitioner: how professionals think in
action New York, Basic Books.
Senge, P. (1990). The Fifth
Discipline: The Art and Practice of
the
Learning
Organization
- 1st edition, 1994 - paperback
edition, xxiii, 413
Sorrell, K. L. (2001). Human
capacity building strategy (19 March
2001, ECOTECH INFO XCHANGE
web site). The Cuba Group Ltd
Tyson, P. (1998). (Opinion).
Developmental theory and the
postmodernist psychoanalyst. JAPA:
The Journal of the American
Psychoanalytic Association. Vol. 4
(10). http://www.apsa.org/japa/461opin.htm

PROFESSOR JAAFARI is Chair Professor of Project Management at the University of Sydney and is a
recognised authority in project and programme management. He has been a speaker at numerous
World Congresses and International Conferences worldwide. He is the winner of many prizes and
awards (3 in 2001).
Professor Jaafari has wide expertise and professional experience. His most recent executive position
was in 1990-3 as Chief Manager, Project Management, with SMEC in Australia. He has, to-date,
authored over 130 publications in project, programme, operations and technology management,
including strategy-based project management, whole-of-life framework & philosophy, concurrency,
management of technology and innovations, information management systems, TQM, risk, opportunity and uncertainty analysis & management and education of professionals. Since 1982 he has
conducted courses and seminars for over 3,000 executives, managers and professionals in
Australia, Asia and Europe. Professor Jaafari has held visiting professorial appointments at a number of universities, in the US, UK, Europe and Asia.

December 2003 Project Management Journal 57

PMI-002 11/5

11/6/03

9:20 AM

Page 58

COVER TO COVER
Book Review Editor, Kenneth H. Rose, PMP

DYNAMIC SCHEDULING WITH MICROSOFT, PROJECT 2002


BY ERIC UYTTEWAAL

ric Uyttewaal has done it


again. The second edition
of his book on Microsoft
Project entitled, Dynamic
Scheduling with Microsoft
Project 2002, is as impressive
as the first.
This book differs from the
other MS Project user books
and manuals in that it looks at
the software as a tool. It follows established and proven project management best
practices indicating where this tool is useful. Reading a
reference manual/user guide from this perspective is very
refreshing. It does not assume you will alter your
processes for the sake of the software; rather, it identifies
where your (PMBOK Guide) practices can benefit from
the functionality of MS Project 2002 to achieve cost
and/or time savings.
Perhaps the most impressive part of this book is
Chapter 9, Optimizing the Schedule. Within this chapter, Uyttewaal discusses many techniques to have
Microsoft Project assist the project manager in finding
time and cost savings in the areas of resource assignment,
leveling, and utilization. Everyone knows that optimizing
the project schedule can help to lower project costs or
duration. In this chapter the author uses his vast experience to demonstrate several techniques to do so successfully. This is the key to this books appealthe author
uses practical experience to explain the software and presents realistic examples to demonstrate its usefulness. The
material within this book can be applied to projects of
any size and within any industry.
The book will appeal to the experienced project
manager, and also discusses many topics of benefit

58 Project Management Journal December 2003

the junior or intermediate project manager. Examples


of which include the differences between constraints
and dependencies, and critical path versus resourcecritical path.
There is so much more than software training contained within these pages. Every project manager could
benefit from the techniques, suggestions, and tips presented within this publication, including: how to implement time saving strategies mid-project such as RCP fast
tracking; how to handle the replacement of critical
resources; strategies on how to defend/present a visible
buffer, or contingency, within your schedule; and downloadable exercise files, certified schedules, and filters.
Aside from the general project management best
practices, the book is also sound technically. New
Microsoft Project 2002 features, such as project guides,
and enhancements to the Assign Resources dialog, are
presented in detail.
Authored by a Project Management Professional,
aligned with the PMBOK Guide, easy enough to use by
a junior project managerand yet this book is complex
enough to teach even seasoned project managers and
Microsoft Project users alike. Eric Uyttewaals Dynamic
Scheduling with Microsoft Project 2002, is a must
read, re-read, and use daily for all project managers.
This should become a definite addition to your desktop
reference bookshelf.
J. Ross Publishing/IIL, 2003, ISBN: 1-932159-13-4,
704 pp., $54.95 Member, $59.95 Nonmember.

Reviewed by Corine Porter, Director of Marketing and


Business Development for CGI Information Systems &
Management Consultants Inc., Ottawa, Ontario, Canada.

PMI-002 11/5

11/6/03

9:20 AM

Page 59

PROJECT MANAGEMENT: A SYSTEMS APPROACH TO PLANNING,


SCHEDULING, AND CONTROLLING. 8TH EDITION
BY HAROLD KERZNER
ith the eighth edition of Harold
Kerzners Project Management: A
Systems
Approach
to
Planning,
Scheduling, and Controlling, we find that
this venerable work is showing its age. I
happen to have the fifth edition (1995)
handy, so when I received a copy of the
eighth edition, I sat down and compared
the content of the two editions. There is
little difference between them. The principal difference is that the text has been reduced from just
under 1,200 pages to 900 pages. However, this cutback does
not reflect a dramatic change in content or orientation. Rather,
the author has removed many of the case studies contained in
earlier editions and placed them into yet another book titled
Project Management Case Studies (Wiley, 2003).
The good news is that the book contains edifying incidents-for-discussion and textual explanations of key project
management concepts and tools. Unfortunately the book has
gone from edition to edition since its introduction in 1979 as
a 500-page work, new material has been added with little of
the old material being altered or removed. Some topics that
are covered extensively such as the ones on force-field analysis and learning curves reflect items of interest three decades
ago, but whose relevance to current project management theory and practice is limited. Most the footnotes found throughout the eighth edition reference works published in the 1960s
and 1970s. Clearly, the book needs to be refreshed.
There are nonetheless good things in the book. Kerzner
knows his stuff and his insights are on target. For example, his
chapter titled Working with Executives deals with important
issues that most writers ignore. Kerzner recognizes that without
support of project sponsors, projects in todays chaotic world
have trouble achieving their goals. The chapter provides practical insights to getting needed support.
Another example: Kerzner emphasizes that there is more
to project success than delivering goods on time, within budget and according to specifications. Success and failure are multidimensional. Ultimately, they are closely tied to the extent to
which you meet customer expectations.
Perhaps the most serious instance of outdated material is
found in the chapter dedicated to network scheduling.
Network diagramming is presented as an arrow diagram technique. However, with the advent of PC-based scheduling software in the early 1980s, the arrow diagram technique faded
into the background. None of the current generation of project management scheduling software employs arrow diagrams. Rather, the software employs the precedence diagram
method (PDM), which uses boxes and lines in lieu of arrows.
In Project Management, only a few pages are added at the end
of the network diagramming chapter that discuss PDM.
Also of concern is the assertion Kerzner makes that: This

text, the workbook, and the book of cases are ideal as selfstudy tools for the Project Management Institutes
Certification exam. While the text contains substantial
amounts of material that can provide readers with knowledge
that will serve them well when they take the Certification
exam, large portions of it are not compliant with PMIs A
Guide to the Project Management Body of Knowledge
(PMBOK).
Since the Certification examination reflects the PMBOK
perspective, this is a serious shortcoming of Project
Management as a Certification exam study source. The book
never discusses the PMBOKs five project management
processes or nine knowledge areas, which form the logical
backbone of project management theory and practice as
promoted by PMI and which lie at the heart of the
Certification exam.
Furthermore, its use of terminology often does not correspond to PMBOK usage. For example, its treatment of risk
management which is well done uses a different approach
than what is employed in the PMBOK. While the book divides
the risk management process into risk planning, risk assessment, risk handling, and risk monitoring, the PMBOK partitions it according to risk planning, risk identification,
qualitative risk analysis, quantitative risk analysis, risk
response planning, and risk monitoring and control. While
the book identifies risk assumption, risk avoidance, risk control, and risk transfer as the principal risk handling techniques
available to risk management practitioners, the PMBOK identifies risk acceptance, risk avoidance, risk mitigation, and risk
transference as the core techniques.
Consequently, students who use Project Management to
prepare for the risk management questions on the
Certification exam will find that many of the concepts and
terms they learned in this book do not map to concepts and
terms covered on the exam. What holds true for risk management holds with other knowledge areas as well.
There is not much that is truly new in the eighth edition.
One new chapter is titled Modern Developments in Project
Management. It covers eight topics in 20 pages, including
such items as project management maturity models and managing multiple projects. While this chapter addresses some
interesting new developments, the treatment of each topic is
very cursory. Another chapter dealing with a new topic is titled
Critical Chain Project Management which is written by
Gerald Kendall. It does a good job describing this relatively
new perspective on project scheduling.
John Wiley & Sons, 2003, ISBN: 0-471-22577-0, hardcover, 911 pp., $76.00 Member, $80.00 Nonmember.
Reviewed by J. Davidson Frame, PhD, PMP, Academic Dean,
The University of Management and Technology, Arlington,
Virginia, USA

December 2003 Project Management Journal 59

PMI-002 11/5

11/6/03

9:42 AM

Page 60

PROACTIVE RISK MANAGEMENT: CONTROLLING UNCERTAINTITY


2003 David I. Cleland Project Management Literature Award
IN PRODUCT DEVELOPMENT
BY PRESTON G. SMITH AND GUY M. MERRITT
roactive Risk Management: Controlling
Uncertainty in Product Development
by Preston G. Smith and Guy M. Merritt
may be simply the best book on risk management available today. It is certainly the
best book written on the subject during
2002or any other project management
subject for that matterwinning the coveted David I. Cleland Project Management
Literature Award from the Project
Management Institute for 2003.
Risk management can be a scary subject. In many circles
it has a reputation as being an intimidating collection of
mathematical techniques and formulas inaccessible to the
uninitiated members of project teams. Consequently, it is
often avoided or touched only lightly in ways that fail to
exploit its many benefits.
Smith and Merritt have developed and defined a practical
approach to risk management that is focused on new product
development but extensible to any project environment. Their
primary purpose is to enable product development teams to
identify surprises early in the project and manage them
throughout to diminish the disruption they cause. But identifying surprises and diminishing disruption is not a matter of
interest solely to product development teams. Any manager of
any project will find a useful framework in the model suggested by the authors.
Proactive Risk Management is unique among similar
texts in its practical, easy-to-use, fact-based approach to
managing all of the risks associated with a project. Howto information and techniques at the depth it offers are
not available elsewhere. The authors approach provides
a risk model that is scalable to any size project, methods
for identifying causes of risks, and a method for prioritizing risks without introducing errors.
Beyond its practicality, the books salient characteristic is its readability. It is user-friendly in the extreme,
characterized by simple, direct language and facilitating
icons that graphically indicate key ideas, cautionary
notes, examples, and supplementary information.
In the opening chapters, the authors make a clear distinction between risks (uncertain events) and issues (certain events). It is important to recognize the difference
because the two are managed in different ways. They also
make their case for proactive risk management, pointing
out that the process begins early in the project and continues throughout implementation as monitoring and
follow-up. They describe "firefighting" as an all-to-common alternative practiced by those who fail to prevent
"fires" by disciplined risk management techniques, or
worse, see crisis as an opportunity to be a corporate hero.

60 Project Management Journal December 2003

Whatever the basis, fighting fires is neither desirable nor


particularly successful.
Chapter 3 presents the proactive risk management
model in summary. It serves as an introduction for those
who will study further and as an executive overview for
top managers who just want the bottom line. The model
comprises a five-step process that includes: identifying
risks; analyzing risks to determine drivers, impacts, and
probabilities; prioritizing and mapping risks; planning
actions to take; and monitoring progress and identifying
emerging risks.
Smith and Merritt address each of the five processes in
detail in separate chapters. They provide useful, how-to guidance that includes hints as to where the hurdles might be in
application. All is presented in a conversational tone that facilitates understanding and learning. Each chapter closes with a
summary that reviews and reinforces key points and a brief list
of supplemental reading resources.
But the model, powerful as it may be, does not stand alone.
The authors also describe five tools that support the model and
the overall risk management effort. Some are very traditional,
such as spreadsheets and decision analysis. Others are more
innovative, such as sticky density, a highly visual and interactive approach to pinpointing risky areas in a process, project, or
organization. A series of suggested strategies complements the
tools and model to improve risk management effectiveness.
Some seem obvious: Avoid risk when it does not add value.
Others require a little thought: Apportion risk carefully, and
Use failure to your advantage.
Last, the authors offer guidance on identifying and overcoming organizational impediments. Effective risk management
does not just happen. An effective approach often requires
changes to established ways. Success depends on a broad view
and sensitivity to organization dynamics. The key is to build risk
management into the project as an integral element of all phases so that it rises to the importance level of cost and schedule.
Proactive Risk Management is a new entry to project management literature that should not be missed. For experienced
project managers, it may provide a codification of practices that
they have been applying all along. For those newer to the discipline, it will provide a solid grounding in a process that is essential to successful project implementation. For all, it provides a
straightforward, easy-to-understand method for managing risks
in the real project world.
Productivity Press, 2002, ISBN: 1-56372-265-2, paperback, 226
pp., $31.30 Member, $32.95 Nonmember.
Reviewed by Kenneth H. Rose, PMP, Director, Peninsula Center for
Project Management in Hampton, VA, USA and vice president for
programs, PMI Hampton Roads Chapter.

PMI-002 11/5

11/6/03

9:20 AM

Page 61

TEAM DEVELOPMENT FOR HIGH-TECH PROJECT MANAGERS


BY JAMES WILLIAMS

ooks about teams seem to coalesce around two poles: one


related to theory and another
related to step-by-step practices.
James Williams bridges the two
with Team Development for HighTech Project Managers, a practical,
no-frills approach to teams in a
project context.
Williams does not offer a cookbook of prescribed
procedures, but rather experienced-based, insightful
information that will stimulate readers thinking and
help them view project management and team building
in new waysways that will meet the new challenges of
todays project environment.
The book is divided into three parts. The first four
chapters establish a foundation of both project and team
basics. Readers will welcome familiar language and structure that arises from PMIs PMBOK Guide2000
Edition. They will also notice that the familiar team
development stages of forming, storming, norming, and
performing appear as birth, exploration, discovery, and
performance, with completion appended as a necessary
closure stage. Williams is not trying to coin new terminology. He explains that his terms get more to the heart
of what really occurs in the various stages and makes this
clear in his discussion of each.
The core and central strength of this book lie in the
seven chapters that address key topics that pertain to
team leaders and team participants that must work
through project processes. The author begins with communication systems, both formal and informal, internal
and external. He boils it all down to a simple goal of
saying (or relaying) the right information at the right
time to the right people in the right manner.
Williams discussion of motivation may seem brief.
Readers should keep in mind that Williams intent is not
encyclopedic coverage of complex issues. He covers the
essential points and provides references for those
inclined to further reading.
A welcome inclusion is the discussion of teams and
quality. This central issue often gets short shrift in team
texts. Williams focus on customers, teamwork, metrics,
and continuous improvement reminds readers that teams
implement projects to satisfy a customer, not just to meet
a planned schedule or budget.
Negotiation is a critical activity within project teams
and between project teams and their customers or spon-

sors. The author offers several tips for effective negotiation and describes several hardball tactics to avoid or
recognize when encountered. He emphasizes preparation
as the key to success and defines criteria for determining
success in any negotiation. He also points out that project managers must have strong listening skills to be effective negotiators, including both attentive and interactive
skills.
The obligatory chapter on conflict resolution is brief
but complete. Williams describes conditions that lead to
or contribute to conflict and methods for dealing with
conflictthe classic five of smoothing, withdrawal, compromising, forcing, and problem solving. He complements these with five personal styles ranging from
win-lose to integration (win-win). He follows with a discussion of project-specific sources of conflict and bases of
power that gives readers a comprehensive view that will
serve them well in any project team.
The issue of power is addressed in two chapters, one
dealing with building a project power base and one dealing with empowering others. Power and influence are
essentialand perhaps often misunderstoodingredients for a successful project manager. Williams shows a
positive approach that avoids the unsavory connotations
of power in the past. The strength of a team lies in
empowerment that enables and releases the full creativity of the team members. Williams suggests nine techniques that readers can apply on the job.
The book closes with a sort of catch-all section that
includes chapters on problem solving, time management, auditing, and future directions, Important topics
all, but wisely placed here to avoid breaking the chain of
thought that links together the elements of the previous
section.
Readers have many choices when seeking books on
teams and team building. Team Development for HighTech Project Managers should be considered first. It is
concise and complete, and focused on project needs
exactly what busy project managers are looking for.
Artech House, 2002, ISBN: 1580531342, hardcover, 213
pp., $56.05 Member, $59.00 Nonmember.

Reviewed by Kenneth H. Rose, PMP, Director, Peninsula


Center for Project Management in Hampton, VA, USA, and
vice president for programs, PMI Hampton Roads Chapter

December 2003 Project Management Journal 61

PMI-002 11/5

11/6/03

9:20 AM

Page 62

Guidelines for PMJ Book Reviews


Selecting Books for Review

PMJ welcomes recommendations from project managers and others regarding books that may be of
professional value to fellow PMI associates. Areas of potential interest include: new ideas about the
theory, concepts, and techniques of project management; new approaches to technology and management; getting business results; competing in todays complex workplace; and global changes.
Recommendations should include the title, author, and publisher, and a brief statement as to why the
book should be considered for review. PMJ will select books for review and identify a reviewer.
Individuals recommending books for review may also volunteer to write the review. However, individuals should not submit a review before PMJ has selected the book. PMJ receives many books from publishers and authors and cannot review them all.
Guidelines for Writers

Reviews should begin with a strong, brief opening paragraph that identifies the book and author, and tells
the reader why the book is important. The review should not only describe the content of the book, but also
what the content means; that is, why it is a contribution to the project management body of knowledge.
Reviewers may include the following elements:
A summary of key or unique concepts
Favorite quote, graphic, chart, etc.
Important tips or guidelines
New terms or phrases, such as knowbots or teamocracy
Message from the book that should be remembered for future use, or should have been disclosed
years ago.
Reviews should include the books strong points and any weak points if this information will be useful
to the reader. Reviews should be written in a conversational style that maintains academic rigor.
Reviewers should avoid use of the first person (I) and focus on the book and its contents. Reviewers
should also avoid use of extensive lists as a means of describing or duplicating content. Instead, focus
on what the content means to readers. Reviews should be no longer than 750 words in length (please
use your computer word count to verify length of the review).
Reviews should include complete publishing information, if possible: title, author(s), publisher (city and
state), year published, ISBN number, total pages, and price in U.S. dollars. PMJ will add any information that
is not available to reviewers.
Reviews should be prepared using MS Word and may be submitted by email (preferred) or on disk.
Submissions should include the name, title, company, address, phone/fax/e-mail, and brief (one or two
sentence) biosketch of the reviewer. Reviews should be submitted to:
Book Review Editor
PMI Publications
natasha.pollard@pmi.org
PMI reserves the right to edit all material submitted for publication.

62 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 63

Notes for Authors


SCOPE
The Project Management Journal is the professional journal of the Project Management Institute.
The mission of PMJ is to advance the state of the
art of the knowledge of project and program
management. PMJ presents useful information
on both theory and practice in the field of project management. Authors are encouraged to submit the following types of original manuscripts:
descriptions of innovative practices; summaries
of research results; reviews of current literature;
surveys of current practices; critical analyses of
concepts, theories, or practices; developments of
concepts, theories, or practices; analyses of failure. Manuscript length should not exceed
12,000 words. The selection of manuscripts for
publication is based on the extent to which they
advance the knowledge and understanding of
project management. PMI neither approves nor
disapproves of any data, claims, opinions, or
conclusions presented.
MANUSCRIPT REVIEW
PMJ uses a double-blind review process. The first
review of every manuscript is performed by two
anonymous referees (usually members of the
PMJ Editorial Review Board). The manuscript is
then either accepted, rejected, or returned to the
author for revision (with reviewer comments
furnished to the author). Revised manuscripts
are sent to the Editor, who makes a final disposition in consultation with the Publisher.
PMJ strives to respond to all authors within
three months of the date the manuscript is
received at the PMI Publishing Department.
Accepted manuscripts are subject to editorial
changes. The author is solely responsible for
all statements made in the manuscript,
including editorial changes.
ORIGINAL PUBLICATION
It is the policy of PMI to be the sole, original
publisher of manuscripts. Manuscripts that have
been submitted simultaneously to other magazines or journals will be rejected outright and
will not be reconsidered. Republication of a
manuscript, possibly revised, that has been disseminated via conference proceedings or
newsletter is permitted if the Editor judges there
are significant benefits to be gained from publication.
COPYRIGHT
Upon acceptance of a manuscript, authors will
be asked to transfer copyright of the article to the
publisher. This transfer will ensure the widest
possible dissemination of information. This
transfer of copyright enables PMI to protect the
copyrighted material for the authors, but does
not relinquish the authors proprietary rights.
The copyright transfer gives PMI the exclusive
rights to republish or reprint the manuscript in
any form or medium as well as to grant or refuse
permission to third parties to republish all or
parts of the manuscript.

SHORT ITEMS
Short items do not need rigorous academic
scrutiny and are not refereed. Upon receipt, however, these items become the copyright property
of PMI.
Opinion presents thoughtful discussion of
project management issues.
Correspondence pertains to the project and
program management profession, including references to literature, practice, and scholarship as
well as discussion and replies related to articles
published in PMJ.
Book Reviews express opinions about books
related to the project management profession, or
about general management or technical books
that cover topics of particular value to the project
manager.
Calendar of Events offers notices of forthcoming meetings and calls for papers.
SUBMISSIONS
All manuscripts must be submitted electronically either by email to natasha.pollard@pmi.org
or on diskette sent to: Project Management
Journal, Attn: Natasha Pollard, 4 Campus Blvd.,
Newtown Square, PA 19073 USA. If you submit
your manuscript on diskette, please include a
printout of the manuscript, including all tables
and figures, on 8-1/2 x 11 inch paper, double
spaced throughout, and printed on one side
only. Manuscripts should include the following
in the order listed:
A title page that includes the title of the
manuscript and each authors name, affiliation,
mailing address, and phone, fax, and e-mail
address. Correspondence will be directed only to
the first author listed.
An abstract of 100 words or less that outlines the purpose, scope and conclusions of the
manuscript, and selected keywords.
Text (use headings and no more than two
levels of subheadings). To permit objective
reviews by two referees, the abstract and first
page of the text should not reveal the authors
and/or affiliations, but only the manuscript title.
References.
Illustrations and Tables (titled, numbered
in Arabic, with captions, each on a separate
sheet, preferred location indicated within the
body of the text).
Biographical details of each author.
Upon manuscript acceptance, authors must also
provide a black-and-white passport-style photograph and a signed copyright agreement.
COMPUTER-GENERATED
TEXT AND ILLUSTRATIONS
Authors are requested to submit the final text
and illustrations via email or on a 3.5
IBM/compatible disks. As with the requirements
for manuscript submission, the main text, list of
references, table and illustration captions, and
author biographies should be stored in separate
text files with clearly identifiable file names.
Keep the layout of the text as simple as possible

and save text in their original applications


and/or Rich Text Format (RTF). It is essential that
the name and version of the word processing
program and format of the text files are clearly
indicated (example: Word for Windows 95 doc).
The electronic version on disk should only be
sent with the final accepted version of the paper
to the Editor. NOTE: The hard copy and electronic files must match exactly.
Upon acceptance of the manuscript for
publishing, authors will also be asked to provide
illustrations in computer format. Preferred formats are CorelDraw, MacroMedia Freehand,
Freelance Graphics, PowerPoint, Harvard
Graphics, Harvard Chart, or Canvas. If one of
these formats is unavailable, submit in Windows
Metafile (WMF), Adobe Illustrator (AI or EPS) or
Encapsulated PostScript (EPS). Please use
default/standard extensions. If illustrations are
available in paper form only, they will be recreated electronically for publication. Contact PMI
Publishing Department for further details.
STYLE OF TEXT
You should write in clear and concise English.
Spelling should follow Websters New World
Dictionary. Authors whose native tongue is not
English are assured that in-house editorial attention to their manuscript will improve clarity and
acceptability to readers. For questions regarding
style and format of text, refer to the Publication
Manual of the American Psychological Association,
Fifth Edition.
REFERENCES
For questions regarding reference format, refer
to the Publication Manual of the American
Psychological Association, Fifth Edition,
Bibliographic Forms for Journal Articles.
References used in the text should be identified
by author name and publication date in parentheses, e.g., (Cleland & King, 1983), and listed
alphabetically at the end of the manuscript.
Page numbers should be cited for all quotations. Follow the format example shown below:
Baker, Bud. (1993). The project
manager and the media: Some lessons from the stealth bomber program. Project Management Journal, 24
(3), 1114.
Cleland, David I., & King,
William R. (1983). Systems analysis
and project management. New York:
McGraw-Hill.
Hartley, John R. (1992).
Concurrent engineering. Cambridge,
MA: Productivity Press.
Please ensure that references are complete, that
they include, where relevant, authors name,
article or book title, volume and issue number,
publisher, date and page reference.
The use of page footnotes should be kept
to a minimum. Footnotes should be numbered
consecutively and listed at the end of the text
as endnotes.

December 2003 Project Management Journal 63

PMI-002 11/5

11/6/03

9:20 AM

Page 64

KEYWORDS
Keywords categorize your manuscript. They cover project management methodologies and processes, tools and techniques, PMBOK Guide
knowledge areas, industries, types of projects, geography. Please list three or four keywords that best categorize your manuscript. Choose
from the following list of suggested keywords (this is not a comprehensive list) or you may use your own.
Accounting
Activity Duration Estimating
Agriculture
Arrow Diagramming Method
Baselines
Benchmarking
Benefit/Cost Analysis
Budgeting
Change Control
Communications Management
Concurrent Engineering
Configuration Management
Conflict Resolution
Constraints
Construction
Contingency Planning
Contract Closeout
Cost Estimating
Cost Management
Critical Path
Delegation

Deliverables
Design
Documentation
Earned Value
Engineering
Environment
Estimating
Fast-Tracking
Feedback
Finance
Float
Funding
Human Resource Management
Information Systems
Integration Management
Large Project
Leadership
Life-cycle Costing
Manufacturing
Management Skills
Matrix Organization

CHECKLIST
Manuscript via email or on diskette
100-word abstract
Illustrations
Author biographies
Black and white author photographs
(upon acceptance)
Signed copyright agreement
(upon acceptance)

Milestones
Mitigation
Monte Carlo Analysis
Multiproject Planning
Negotiating
Networking
New Product Development
Organizational Planning
Organizational Structure
Parametric Modeling
Performance Reporting
Pharmaceuticals
Procurement Management
Productivity
Project Life Cycle
Project Management Software
Project Plan Development
Quality Assurance
Quality Management
Reengineering
Resource Planning

PROOFS
Correspondence and proofs for correction will
be sent to the first-named author unless
otherwise indicated. Copyediting of
manuscripts is performed by PMI staff. The
authors are asked to check proofs for
typographical errors and to answer queries
from editors. To improve publication times it
is important that proofs be returned within
three days. Authors may be charged for
extensive corrections in the proof stage.

Responsibility
Risk Management
Risk Response Development
Schedule Development
Schedule Control
Scope Management
Scope Definition
Scope Change Control
Simulation
Staff Acquisition
Stakeholders
Standards
Statistical Sampling
Team Development
Time Management
Tools
Training
Transportation Variance
Utilities
Virtual Organization
Work Breakdown Structure
Work Packages

COPIES AND REPRINTS


Authors will receive 10 copies of the journal
free of charge. Additional copies of the journal
and/or article reprints can be ordered at any
time from the PMI.

Project Management Institute


Publishing Department
4 Campus Blvd.
Newtown Square, PA 19073 USA
Tel: 610/356-4600 ext. 1135
Fax: 610/355-1633
E-mail: natasha.pollard@pmi.org

Statement of Ownership, Management, and Circulation


1.
2.
3.
4.
5.
6.
7.

Publication Title: Project Management Journal


Publication Number: 8756-9728
Filing date: 12/01/03
Issue Frequency: Quarterly
Number of Issues Published Annually: 4
Annual Subscription Price: $14.00
Complete Mailing Address of Known Office of
Publication: PMI Publishing Division,
Four Campus Boulevard, Newtown Square,
Pennsylvania 19073-3299 USA

8. Complete Mailing Address of Headquarters or General


Business office of the Publisher: Project Management
Institute, Four Campus Boulevard, Newtown Square,
Pennsylvania 19073-3299 USA
9. Full Names and Complete Mailing Addresses of
Publisher: Gary Boyler, Four Campus Boulevard Four
Campus Boulevard, Newtown Square, Pennsylvania
19073-3299 USA
10. Owner: Project Management Institute, Four Campus
Boulevard, Newtown Square, Pennsylvania 19073-3299 USA

11. Known Bondholders, Mortgagees, and Other Security


Holders Owning or Holding 1 Percent or More of
Total Amount of Bonds, Mortgages, or Other
Securities: None
12. For completion by nonprofit organizations authorized
to mail at special rates. The purpose, function, and
nonprofit status of this organization and the exempt
status for federal income tax purposes: Has Not
Changed During Preceding 12 Months
13. Publication Name: Project Management Journal
14. Issue Date for Circulation Data Below: November 2003

15. Extent and Nature of Circulation

a. Total No. Copies (Net Press Run)


b. Paid and/or Requested Circulation
(1) Sales Through Dealers and Carriers, Street Vendors, and Counter Sales (Not Mailed)
(2) Paid or Requested Mail Subscriptions (Include Advertisers Proof Copies/Exchange Copies)

Average No. Copies Each Issue


During Preceding 12 Months

Actual No. Copies Single Issue


Published Nearest to Filing Date

108,987

119,812

Does Not Apply

Does Not Apply

107,887

118,712

107,887
Does Not Apply
Does Not Apply
Does Not Apply
107,887

118,712

1,100
Does Not Apply
108,987
98.7%

1,100

c. Total Paid and/or Requested Circulation (Sum of 15b(1) and 15b(2)


d.
e.
f.
g.
h.

Free Distribution by Mail (Samples, Complementary, and Other Free)


Free Distribution Outside the Mail (Carriers or Other Means)
Total Free Distribution (Sum of 15d and 15e)
Total Distribution (Sum of 15d and 15f)
Copies Not Distributed
(1) Office Use, Leftovers, Spoiled
(2) Return from News Agents
i. Total (Sum of 15g, 15h(1), and 15(2))
Percent Paid and/or Requested Circulation (15c / 15g x 100)
16. This Statement of Ownership will be printed in the December 2003 issue of this publication.
17. Name and Title of Editor, Publisher, Business Manager, or Owner: Gary Boyler,

118,712

119,812
98.9%

Date: 12/01/03

64 Project Management Journal December 2003

PMI-002 11/5

11/6/03

9:20 AM

Page 65

INDEX OF 2003

PROJECT MANAGEMENT
JOURNAL PAPERS AND AUTHORS
1. A Critical Look at Critical Chain Project
Management. Tzvi Raz, Robert Barnes, and Dov Dvir.
December, 24-32.
2. Applying the Slevin-Pinto Project Implementation
Profile to an Information Systems Project. Peter Finch.
September, 32-39.
3. Applying Utility Theory to Risk Management.
Crispin Piney. September, 26-31.
4. Beyond the Body of Knowledge: A KnowledgeFlow Approach to Project Management Theory and
Practice. Keith F. Snider and Mark E. Nissen. June, 4-12.
5. Cost Estimation Overruns in the North Sea.
Magne Emhjellen, Kjetil Emhjellen, and Petter
Osmundsen. March, 23-29.
6. Earned Value Project Management Method and
Extensions. Frank T. Anbari. December, 12-23.
7. Effectiveness of Alliances Between Operating
Companies and Engineering Companies. He Zhang and
Peter Flynn. September, 48-52.
8. Effective Project Management for Strategic
Innovation and Change in an Organizational Context.
John Kenny. March, 43-53.
9. Evaluation and Selection of Consultants for
Design-Build Projects. Yean Yng Ling, George Ofori, and
Sui Pheng Low. March, 12-22.
10. JWARS: A Case Study. Jim Metzger. December, 40-46.
11. Learning Generators: Project Teams Re-conceptualized. Andrew J. Sense. September, 4-12.
12. Learning to reduce rework in projects: Analysis
of firms organizational learning and quality practices

Authors
Anbari, Frank T. (6)
Andersen, Erling S. (22)
Atkins,Steven (21)
Badir,Yuosre F. (13)
Barnes, Robert (1)
Bourquin, Vincent (13)
Demeulemeester, Erik (20)
Dvir, Dov (1)
Edwards, David J. (12)
Emhjellen, Kjetil (5)
Emhjellen, Magne (5)
Finch, Peter (2)
Flynn, Peter (7)

Peter E.D. Love, Zahir Irani, and David J. Edwards.


September, 13-25.
13. Management of Global Large-Scale Projects
Through a Federation of Multiple Market-Based
Workflow Management Systems. Yuosre F. Badir, Remi
Founou, Claude Stricker, and Vincent Bourquin.
September, 40-47.
14. Project Management in the Age of Complexity and
Change. Ali Jaafari. December, 47-57.
15. Project Management Learning: What the Literature
has to say. Debbie Tesch, Timothy J. Kloppenborg, and John
K. Stemmer. December, 33-39.
16. Project Management Maturity:An Industry-Wide
Assessment. James S. Pennypacker and Kevin P. Grant.
March, 4-11.
17. Schedule and Cost Buffer Sizing: How to Account for
the Bias Between Project Performance and Your Model.
Larry Leach. June, 34-47.
18. Strategic Planning for a Project Office. Harold
Kerzner. June, 13-25.
19. Surveying Practicing Project Managers on
Curricular Aspects of Project Management Programs: A
Resource-Based Approach. Alan D. Smith. June, 26-33.
20. The Application of Project Scheduling Techniques in
a Real-life Environment. Mario Vanhoucke and Erik
Demeulemeester. March, 30-42.
21. The Role of Induction and Training in Team
Effectiveness. Steven Atkins and Guinevere Gilbert. June, 48-52.
22. Understanding Your Project Organizations
Character. Erling S. Andersen. December, 4-11.

Founou, Remi (13)


Gilbert, Guinevere (21)
Grant, Kevin P. (16)
Irani, Zahir (12)
Jaafari, Ali (14)
Kenny, John March (8)
Kerzner, Harold (18)
Kloppenborg, Timothy J. (15)
Leach, Larry (17)
Ling, Yean Yng (9)
Love, Peter E.D. (12)
Low, Sui Pheng (9)
Metzger, Jim (10)
Nissen, Mark E. (4)

Ofori, George (9)


Osmundsen, Petter (5)
Pennypacker, James S. (16)
Piney, Crispin (3)
Raz, Tzvi (1)
Sense, Andrew J. (11)
Smith, Alan D. (19)
Snider, Keith F. (4)
Stemmer, John K. (15)
Stricker, Claude (13)
Tesch, Debbie (15)
Vanhoucke, Mario (20)
Zhang, He (7)

December 2003 Project Management Journal 65

Das könnte Ihnen auch gefallen