IPJM Vol 23

1.
Editorial board
Page CO2
2.

The impacts of charismatic leadership style on team cohesiveness and overall
performance during ERP implementation
Pages 173-180
Eric Wang, Huey-Wen Chou and J ames J iang
3.

Standardized project management may increase development projects success
Pages 181-192
Dragan Milosevic and Peerasit Patanakul
4.

The use of dependence structure matrix and domain mapping matrix in
managing uncertainty in multiple project situations
Pages 193-203
Mike Danilovic and Bengt Sandkull
5.

Project management turnover: causes and effects on project performance
Pages 205-214
Stephen K. Parker and Martin Skitmore
6.

A tool for managing projects: an analytic parameterization of the S-curve
Pages 215-222
Denis F. Cioffi
7.

Project Scheduling using Dependency Structure Matrix
Pages 223-230
J . Uma Maheswari and Koshy Varghese
8.

Process improvement in project expediting: there must be a better way
Pages 231-236
Keith A. Willoughby
9.

The success of international development projects, trust and communication:
an African perspective
Pages 237-252
Amadou Diallo and Denis Thuillier

International Journal of Project Management
Copyright 2006 Elsevier Ltd and the International Project Management Association (IPMA). All rights reserved
Volume 23, Issue 3, Pages 173-256 (April 2005)
10.

The Project Management AZ: A Compendium of Project Management
Techniques and How to Use Them
Pages 253-254
Dennis Lock
11.

John M. Nicholas, Project Management for Business and Engineering (second
ed.), Elsevier, ButterworthHeinemann, Burlington, MA, USA (2004) ISBN 0-
7506-7824-0 p. 603 (paperback), 29.99.
Pages 254-256
Dennis Lock

The International Journal of Project Management is devoted to the publication of papers which advance knowledge of
the practical and theoretical aspects of project management. The Journal aims to: provide a focus for worldwide
expertise in the required techniques, practices and areas of research; present a forum for readers to share common
experiences across the full range of industries and technologies in which project management is used; cover all areas of
project management from systems to human aspects; and link theory with practice by publishing case studies and
covering the latest important issues in special series.
Contributions Those wishing to submit full-length papers or case studies should send four copies to the editor,
Professor J R Turner, at the address below. Contributors should refer to the Notes for Authors printed in this issue
of the Journal. These are also available from the publishers.
INTERNATIONAL EDITORIAL BOARD
Professor D Arditi Professor and Chairman,
Department of Civil and Architectural
Engineering, Illinois Institute of Technology,
3201 South Dearborn Street
Chicago, IL 60616-3793, USA
E-mail: ia_arditi@vaxl.iit.edu
Professor Karlos A Artto Helsinki University
of Technology, PO Box 9500
FIN02015 HUT, Finland
E-mail: karlos.artto@hut.
Professor B Boeva University for National and
World Economic Studies, Studentslei grad
Ch. Botev, 1100 Soa, Bulgaria
E-mail: boeva@apollo.netissat.bg
Professor Sergey Bushuyev Kiev National
University of Construction and Architecture,
31 Povitrootsky pr., Kiev 04037, Ukraine
E-mail: bush@upma.freenet.kiev.ua
Dr Juan Luis Cano Department of Design and
Manufacturing Engineering, University of
Zaragoza, Maria de Luna 3, 50015 Zaragoza,
Spain
E-mail: jlcano@posta@unizar.es
Mr Giles Caupin Caupin & Associes,
3 Rue Creuse, F-77710TREUZY
LEVELAY, France
E-mail: 100661.1434@compuserve.com
Dr L. Crawford 10 Amaroo Crescent,
Mosman, NSW 2088, Australia
E-mail: lynn.crawford@uts.edu.au
D H Curling Principal Consultant,
LODAY Systems Ltd, 1786 Devlin Crescent,
Ottawa, Ontario K1H 5T6, Canada
E-mail: pm@davidcurling.info
Dr J D Frame UMT, Suite 306
1925 N. Lynn Street
Arlington, VA 22209, USA
E-mail: davidson.frame@umtweb.edu
Professor Qian Fupei PO Box 617, Northwestern
Polytechnical University, Xian, 710072,
Peoples Republic of China
E-mail: qianfp@nwpu.edu.cn
Professor Roland Gareis Projektmanagement
Austria-Institute, Wirtschaftuniversitet,
Franz Klein Gasse, 1190 Vein, Austria
E-mail: roland.gareis@wu-wein.ac.at
Professor Shlomo Globerson Faculty of
Management, Tel Aviv University, POB 39010
Ramat Aviv, Tel Aviv 69978, Israel
E-mail: globe@post-tau.ac.il
Professor Joop Halman University of Twente,
Faculty of Engineering Technology,
Department Construction Engineering
Management, PO Box 217 7500 AE Enschede
Professor Francis Hartman Faculty of
Engineering, University of Calgary,
2500 University Drive
NW, Calgary, Alberta, Canada
E-mail: fhartman@ucalgary.ca
Professor M Elizabeth C Hull School of
Computing and Mathematical Sciences,
University of Ulster, Newtownabbey,
Co Antrim, BT37 0QB, N. Ireland, UK
E-mail: mec.hull@ulst.ac.uk
Mr Adesh Jain Director in Charge,
Centre for Excellence in Project Management,
A-48, Sector V, Noida 201 301, India
E-mail: acjain@vsnl.com
Professor Jon Lereim Institutt for Teknologile-
delse, Elias Smiths vei 15, Postboks 580,
1302 Sandvika, Norway
E-mail: jon.lereim@bi.no
Professor Rolf A Lundin Jo nko ping
International Business School,
Jo nko ping University, PO Box 1026,
WE-551 11 Jo nko ping, Sweden
E-mail: rolf.a.lundin@jibs.hj.se
Professor Christophe Midler Centre de
Researche de Gestion, Ecole Polytechnique
1 rue Descartes, 75005 Paris, France
E-mail: midler@poly.polytechnique.fr
Professor Peter Morris Professor of Construction
and Project Management, The Bartlett School
of Graduate Studies, UCL The Faculty of the
Built Environment, Torrington Place Site,
Gower Street, London WC1E 6BT, UK
E-mail: pwmorris@netcomuk.com.uk
Professor Jerey Pinto School of
Business, Penn State Erie, Station Road,
Erie PA 16563, USA
E-mail: jkp4@psu.edu
Professor Nigel J Smith Department of Civil
Engineering, University of Leeds,
Leeds LS2 9JT, UK
E-mail: n.j.smith@leeds.ac.uk
Hiroshi Tanaka Project Services Division,
Yokohama World Operations Center,
3-1, Minato Mirai 2-chome, Nishi-ku,
Yokohama 220-6001, Japan
E-mail: tanaka.hiroshi@jgc.co.jp
Willi Vonrufs Project and Process
Management, Larchenstrasse 20,
CH-8903 Birmensdorf, Switzerland
E-mail: vonrufs@vonrufs.ch
Professor Terry M Williams Department
of Management Science, Graham Hills Building,
40 George Street, Glasgow, G1 1QE
E-mail: Terry@mansci.strath.ac.uk
Professor K-T Yeo Nanyang Technological
Unia versity, School of Mechanical and
Production Engineering, Nanyang Ave,
Singapore 2263
EDITOR
Professor J R Turner
Professor of Project Management
ISGI-Groupe ESC Lille
Avenue Willy Brandt
F 59777 EURALILLE
France
Postal Address: EuroProjEx
Wildwood
Manor Close
East Horsley
Surrey KT24 6SA, UK
E-mail Address: ijpm@europrojex.co.uk
INTERNATIONAL JOURNAL OF
PROJECT
MANAGEMENT
International Journal of Project Management is the ocial journal of the International Project Management Association. The
journal is available to all members of the IPMA at a special membership rate. For details of membership or enquires regarding the
association, please contact:
Ms Nancy Dol, IPMA International Secretariat, International Project Management Association, P.O. Box 1167, NL 3860 BD
Nijkerk, The Netherlands.
Members of associations aliated to IPMA should contact their National Association for subscription details
INTERNATIONAL JOURNAL OF PROJECT MANAGEMENT
NOTES FOR AUTHORS
Scope
The International Journal of Project Management is devoted to
the publication of papers which advance knowledge on prac-
tical and theoretical aspects of project management. The list of
key words at the end of this guide indicates the scope of the
journal. Papers are selected for publication based on their re-
levance, clarity, topicality, the extent to which they advance
knowledge, and their contribution to inspiring further devel-
opment and research. The journal strives to maintain a balance
between papers derived from research and from practical ex-
perience. Authors are encouraged to submit case studies de-
scribing the project environment; criteria and factors for
success; responsibilities of participants; managerial arrange-
ments; human factors; contract forms; planning and control
systems; problem areas encountered and lessons learned.
Submission of Papers
Authors are requested to submit their original manuscript and
gures plus three copies to Professor .J. R. Turner, EuroProjex,
Wildwood, Manor Close, East Horsley, Surrey, KT24 6SA,
UK. (When sending revisions. only two copies are required.)
The editorial oce does not have bulk photocopying facilities
and so cannot receive papers by e-mail onlypaper versions
must be sent by post.
Submission of a paper implies that it has not been published
previously, that is not under consideration for publication
elsewhere, and that if accepted it will not be published else-
where in the same form, in English or any other language,
without the written consent of the Publisher.
Refereeing: All papers submitted for publication will be refer-
eed on the double-blind system by two or more specialists
selected from a panel of referees. This means the author and
referees do not know each other, nor do the referees know
other referees. Thus it is important that authors names should
appear nowhere in the manuscript except on the cover page
(which can be separated from the manuscript) and in refer-
ences. When referring to their own work, authors should refer
to themselves in the third person. Any papers not adhering to
this will be returned.
Manuscript Preparation
General: Manuscripts should be 3000 to 5000 words long (6000
maximum), inclusive of gures and tables. Count each gure
and table as 300 words. Papers must be typewritten, double-line
spaced with wide margins on one side of white A4 paper. Good
quality printouts with a font size of 12 or 11 pt are required.
Number every sheet. Write in clear and concise English, using
active rather than passive voice. Authors may refer to them-
selves in the rst person, except when citing their own work.
Spelling should follow the Oxford English Dictionary. Authors
should consult a recent issue of the journal for style if possible.
An electronic copy of the paper should accompany the nal
version. The Editors reserve the right to adjust style to certain
standards of uniformity. Authors should retain a copy of their
manuscript since we cannot accept responsibility for damage or
loss of papers. Original manuscripts are discarded one month
after publication unless the Publisher is asked to return original
material after use.
Abstracts: Please supply an abstract of about 100 words out-
lining the purpose, scope and conclusions of the paper, and at
least two selected keywords. It is important that the abstract
should be very clear and understandable to those whom Eng-
lish is not their native language. The abstract should explain
why the paper is important to those who may not necessarily be
in that particular eld. A list of keywords to choose from ap-
pears at the end of this guide.
Arrangement of papers: Please arrange your paper as follows
(with each of the numbered items beginning on a new page):
1. Cover page with title, author(s), aliation(s), full ad-
dress(es), e-mail, telephone and fax numbers (this will be
removed from the copy, sent to referees).
2. Abstract page with the title repeated (but no authors
names), abstract and keywords.
3. The text, suitably divided under headings. Please do not
number headings.
4. Acknowledgements (if any).
5. References.
6. Captions to tables and illustrations (grouped on a separate
sheet).
7. Tables (each on a separate sheet, with captions).
8. Illustrations (each on a separate sheet, without captions).
Please ensure that your name appears only in item I (except when
citing a reference within a paper) and that this can be separated
from the rest of the paper. Do not import the Tables or Illus-
trations into your text. The corresponding author should be
identied with an asterisk and footnote. All other footnotes
(except table footnotes) should be identied with superscript
Arabic numerals. Trade names should have an initial capital
letter.
Units: You should use SI units, as dened by the ISO standard
or your national authorized SI standard. Where SI units do not
exist, use an internationally accepted unit. If you use any
symbol or unit that may not be generally recognized, please put
an explanatory note in the margin the rst time it is used, to
help the referees and editors.
References: All publications cited in the text should be pre-
sented in a list of references following the text of the manu-
script. In the text refer to references by a number in square
brackets on the line, e.g. Since Cooper [1]. Where you cite a
reference more than once in the text, use the same number each
time. The full reference should be given in a numerical list at
the end of the paper. References should take the following
form:
[1] Cooper DF. Chapman CB. Risk analysis for large projects:
models, methods and cases. New York: Wiley, I987.
[2] Potter M. Procurement of construction work: The clients
role: In: U J. Orams AM, editors. Proceedings of 7th Annual
Conference on Construction Law and Management, Kings
College, London, UK, 1995. p. 169194.
[3] Norwood SR, Manseld NR. Joint venture issues concerning
European and Asian construction markets of the 1990s. Inter-
national Journal of Project Management 1999;17(2):8993.
Please ensure that references are complete, i.e. that they in-
clude, where relevant, authors name, article or book title,
volume and issue number, publisher and location, date and
page reference.
Illustrations: All illustrations should be provided in camera-
ready form, suitable for reproduction (which may include re-
duction) without retouching. Photographs, charts and dia-
grams are all to be referred to as Figure(s) and should be
numbered consecutively in the order to which they are referred.
They should accompany the manuscript, but should not be
included within the text. All illustrations should be clearly
marked on the back in pencil with the gure number and the
authors name. All gures are to have a caption. Captions
should be supplied on a separate sheet and should be in low-
ercase letters with an initial capital for the rst word only.
Line drawings: Good quality printouts on while paper pro-
duced in black ink are required. All lettering, graph lines and
points on graphs should be suciently large and bold to permit
reproduction when the diagram has been reduced to a size
suitable for inclusion in the journal. Dye-line prints or photo-
copies are not suitable for reproduction. Do not use any type of
shading on computer-generated illustrations.
Graphs: The minimum amount of descriptive text should be
used on graphs (label curves, points etc. with single-letter
symbols). Descriptive matter should be placed in the gure
caption. Scale grids should not be used in graphs, unless re-
quired for actual measurements. Graph axes should be labelled
with variables written out in full, along the length of the axes,
with the unit in parentheses (e.g. Time(s)). A table is usually
more satisfactory for recording data.
Photographs: Original photographs must be supplied as they
are to be reproduced (e.g. black and white or colour) plus two
photocopies. If necessary, a scale should be marked on the
photograph. Please note that photocopies of photographs are
not suitable for reproduction.
Colour: Where colour gures are required, the author will be
charged accordingly (further details of costs are available from
Author Services at Elsevier). In cases where colour is paid
for, authors will receive an additional one hundred free o-
prints.
Tables: Tables should be numbered consecutively in Arabic
numerals and given a suitable caption at the top of the table.
Type each table on a separate sheet. Footnotes to tables should
be typed below the table and should be referred to by super-
script lowercase letters. No vertical rules should be used. Tables
should not duplicate results presented elsewhere in the manu-
script (e.g. in graphs).
Electronic submission
Authors should submit an electronic copy of their paper with the
nal version of the manuscript. This may be sent on disk or by e-
mail, but only with the nal accepted version of the paper. The
electronic copy must match the hardcopy exactly and should
be accompanied by two paper copies of the manuscript.
Always keep a backup copy of the electronic le for refer-
ence and safety. Guidelines on electronic submission are sent
to the authors with the request to revise the paper. Full
details of electronic submission and formats can be obtained
from http://authors.elsevier.com or from Author Services at
Elsevier.
Proofs
Proofs will be sent to the author (rst-named author if no
corresponding author is identied on multi-authored papers)
by PDF wherever possible and should be returned within 48
hours of receipt, preferably by e-mail. Corrections should be
restricted to typesetting errors; any other amendments made
may be charged to the author. Any queries should be answered
in full. Elsevier will do everything possible to get your article
corrected and published as quickly as possible. Therefore, it is
important to ensure that all of your corrections are returned to
us in one all-inclusive e-mail or fax. Subsequent additional
corrections will not be possible, so please ensure that your rst
communication is complete. Should you choose to mail your
corrections, please return them to: Log-in Department.
Elsevier, Stover Court, Bampfylde Street, Exeter. Devon EX1
2AH, UK.
Oprints
Fifty oprints will be supplied free of charge to the corre-
sponding author. Additional oprints can be ordered at a
specially reduced rate using the order form sent to the corre-
sponding author after the manuscript has been accepted. Or-
ders for reprints (produced after publication of an article) will
incur a 50%, surcharge.
Copyright
All authors must sign the Transfer of Copyright agreement
before the article can be published. This transfer agreement
enables Elsevier Ltd and the International Project Management
Association to protect the copyrighted material of an author,
without the author relinquishing his/her proprietary rights. The
copyright transfer covers the exclusive rights to reproduce and
distribute the article, including reprints, photographic re-
productions, microlm or any other reproductions of a similar
nature, and translations. It also includes the right to adapt the
article for use in conjunction with computer systems and pro-
grams, including reproduction of publication in machine-
readable form and incorporation in retrieval systems. Authors
are responsible for obtaining from the copyright holder per-
mission to reproduce any material for which copyright already
exists.
Checklist
Have you told readers, at the outset, what they might gain
by reading your paper?
Have you made the aim of your work clear?
Have you explained the signicance of your contribution?
Have you set your work in the appropriate context with
sucient background, and all relevant references?
Have you addressed the question of practicality and use-
fulness?
Have you identied future developments that may result
from your work?
Have you structured your paper in a clear and logical
fashion?
Author Services
For enquiries relating to the submission of articles (including
electronic submission where available) please visit the Author
Gateway from Elsevier at http://authors.elsevier.com. The
Author Gateway also provides the facility to track accepted
articles and set up e-mail alerts to inform you of when an ar-
ticles status has changed, as well as detailed artwork guide-
lines, copyright information, frequently asked questions and
more.
Keywords
Please choose at least two key words from the following lists, as
appropriate. This will assist the editor in choosing referees, as
well as helping with cataloguing.
General:
Implementing Strategy; Managing Programmes; Managing
Projects; Success and Strategy; Processes, Procedures; Systems.
Project Oce; Audits, Health Checks; Systems Approach.
External Context:
PEST: Legal; Environmental; Value, Benet, Finance.
Implementation:
Functionality. Value; Conguration; Scope of Work; Organi-
zation Resources; Quality; Cost; Time; Risk; Safety and
Health.
Life cycle:
Integration-Life Cycle; Start-up; Proposal and Feasibility;
Design and Appraisal; Implementation; Progress; Commis-
sioning and Close-out.
Commercial:
Value and Benet; Finance; Cash Flow Management; Taxa-
tion; Insurance.
Contractual: Organization Design; Partnerships; Alliances;
Procurement; Bidding; Contract Administration; Materials,
Purchasing & Supply; Commercial Law; Claims; International
Projects.
People:
Management Structure; Teams; Individuals; Managing and
Leading; Stakeholders; Competence; Culture; Ethics; Change.
General Management:
Human resource management: Marketing; Operations; In-
formation technology; Finance and accounting; Strategy;
Technology, Innovation.
The impacts of charismatic leadership style on team cohesiveness
and overall performance during ERP implementation
Eric Wang
a
, Huey-Wen Chou
a
, James Jiang
b,
*
a
Department of Information Management, National Central University, No. 300, Jung-da Rd., Jung-li City, Taoyuan, 320 Taiwan, ROC
b
Department of Management Information Systems, University of Central Florida, Orlando, FL 32816, USA
Received 11 June 2004; received in revised form 5 August 2004; accepted 24 September 2004
Abstract
Though several key enterprise resource planning (ERP) implementation factors, including top management commitment and
support, change management, and consultants support haven been broadly discussed in literature, other factors such as leadership
style and team cohesiveness have recently received more attention in technical project implementation [Thite M. Leadership styles in
information technology projects. International Journal of Project Management 2000:18;23541; Jiang JJ, Klein G, Chenoun-Gee H.
The relative inuence of IS project implementation policies and project leadership on eventual outcomes. Project Management Jour-
nal 2001;32(3):4955]. The charismatic leadership style has often been adopted by organizational leaders, primarily in Asian coun-
tries including Taiwan. The present study, based upon the team leadership theory proposed by Zaccaro, Rittman, and Marks [The
sociology of religion [Transl. Ephraim Fischo]. Boston: Beacon Press; 1963], serves as an initial step towards understanding the
impacts of charismatic leadership style on ERP implementation. Three-hundred companies listed in the Top 500 of The Largest
Corporations in Taiwan 2001, that have implemented ERP systems, were surveyed. The results conrm that leaders should dem-
onstrate more charismatic behaviors to establish the ERP project team members cohesiveness and, thus, improve team perform-
ance. The positive relationship between team cohesiveness and overall team performance was also statistically supported.
Implications on future study are discussed.
2004 Elsevier Ltd and IPMA. All rights reserved.
Keywords: Enterprise resource planning; Charismatic leadership; Project team performance; Cohesiveness
1. Introduction
Many rms view standard ERP packages as a key to
overcoming the problems of their legacy systems and to
increasing global competitiveness [16]. ERP systems
have been adopted by over 60% of Fortune 500 compa-
nies in the USA [31]. However, studies have indicated
that the implementation of an ERP system could be
an extensive, lengthy and costly process. For example,
the Standish Group reports that ERP implementation
projects were, on average, 178% over budget, took 2.5
times as long as intended and delivered only 30% of
the promised benets [23]. Due to its complexity and
scope, ERP implementation is handled by a cross-func-
tional team, composed of members of diverse back-
grounds and interests. As a result, the ERP leaders
eectiveness and the cohesiveness among ERP team
members have become critical success factors for ERP
implementation [14]. Unfortunately, it is generally rec-
ognized that technical employees lack the leadership
skills necessary to eectively manage people [18]. In spite
of its importance, little attention has been paid to the
nature of IS project leaders leadership styles [33].
0263-7863/$30.00 2004 Elsevier Ltd and IPMA. All rights reserved.
doi:10.1016/j.ijproman.2004.09.003
*
Corresponding author. Tel.: +1 407 823 4864; fax: +1 407 823
2389.
E-mail addresses: ewang@mgt.ncu.edu.tw (E. Wang), hwchou@
mgt.ncu.edu.tw (H.-W. Chou), jjiang@bus.ucf.edu (J. Jiang).
www.elsevier.com/locate/ijproman
International Journal of Project Management 23 (2005) 173180
PROJECT
MANAGEMENT
Leadership is critical to any group environment. Sev-
eral studies have highlighted the essential leadership
qualities and skills required by IS project managers to
ensure success, such as the ability to manage people,
stress, emotions, bureaucracy, and communication.
Charismatic leadership behaviors are identied as
among the most critical leadership behaviors in terms
of satisfaction [33]. Weber [34] rst introduced the term
charisma and described it as a somewhat super-
human attribute, or an endowment with the gift of
divine grace. According to Weber, a charismatic lea-
der is viewed as a mystical, narcissistic, and personally
magnetic saviour [5]. Attributed personality traits that
others consider extraordinary dene one characteristic
of charisma [8]. Some researchers argue that charis-
matic leaders fuse each members personal goals with
the team or organizational mission. Team members
identify at a personal level with the purposes and goals
of the collective as a whole and therefore feel more
team commitment and cohesiveness, which improves
subsequent performance.
Group cohesiveness can be thought of as the degree
to which members are attracted to the group and are
more motivated to remain part of the group [29]. In spite
of the lack of attention received in the IS literature,
cohesiveness has long been identied as a factor exerting
considerable inuence over work group performance
and is considered central to the study of group dynamics
in other disciplines [36].
The purpose of this study is to examine the inuence
of project managers charismatic leadership styles on
project teams cohesiveness and thus the teams overall
performance during ERP implementation in Taiwan.
More specically, the study attempts to address the fol-
lowing questions:
1. Does the charisma leadership style have a positive
inuence on the ERP project teams cohesiveness?
2. Does the charisma leadership style have a positive
inuence on the ERP project teams performance?
3. Does team cohesiveness have a positive relationship
with the ERP project teams performance?
This study makes a number of contributions. First, to
our knowledge this is the rst empirical study in the IS
literature that examines the charisma leadership style
and its impacts on the group cohesiveness and team
performance in the context of ERP implementation.
Second, this study identies another critical success fac-
tor (i.e., project leaders leadership style) for ERP imple-
mentation beyond the more well-known factors such as
top management support, consultant competence, and
the t between the ERP system and business processes.
Third, this study provides empirical evidence conrming
the relationship between a project leaders leadership
style (i.e., charismatic leadership) and team cohesive-
ness. This is important, given that team cohesiveness is
central to understanding group dynamics. Fourth, this
study provides the rst empirical evidence that leader-
ship style has a signicant impact on technology-ori-
ented project implementation, which is an issue raised
recently in the IS literature [33]. Finally, the proposed
research model provides a framework for future studies
that examine the impacts of other leadership styles (e.g.,
intellectual stimulation) on IT implementation project
team performance.
2. Background and research hypotheses
The term team may be dened as a social system
of three or more people, which are embedded in an
organization, whose members perceive themselves as
such and are perceived as members by others, and
who collaborate on a common task (teamwork)
[1,11]. According to Katzenbach and Smiths [19] de-
nition, teamwork represents a set of values that
encourages listening, responding constructively to views
expressed by others, providing support and recognizing
the achievement of others. In this study, the term ERP
project team refers to a small group in which individuals
work together outside of traditional hierarchical lines of
authority on a temporary basis on ERP implementation
projects to reach some predetermined standards such as
quality, within time and budget constraints.
Eective team performance derives from several fun-
damental characteristics [35]. First, team members need
to successfully integrate their individual actions. Team
processes become a critical determinant of team per-
formance. Second, teams are increasingly required to
perform in complex and dynamic environments. These
performance requirements heighten the need for mem-
ber coordination and cohesion. Team leadership repre-
sents a third characteristic of eective team performance
[28].
Kotter [22] noted that providing leadership means
inuencing others to take responsibility for identifying,
developing, retaining, and motivating talented profes-
sionals on the team. The most popular leadership style
classication contrasts transactional and transforma-
tional leadership styles. The transactional leadership
style represents traditional views on leadership, which
focus on the contractual relationship between the leader
and his/her subordinates in terms of expected perform-
ance in return for certain rewards [33]. The leader
follower relationship is reduced to the simple exchange
of a certain quality of work for an adequate price. It is
believed that such a cost-benet exchange process will
only lead to as expected outcomes and subordinate per-
formance. On the other hand, the transformational
leader, who strongly motivates followers to perform
beyond their expectations, increases the followers sense
174 E. Wang et al. / International Journal of Project Management 23 (2005) 173180
of the importance and value of tasks, and stimulates
members to look beyond their own interests and direct
themselves to the interests of the team, organization or
larger community [26].
Although there is no single leadership style applicable
to all project situations, some IS researchers [7,33] rec-
ommend behavioral charisma for enhanced leadership
eectiveness. For example, Cheung et al.s [7] empirical
survey conducted in Hong Kong indicated that the char-
ismatic leadership style has the most impact on team
member satisfaction. Interestingly, the charismatic lead-
ership style is often the most dominant style in Asian
countries [7].
Contemporary thought suggests that charismatic
leadership results in a strong internalization of the lea-
ders values and goals by the followers, moral commit-
ment to these values, and a tendency for followers to
transcend their own self-interests for the sake of the col-
lective [17]. Meanwhile, Kayworth and Leidner [20] dis-
covered that highly eective team leaders act in a
mentoring role and exhibit a high degree of understand-
ing (empathy) toward other team members. Other
researchers [19] suggest that making the team members
enthusiastic about the project, developing trust, building
condence and commitment, and acting as a role model
are the critical behaviors for eective team leadership. In
short, the literature suggests that the charismatic leader-
ship style is an eective behavior style for project
managers.
Meanwhile, cohesion is viewed as the single strongest
predictor of group behavior. The denition of group
cohesiveness for this study is the extent to which group
members feel a part of the group and desire to remain in
the group. According to Levin and Moreland [24],
groups can be made more successful by strengthening
their cohesion. Highly cohesive groups are better able
to force members to comply with group positions
[4,32]. Group cohesiveness also results in uniformity of
group members [25], and makes the group more eec-
tive. Cohesion is one of the important facets of team-
work quality. There are several factors, including
leadership style [35], that inuence the will of team mem-
bers to remain on the team and work to each other. If
there is no desire for members to work together and to
commit with each other, it will be impossible to main-
tain the team and for members to perform their jobs
well.
Past studies focus on measuring team performance in
terms of whether the team meets predetermined quality,
time and cost objectives [10,15], or in terms of team
members work satisfaction [15]. Hackman [12] pro-
posed a three-dimensional model of group performance,
which provides a comprehensive framework for the
understanding of group performance. This framework
considers the groups contribution to: (1) its embedded
organization; (2) to itself, and (3) to its composite mem-
bers. For the rst dimension a groups performance is
measured by the degree that the group meets quantity,
quality, and timeliness standards. The second dimension
focuses on the degree to which the process of carrying
out the work enhances the capability of members to
work together interdependently in the future. Finally,
the third dimension measures the group performance
as the degree to which the group experience contributes
to the growth and personal well-being of team members.
2.1. Research model
Fig. 1 depicts this studys research framework. Three
constructs are included in the research framework; the
charismatic leadership style that the ERP project leader
exhibits, the cohesiveness of the project team, and overall
team performance. The proposed model suggests that
charismatic leadership will have a positive inuence on
the project teams cohesiveness and the project teams
overall performance. Furthermore, we argue that the de-
gree of team cohesiveness has a positive relationship
with project teams overall performance. Support for
these arguments is provided in this section.
Charismatic leaders excite and transform previously
dispirited followers into active followers by heightening
motivation and instilling a sense of purpose [6]. The lea-
der is idealized and becomes the model of behaviour that
engenders followers commitment [30]. Charismatic
leadership is often positively related to the eectiveness
of the leader. For example, charismatic leaders have
been shown to receive higher performance evaluations
[5] and have been rated by superiors as top performers
[13]. Based upon Zaccaro, Rittman, and Marks [35]
proposed team leadership theory, leaders functions
(behaviors) will inuence team motivational processes.
In particular, leaders planning and goal setting and
motivation of team members can enhance team cohe-
siveness. Although there is no empirical evidence found
in the IS literature, studies in other disciplines (such as
management) show that charismatic leadership is posi-
tively related to team members eorts and commitment
to the team [21]. Based upon team leadership theory and
the empirical ndings discussed above, we, therefore,
propose the following hypothesis:
Cohesiveness
Project Team
Performance
Charismatic
Leadership
Fig. 1. Research model.
E. Wang et al. / International Journal of Project Management 23 (2005) 173180 175
H1: The charismatic leadership style will positively
inuence the extent of team cohesiveness during ERP
implementation.
Team leadership theories specify leadership as a cen-
tral driver of team processes and team performance.
Many studies examine leadership style eectiveness
resulting from charisma, although most organizations
are primarily interested in project team member eec-
tiveness. After all, the goal of eective leadership is in-
creased positive results from subordinates and the
resulting eects on organizational outcomes. Some
empirical studies show the link between charismatic
leadership and team performance, both in the US and
abroad [3]. In the IS literature, Thite [33] also argued
that transformational (or charismatic) leadership can in-
crease teams overall performance. Based upon the team
leadership theory and the empirical ndings, we propose
the following hypothesis:
H2: The charismatic leadership style will positively
inuence the overall project team performance during
ERP project implementation.
The relationship between group cohesiveness and
group performance has been well studied. Two recent
meta-analytic studies conclude that there is a positive
relationship between group cohesion and group per-
formance [9,27]. Although some researchers argue that
other variables (e.g. work environment) may moderate
the relationship between team cohesiveness and per-
formance, team development theorists, in general, agree
that cohesiveness is central to the study of group dynam-
ics and performance [36]. Unfortunately, the IS litera-
ture oers no empirical evidence of the relationship
between IT project team cohesiveness and team per-
formance. Based upon the above discussion, we propose
the following hypothesis:
H3: There is a positive relationship between extent of
the team cohesiveness and project teams overall
performance.
3. Research method
3.1. Sampling
Three hundred companies listed in the Top 500 of
the largest corporations in Taiwan 2001 that had
implemented ERP systems were sent a questionnaire.
Any key person, except the leader, of the ERP project
teams in each company was asked to ll out and send
back the questionnaire. Before the questionnaire was
delivered to the respondents, each company was ap-
proached at least two times to locate the key respondent.
Background information on the research theme was
provided to the respondent. Among the 300 companies
surveyed, 106 returned the questionnaire, which makes
a response rate of 35.3%. Given that the data were col-
lected in Taiwan, detailed demographic information is
provided below.
Among the 106 respondent companies, more than
half had implemented more than seven ERP system
modules. About 21.4% of respondent companies have
fully implemented the ERP systems. About 63.7% of
the implemented ERP systems came from local vendors
in Taiwan, such as DSC (15.6%), IE (5.8%), ProYoung
(5.8%), with the rest coming from foreign vendors, such
as SAP (10.7%), Oracle (13.6%) (see Table 1).
More than half (52.4%) of the ERP implementation
project teams have more than 10 people in implementing
ERP systems. The majority of respondents (77.5%) re-
port that they have been with their current company
form more than three years. A minority (41.2%) of the
ERP project leaders had no experience in ERP imple-
mentation. Very experienced leaders were relatively rare
(14.4%). Fifty-six of the 103 respondents companies as-
signed the information department manager to be the
ERP project team leader (see Table 2).
The respondent companies represent various indus-
tries, such as electronic product (21.4%), information
products (11.7%), iron and steel (10.7%), other various
manufacturing (16.5%) and service industries (10.7%).
About 21.6% of respondents companies have more than
one thousand employees, while 52% of respondents
companies have more than 350 employees. About 35%
of them have an information department with more
than ten employees. About 63.6% of respondents com-
panies have capital in excess of 500 million NT dollars.
Finally, the companies, on average, have been in exist-
ence for more than 20 years (see Table 3).
3.2. Measures
3.2.1. Charisma leadership style
The questionnaire developed by Cheung et al. [7] and
based on Basss [5] Multifactor Leadership Question-
naire, was adapted to measure charismatic leadership
Table 1
Background information on ERP systems
Characteristics Categories Responses Percentage
Number of
modules
15 38 46.6
610 62 50.5
>10 3 2.9
ERP system
vendor type
Domestic
vendor
DSC 16 15.6
IE 6 5.8
Proyoung 6 5.8
Fast 2 1.9
Others 36 35.0
Foreign
vendor
SAP 11 10.7
Oracle 14 13.6
JDE 2 1.9
Baan 1 1.0
Others 9 8.7
style. The wording of some items was rened to reect
the ERP project team context. A ve-point response
scale was used (from 1 = never to 5 = always) to meas-
ure the frequency of the charismatic leadership
behaviors.
3.2.2. Cohesiveness
Items used in this study to measure team cohesiveness
were developed by Hoegl and Gemuenden [15]. All items
were on a ve-point Likert scale (from 1 = never to
5 = always) to indicate the frequency of aforementioned
behaviors.
3.2.3. Team performance
Questions from Gemuenden and Lechler [10]
and Hoegl and Gemuenden [15] were employed to
measure team performance. Four items were used to
measure team eectiveness and three items were used
to measure team eciency. Each question was measured
on a ve-point Likert scale (from 1 = strongly disagree
to 5 = strongly agree).
A conrmatory factor analysis (CFA) was conducted
to examine the validity of the constructs used in this
study. When conducting a CFA, if the model provides
a reasonably good approximation to reality, it should
provide a good t to the data. The CFA for the meas-
urement model resulted in a Root Mean Square Resid-
ual of 0.05 (60.10 is recommended), a v
2
/Degree of
Freedom ratio of 2.31 (60.3 is recommended), a Com-
parative Fit Index of 0.90 (P0.90 recommended), and
a Non-normed Fit Index of 0.90 (P0.90 recommended).
The measurement model was adequate for the data set.
Convergent validity can be assessed through t-tests on
the factor loadings, such that the loadings are greater
than twice their standard error [2]. The t-tests for the
loadings of each variable are in Table 4. The constructs
demonstrate high convergent validity since all t-values
are signicant at the 0.05 levels. In addition, the reliabil-
ity of each construct is examined by the Cronbach a-
value. The Cronbach a-values exceeded the recommend
level of 0.70. Discriminant validity is assessed by the
condence interval test [2]. A condence interval test in-
volves calculating a condence interval of plus or minus
two standard errors around the correlation between fac-
tors, and determining whether this interval includes 1.0
(or 1.0). If the interval (for each pair of constructs)
does not include 1.0, the discriminant validity is demon-
strated. The results of the condence interval tests sup-
port the discriminant validity of the constructs in this
study.
4. Data analsysis and results
A path analysis with structural equation modeling
was conducted to test the hypotheses. The theorized
model in Fig. 1 t the data reasonably well, with a Root
Mean Square Residual of 0.04, a v
2
/Degree of Freedom
Fit of 1.83, a Comparative Fit Index of 0.92, and a Non-
normed Fit Index of 0.90. Table 5 shows the results of
the structural equation model analysis. Hypotheses
H1, H2, and H3 were all supported with path coe-
cients of 0.44, 0.48, and 0.37, respectively. The t-statis-
tics for these three hypotheses all exceeded signicance
at the 0.05 level, indicating these relationships hold sta-
tistical signicance.
Table 2
Background information on ERP teams
Size of ERP
implementation
team
<5 19 18.4
610 35 34.0
1120 25 24.3
>20 24 23.3
Average tenure
of team
members
13 23 22.4
35 31 30.1
57 21 20.4
79 16 15.5
>9 11 10.7
N/A 1 1.0
Leaders experience
on ERP
implementation
(from 1 = no
experience to
7 = very experienced)
1 40 38.8
2 3 2.9
3 7 6.8
4 6 5.8
5 19 18.4
6 8 7.8
7 14 13.6
N/A 6 5.8
Leaders aliation Information 56 54.4
Production 4 3.9
Accounting/nance 11 10.7
Human resource 2 1.9
Marketing 1 1.0
Others 28 27.2
N/A 1 1.0
Table 3
Background information on respondent companies
Industry type Electronic product 22 21.4
Information product 12 11.7
Iron and steel 11 10.7
Others 58 56.3
Total number
of employees
<100 18 17.6
101300 31 30.1
301500 19 18.4
5011000 13 12.6
>1000 22 21.4
Number of employee
in information
department
<10 72 69.9
1150 24 23.3
>50 7 6.7
5. Discussion and conclusions
ERP implementation projects often require intensive
cross-functional coordination and cooperation. As a re-
sult, ERP project success is heavily dependent on hu-
man factors such as project leaders and team
members eorts and commitments. Jiang et al. [18]
and Thite [33] found that project leadership is an
important factor to the successful delivery of an infor-
mation system. Specically, the charismatic leadership
style of ISD project managers has been argued as an
eective management behavior for fusing team mem-
bers personal goals with team missions and, thus,
establishing the groups cohesion [7]. Zaccaro et al.
[35] also argued that the charismatic leadership style
has direct eects on team task cohesiveness and subse-
quent performance. Nevertheless, there is a paucity of
empirical studies on the impact and role of charismatic
leadership style in ERP implementation. The present
study serves as an initial step to explore the impacts
of charismatic leadership style on team cohesiveness
and, thus, team performance in the context of IT
implementation.
The results indicate that the ERP project leaders char-
ismatic leadership style signicantly inuences the level
of team cohesiveness, which, in turn, aects the overall
project team performance. This result is consistent with
Cheung et al.s [7] ndings that charismatic behavior
has a signicant inuence on project team members
behaviors and eorts. The result also conrmed with
Thites [33] study that charismatic leadership style can
have signicant eects on project performance. Given
that the culture studied in Cheung et al. [7] and this study
is similar, conrmation of the earlier study provides evi-
dence of the external validity of the ndings of this study.
To further examine the generalizability of this nding,
two additional demographical variables (i.e., project
managers experience and industry type) were included
as control variables. The results did not change signi-
cantly. Interestingly, while industry type did not have a
signicant inuence on project outcomes, the project
managers experience had a signicant, positive impact.
This result indicates that, regardless of the leadership
style adopted by the managers, the project managers
experience has a positive inuence on the nal project
outcomes.
Table 4
Measurement model conrmatory factor analysis results
Construct indicators Standardized loadings t-Value Alpha
Charismatic leadership 0.93
CL1 makes the team members enthusiastic about the project 0.68 7.64
*
CL2 is a model for me to follow 0.79 9.42
*
CL3 makes me feel good to working with him 0.78 9.30
*
CL4 makes me feel proud to be associated with him 0.87 10.94
*
CL5 as a member of the project team member, I have complete faith with him 0.91 11.80
*
CL6 readily trust his judgement to overcome any obstacle 0.88 11.21
*
Cohesiveness 0.94
C1 it was important to the members of our team to be part of this project 0.88 11.20
*
C2 the team members strongly attached to this project 0.93 12.33
*
C3 the members of our team felt proud to be part of the team 0.91 11.75
*
C4 every team member felt responsible for maintaining and protecting the team 0.85 10.62
*
Project team performance 0.88
PT1 going by the results, this project can be regarded as successful 0.83 9.98
*
PT2 from the companys perspective, all project goals were achieved 0.67 7.36
*
PT3 the project results was of high quality 0.83 9.92
*
PT4 the product proved to be stable in operation 0.72 8.06
*
PT5 from the companys perspective one could be satised with how the project progressed 0.76 8.76
*
PT6 the project was within schedule 0.64 6.91
*
PT7 the project was within budget 0.52 5.38
*
RMSEA: 0.04 (60.10 recommended); Bentlers CFI: 0.93 (P0.90 recommended); v
2
/DF ratio: 1.80 (<3 recommended); Bollen (1988) NNFI: 0.91
(P0.90 recommended).
*
Signicant at p-value <.05 level.
Table 5
Summary of hypotheses tests
Hypothesis Coecient t-Value
H1: charismatic leadership !cohesiveness 0.44 4.47
*
H2: charismatic leadership !project team performance 0.48 5.01
*
H3: cohesiveness !project team performance 0.37 4.20
*
*
Signicant at p-value <.05 level.
The present study provides several important impli-
cations for business managers interested in the imple-
mentation of ERP systems. First, a qualied leader is
critical to ERP project team performance. In addition
to the ERP project team leaders technical prociency,
top management should place more emphasis on the
project leaders leadership style. Second, the results spe-
cically indicate that there are potential benets from
considering the charismatic leadership model when
selecting and training ISD project managers.
Finally, today a considerable amount of IS project
work is contracted out to independent ISD contractors
who have little or no organizational loyalty. In addition,
there is a growing trend to perform ISD through global
virtual teams where members come from dierent parts
of the world, which aords few opportunities to interact
face-to-face, yet face challenging group tasks. Given the
importance of project leadership, organizations must
understand the impacts of various dierent leadership
styles in such dynamic situations. As pointed out previ-
ously, the impact of ISD project managers leadership
styles on project team performance is just beginning to
receive attention from IS researchers. This study pro-
vides the rst empirical evidence of the importance of
ISD project managers ability to instill a strong sense
of purpose, beliefs and values in team members. This
has a positive inuence on team members cohesiveness,
which, in turn, impacts team performance.
More research is needed to investigate how charis-
matic leadership behavior brings about higher team per-
formance. Currently, most studies examine the impact
of charisma on team leader eectiveness, while project
team performance may be of greater interest to many
organizations. To the best of our knowledge, this is
the rst empirical study in the IS literature that exam-
ines the relationship between charismatic leadership
and project team performance. Understanding how
far-reaching and long-lasting the eects of charismatic
leadership are is also an area for future research. One
can be deemed an eective charismatic leader, but given
todays wider spans of control and increased emphasis
on self-management, future project teams performance
may drop if the eects of charisma fail to be robust
and long-lasting. In this study, group cohesiveness was
identied as a mediator between charismatic leadership
behavior and project team performance. Other variables
needed to be identied that may impact the eect of
charismatic leadership on project teams. This is an area
of research that should be examined further. Another
interesting future research direction is the relationship
between project managers experience and their leader-
ship styles (and their interactions) on the IS project
development and implementation.
A major limitation of this study should be noted.
The data examined in this study were collected in Tai-
wan and, due to culture dierences, the results of this
study may not hold in other countries. Several factors
mitigate this limitation. First, detailed demographic
information about the organizations were provided
allowing readers to better interpret the ndings. Sec-
ond, the proposed research model was supported by
strong theoretical arguments. Finally, the results are
consistent with previous studies conducted in other
countries. Arguably, without hard evidence to the
contrary, we expect the results of this study to hold dur-
ing IS implementation projects in other countries (espe-
cially, in Asia). Certainly, future research that replicates
this study with dierent samples would not only en-
hance the external validity of this study but could also
provide additional insights of our understanding on
project managers leadership styles.
Acknowledgement
This research is supported by the MOE Program for
Promoting Academic Excellence of Universities under
the Grant No. 91-H-FA07-1-4.
References
[1] Alderfer CP. An inter-group perspective on group dynamics. In:
Lorsch JW, editor. Handbook of organizational behavior. Engle-
wood Clis, NJ: Prentice-Hall; 1987. p. 190222.
[2] Anderson JC, Gerbing DW. Structural equation modeling in
practice: a review and recommended approach. Psychol Bull
1988;103:41123.
[3] Avolio BJ, Waldman DA, Einstein WO. Transformational
leadership in a management game simulation. Group Organ Stud
1988;13:5980.
[4] Back K. Inuence through social communication. J Abnorm Soc
Psych 1951;46:923.
[5] Bass BM. Leadership and performance beyond expecta-
tions. New York: Free Press; 1985.
[6] Burns JM. Leadership. New York: Harper & Row; 1978.
[7] Cheung SO, Ng ST, Lam KC, Yue WM. A satisfying leadership
behavior model for design consultants. Int J Project Manage
2001;19(7):4219.
[8] Conger JA, Kanungo RN. The empowerment process: integrating
theory and practice. Acad Manage Rev 1988;13(3):47182.
[9] Evans CR, Dion KL. Groups cohesion and performance: a meta-
analysis. Small Group Res 1991;22:17586.
[10] Gemuenden HG, Lechler T. Success factors of project manage-
ment: the critical few. Reviewed paper, Portland international
conference management of engineering technology, Portland,
Oregon; July 1997. p. 2731.
[11] Hackman JR. The design of work teams. In: Lorsch JW, editor.
Handbook of organizational behavior. NJ, Englewood
Clis: Prentice-Hall; 1987. p. 67102.
[12] Hackman JR. Groups that work (and those that dont): creating
conditions for eective teamwork. San Francisco: Jossey-Bass;
1990.
[13] Hater JJ, Bass BM. Superiors evaluations and subordinates
perceptions of transformational and transactional leadership.
J Appl Psychol 1988;73:695702.
[14] Herb K. Ensuring E-business success by learning from ERP
failures. IT Prof 2000;2(1):227.
[15] Hoegl M, Gemuenden HG. Teamwork quality and the success of
innovative projects: a theoretical concept and empirical evidence.
Org Sci 2001;12(4):43549.
[16] Holland CP, Light B. A critical success factors model for ERP
implementation. IEEE Software 1999;16(3):306.
[17] House RJ, Spangler WD, Woycke J. Personality and charisma in
the US presidency: a psychological theory of leadership eective-
ness. Acad Manage Proc 1990:21620.
[18] Jiang JJ, Klein G, Chenoun-Gee H. The relative inuence of IS
project implementation policies and project leadership on even-
tual outcomes. Project Manage J 2001;32(3):4955.
[19] Katzenbach J, Smith D. The discipline of teams. Harvard Bus
Rev 1993:11120.
[20] Kayworth TR, Leidner DE. Leadership eectiveness in global
virtual teams. J Manage Inform Syst 2001;18(3):740.
[21] Kirkpatrick SA, Locke EA. Direct and indirect eects of three
core charismatic leadership components on performance and
attitudes. J Appl Psychol 1996;81(1):3651.
[22] Kotter J. The leadership factor. New York: Free Press; 1988.
[23] Krumbholz M, Galliers J, Coulianos N, Maiden NAM. Imple-
mentation enterprise resource planning packages in dierent
organizational and national cultures. J Inform Technol
2000;15:26779.
[24] Levin JM, Moreland RL. Progress in small group research. Ann
Rev Psychol 1990;41:585634.
[25] Lott AJ, Lott BE. Group cohesiveness as interpersonal attraction:
a review of relationships with antecedent and consequent
variables. Psychol Bull 1965;64:251307.
[26] Mackenzie SB, Podsako PM, Rich GA. Transformational and
transactional leadership and salesperson performance. J Acad
Market Sci 2001;29(2):11534.
[27] Mullen B, Copper C. The relation between group cohesiveness
and performance: an integration. Psychol Bull 1994;115:
210227.
[28] Nygren R, Levine EL. Leadership of work teams: factors
inuencing team outcomes. In: Beyerlein MM, Johnson D,
Beyerlein ST, editors. Interdisciplinary studies of work teams.
Team leadership, vol. 3. Greenwich, CT: JAI Press; 1996. p.
67104.
[29] Schermerhorn Jr JR, Hunt JG, Osborn RN. Organizational
behavior. New York: Wiley; 2000.
[30] Seltzer J, Bass BM. Transformational leadership: beyond initia-
tion and consideration. J Manage 1990;16(4):693703.
[31] Stewart G, Milford M, Jewels T, Hunter T, Hunter B. Organi-
zational readiness for ERP implementation. Am Conf Inform Syst
2000:96671.
[32] Thibaut JW. An experimental study of the cohesiveness of
underprivileged groups. Hum Relat 1950;3:25178.
[33] Thite M. Leadership styles in information technology projects. Int
J Project Manage 2000;18:23541.
[34] Weber M. The sociology of religion [Transl. Ephraim Fisc-
ho]. Boston: Beacon Press; 1963.
[35] Zaccaro SJ, Rittman AL, Marks MA. Team leadership. Leader-
ship quarterly 2001;12(4):45183.
[36] Zander A. The psychology of group processes. Ann Rev Psychol
1979;30:41751.
Standardized project management may increase
development projects success
Dragan Milosevic
a,
*
, Peerasit Patanakul
b
a
Department of Engineering and Technology Management, Portland State University, Portland , OR, USA
b
Wesley J. Howe School of Technology Management, Stevens Institute of Technology, Hoboken, NJ, USA
Received 20 July 2004; received in revised form 17 September 2004; accepted 23 November 2004
Abstract
Companies frequently opt to implement standardized project management (SPM), which can be dened as a standardized set of
project management practices. These companies expect that such an approach will carry signicant potential for improving project
performance. To investigate this potential, we undertook an exploratory study into the impact of SPM on project performance in
development projects in high-velocity industries. Our research started with the qualitative method using case study research to iden-
tify the major factors in SPM eorts on the organizational project management level (as opposed to the individual project level).
Then, we developed hypotheses based on these factors and performed hypothesis testing to identify factors that impact project suc-
cess. In addition, we conducted the follow-up interviews to enrich and rene our ndings. Three major ndings came out of this
study. First, the variables of SPM tools, leadership skills, and process showed themselves to be of higher interest to standardization
than the other independent variables because they may impact project success; second, these variables of higher interest are typically
customized to t the strategic purpose of the company; and third, companies tend to standardize project management practices only
to a certain level.
Keywords: Standardization; Project management; Development projects; Project performance; Success factors
1. Introduction
According to multiple empirical studies, a companys
eectiveness partly depends on the success of its projects
[1,2]. Consequently, many researchers have investigated
those factors aecting project success, including product
denition, quality of execution, and even project man-
agement techniques [24]. Common to these studies
are that they are done on the individual project level
and they tend to see these success factors as tting all
project situations [5]. In addition, the studies are not
specically conducted for projects in high-velocity
industries.
Some companies in high-velocity industries have rec-
ognized standardized project management (SPM, see
Table 1 for acronyms in this paper) as a strategy for
managing development projects. For example, Brown
and Eisenhardt [6] suggested that critical success factors
can hinge on the degree of standardization of project
practices. Recently, the Project Management Institute
(PMI) issued a new standard, the Organizational Project
Management Maturity Model (OPM3) [7], which sug-
gests SPM as a major strategy. These references suggest
that SPM may have a signicant place in many compa-
nies approach to PM.
Given the signicance of SPM in the industry, it
comes as a surprise that empirical research on the topic
remains sparse, especially on the organizational project
doi:10.1016/j.ijproman.2004.11.002
*
Corresponding author. Address: 1900 SW 4th Avenue, Floor LL,
Suite 50, Portland, OR 97201, USA. Tel.: +1 503 725 4660; fax: +1 503
725 4667.
E-mail address: dragan@etm.pdx.edu (D. Milosevic).
PROJECT
MANAGEMENT
management (OPM) level. Prompted by this paucity of
research, we designed an exploratory study into SPM.
In particular, this study aims to identify and then get a
better understanding of the factors that may impact pro-
ject success and, thus, be of interest in future research
related to SPM eorts in development projects in high-
velocity industries. Specically, the goal is to address
two research questions: What are the major factors in
SPM eorts on the OPM level? And, what SPM factors
on the OPM level are of interest because they may impact
project success?
2. Conceptual background
The context of this research is the high-velocity elec-
tronics, computer, and software industries. According to
Eisenhardt [8], a high-velocity environment abounds
with rapid and discontinuous changes in demand, com-
petition, and technology; in addition, that information is
often inaccurate, unavailable, and obsolete. Lengnick-
Hall and Wol [9] proposed that in these industries:
Disequilibrium and perpetual, discontinuous, radical
change makes all competitive advantages temporary
Organization units and actions are loosely coupled,
stimulating entrepreneurial behaviors
Any advantage is temporary, contributing to sur-
prise, exibility, and unpredictability to a rms stra-
tegic weapons
Continuous disruption is a nonlinear process, and
risk is viewed as a factor to capitalize on
Destabilizing the current environment is focused in
such a way that a succession of eeting advantages
lead to high performance.
In such context, while recognizing Brooks views [10]
of the uniqueness of software development (SWD) pro-
jects, in this study, we believe that there are enough sim-
ilarities between new product development (NPD) and
SWD projects, especially in the electronics, computer,
and software industries. The similarities are in terms
of the level of technological uncertainty, system com-
plexity, and risk involvement, etc. These similarities
and a phenomenon that a multitude of project products
in the electronics and computer industries include both
the NPD (hardware) and SWD (software) components,
led us to study such NPD and SWD projects together,
called development projects.
Technological uncertainty: This issue is closely
related to the degree that the project uses novel versus
mature technologies. Projects involving more novel
technologies are considered to have a higher techno-
logical uncertainty than those with more mature tech-
nologies. For example, breakthrough NPD projects
that create product platforms based on a new gener-
ation of technology are characterized by a higher
level of technological uncertainty than derivative
NPD projects, whose purpose is to adapt the plat-
form for a certain market niche [11]. Similarly, an
SWD project focusing on maintenance, including
minor upgrades, has a lower level of technological
uncertainty than a breakthrough program. Since the
essence of NPD and SWD projects is innovation advan-
tage, a large portion of these projects deal with a med-
ium to high level of technological uncertainty.
System complexity: This issue can be conceptualized
as a combination of product characteristics, func-
tional mission, and organizational structure. For
example, imagine a project with a single component
and a single function of a limited scale that is imple-
mented within a functional group, such as the devel-
opment of a computer hard drive or development of a
software translator. In contrast, a complex project
would have multiple components and multiple func-
tions and require the involvement of multiple organi-
zations, e.g., development of a new generation of
computers or a large software suite. Many NPD and
SWD projects have medium to high levels of system
complexity, which causes further complexities in their
development process (e.g., complexity of team com-
munication, project structure, and project schedule)
and product [10].
Risk involvement: NPD and SWD projects are
among the riskiest endeavors for the modern com-
pany and those risks tend to hit NPD and SWD pro-
jects from many angles. A risky situation may be
severe when the rm has limited knowledge and expe-
rience with the product and process technologies that
they intend to incorporate into the product [11]. In
both NPD and SWD projects, the risk level increases
if the project involves many personnel, has a high
application complexity, involves a high number of
technology acquisitions, and lacks of sucient
resources and team expertise. Generally, a signicant
number of NPD and SWD projects are exposed to
medium to high severity of risk.
Table 1
Acronyms used in this paper
Acronyms
ISO International Standards Organization
OPM Organizational Project Management
PM Project Management
PMBOK Project Management Body of Knowledge
SWD Software Development
NPD New Product Development
OPM3 Organizational Project Management Maturity Model
PMI Project Management Institute
SPM Standardized Project Management
WBS Work Breakdown Structure
182 D. Milosevic, P. Patanakul / International Journal of Project Management 23 (2005) 181192
2.1. Measures of project success
Project success measures literature in general PM and
NPD includes several rigorous empirical studies [12,13].
Its dominant view seems to be a stakeholder approach
to project success, wherein each stakeholder group
e.g., customers, senior management, etc. takes a view
of the project success from a dierent angle. The logic
here is that measures of project success need to include
the diversity of stakeholder interests.
In the context of high-velocity industries, project suc-
cess measures literature oers some rigorous empirical
research but much more of trade literature. Examples
from the rigorous empirical research include measures
such as: on time to market (anticipates markets), on tar-
get to market (product meet needs of current custom-
ers), schedule [6] and schedule, cost, quality; quality of
the project management process; customer satisfaction
[14]. Trade literature examples point to schedule, bud-
get, customer satisfaction [15], and market share, prot-
ability index, schedule, budget, stang level [16].
Overall, these measures follow the stakeholder ap-
proach. In addition, the measures can be grouped as
(a) internal measures (e.g., cost, time, quality) and (b)
external measures (beneting organization, e.g., market
share, time to market, protability index; and beneting
customer, e.g., customer satisfaction).
2.2. Project management factors critical to project success
Critical success factors can be described as character-
istics, conditions, or variables that can have a signicant
impact on the success of the project when properly sus-
tained, maintained, or managed [17]. In our literature
search, we did not nd any empirical studies about
SPM factors on OPM level that are critical to the suc-
cess of projects in high-velocity industries. However,
we did nd some studies about SPM factors that are
critical to project success on OPM level. The studies of
Toney and Powers [18] and Kerzner [1] include samples
drawn from high-velocity industries while a study of So-
bek et al. [19] collected samples from company in the
capability-based industries [9].
According to Toney and Powers [18], standardized
process (approaches and procedures) is a success factor.
Standardized PM tools and skill sets for project leader-
ship are identied as critical success factors in a case
study about Toyota projects by Sobek et al. [19]. Finally,
Kerzner [1] claims that standard PM metrics and tools
impact standard PM methodology (i.e., process), which
then inuences project success. Also according to
Kerzner [1], organizational culture and information
management systems impact project success as well.
Our next step was to generally look at other literature
regarding PM factors critical to project success (not spe-
cic to SPM). In the area of high-velocity industries,
Brown and Eisenhardt [6] demonstrate that process,
communication, and interpersonal relationships (trust,
respect, etc.) impact project success. Other researchers
found success factors such as PM process [14,20], project
organization [14,21], tools [20], metrics [14], and culture
[21]. We can conclude that this literature points up three
ideas. First, in most cases, critical factors are correlated
to a construct of an aggregate measure of project suc-
cess. Second, a great deal of the research exhibits a focus
on a single PM area, e.g. project timeliness while some
of reviewed articles attempt to investigate multiple PM
areas. Third, all this research is directed at the individual
project level.
3. Research method
3.1. Research process
The research approach is summarized in Fig. 1. Basi-
cally, this is an empirical study that combines qualitative
and quantitative methods. According to Eisenhardt [22],
the case study research is necessary at times when little
is known about a phenomenon, current perspectives seem
inadequate because there have little empirical substantia-
tion. In our case, such phenomenon is SPM on OPM in
high-velocity industries. Hence, we believe that it is
appropriate to use a case-study research methodology
as the rst step to develop SPM constructs drawn from
real-life context, and use its results for subsequent steps
of developing and testing hypotheses for the quantita-
tive study (research step 2). To ensure the validity of
our ndings and to enrich and rene them, we imple-
ment research step 3, the follow-up case interviews,
which is again of qualitative nature. We believe that
this research process is very appropriate in searching
for answers to our research questions and environ-
ments in which we undertake our study. Details are as
follows.
In research step 1, we used multiple methods such as
semi-structured interviews with 12 project managers (six
organizations), review of related SPM documents, and
observations. We started informally with open-ended
questions, asking them to tell stories of SPM initiatives.
Then, we asked them to describe their experiences in
SPM eorts and identify variables that make SPM ef-
forts successful. After nalizing individual interviews,
we performed content analysis and a cross-case analysis,
forming ideas, concepts, and insights of the inner work-
ings of SPM initiatives. As is suggested by Eisenhardt
[22], literature review was also performed as part of this
case study research (shown earlier in sections: Measures
of Project Success and Project Management Factors
Critical to Project Success). The purpose of the literature
review was to build internal validity, raise theoretical le-
vel, and sharpen construct denitions [22,23]. The col-
D. Milosevic, P. Patanakul / International Journal of Project Management 23 (2005) 181192 183
lected data were used to develop seven hypotheses and a
questionnaire for the research step two (qualitative re-
search). These seven hypotheses were developed based
on seven SPM factors: process, organization, informa-
tion management systems, tools, metrics, project cul-
ture, and leadership, found from case study research.
After being tested by ve PM practitioners for clarity
and to ensure construct validity, the questionnaire was
administered to project participants in various PM
workshops. Such collected data were used for testing
our hypotheses (see the next section for measures, sam-
ple, and data analysis methods).
In research step 3, we conducted multiple follow-up
interviews with ve individuals from ve companies in
our sample. We selected these companies because they
had a solid SPM level. The purpose was to add rich-
ness to the interpretations of the data analysis results
in other words to verify and enrich ndings of
hypotheses testing and learn more about the research
results.
3.2. Measures
Our questionnaire included these measures:
(1) One dependent variable the degree of project
success operationalized as a multi-item construct aggre-
gating four criteria: the degree to which the projects
accomplished their schedule, cost, quality, and customer
satisfaction goals; as perceived by respondents on a 5-
point Likert scale (5 being the highest degree, 1 being
the lowest degree). Here is an example of a question
measuring project success on cost: Please indicate to
what degree these projects met the following goals
and its format.
Very low Very high
1 2 3 4 5
Cost goals h h h h h
In the sample question, these projects refers to the
frame of reference: recently completed projects in which
the participants were involved. Similar questions were
asked about schedule, quality, and customer satisfaction
goals. Note that there are several reasons we have cho-
sen these goals. First, most of our respondents did have
limited information about strategic goals mentioned in
the earlier literature review section on project success.
Rather, they had knowledge about the internal view
goals such as schedule, cost, and quality, as well as cus-
tomer satisfaction (the only goal from the external
view). Second, project success measures similar to ours
have been extensively used in some rigorous PM
research on NPD projects some of which are from high
velocity industries [24]. Finally, respondents had limited
time in which to complete this survey; therefore our need
to limit the size of the questionnaire.
(2) Seven independent variables on OPM level:
standardized PM process (Hypothesis 1, referred to as
H1), organization (H2), information management sys-
tems (H3), tools (H4), metrics (H5), project culture
(H6) and leadership (H7).
To illustrate the measuring process, here is an exam-
ple using the rst factor, the PM process. In order to
measure the degree of PM process standardization, we
dened standardized according to Stevenson [25]:
the degree of uniformity or consistency applied in imple-
menting PM process. Thus, the highest degree of unifor-
mity (i.e., standardization) is when the PM process is
implemented by all project managers in the same way.
In contrast, when the PM process is inconsistently used
and not shared by all project managers, we considered it
to have the lowest degree of uniformity/standardization.
To capture the numerical responses of our respon-
dents as to the degree of PM process standardization,
we again used a 5-point Likert scale (5 being the highest
degree of standardization, 1 being the lowest degree of
standardization). And we asked questions like the fol-
Step 1:
Qualitative method
Research Question:
1
Research Approach:
Multiple-case approach
Major Activity:
Data gathering & analysis
Outcome:
Constructs defined
Step 2:
Quantitative method
Research Question:
1 and 2
Research Approach:
Survey
Major Activity:
Data gathering &
hypothesis testing
Outcome:
Quantitatively based
findings
Step 3:
Qualitative method
Research Question:
1and 2
Research Approach:
Multiple-case approach
Major Activity:
Follow-up interviews
Outcome:
Qualitatively enriched
findings
Fig. 1. The three-step approach for this research.
lowing: To what degree is your OPM process shared
and consistent across projects?
Very low Very high
1 2 3 4 5
h h h h h
Using the same format, we asked questions about the
degree of standardization of PM tools, PM metrics, pro-
ject culture, and leadership skills. Similar questions were
used to measure the degree of standardization of project
organization and information management systems. For
example, To what degree does your organization use
managerial mechanisms (e.g., a project management of-
ce or project approval committee) to ensure consistent
practices in synchronizing and aligning all projects with
the business strategy?
Very low Very high
1 2 3 4 5
h h h h h
One question was used for each variable. Such single-
item constructs are generally less eective than multi-
item constructs. However, from the reliability test of
our questionnaire, we found that Cronbachs alphas
were higher than the threshold value 0.7, as recom-
mended by Nunnally [26]. This indicates that our ques-
tionnaire is reliable.
(3) Demographic information: Here, we focused on
the type of organization, the type of project, the size
of the project, and the PM experience of the respondents
(number of years).
3.3. Sample
A nal qualifying sample included 55 project partic-
ipants (project directors, project managers, and team
members) from development projects in high-velocity
industries. Of the business units, 31 were in com-
puter/software industries; 24 were in electronics indus-
tries. As for the size of the project budget, 37% of
the projects had a budget greater than $5 million, while
28% had a budget larger than $500,000 but smaller
than $5 million, and 35% had a budget less than
$500,000.
3.4. Data analysis
To test each of the seven hypotheses, we used the
same statistical plan: two methods of bivariate data
analysis along with one multivariate method. The bivar-
iate methods were Pearson product-moment correlation
between each independent and dependent variable, and
t-test, which assesses the signicant dierence in means
between the top group and the bottom group of cases
in terms of project success. First, we divided all our data
points for project success (dependent variable) into the
low group (average score 12.33 on the Likert scale),
the middle group (average score 2.343.66), and top
group (average score 3.675). Then for each group, we
calculated the mean value of standardization of the se-
ven independent variables.
The assumption here is that the top group with the
highest project success will have the highest degree of
SPM factors. If so, the t-test will indicate signicant dif-
ferences between the top group and the bottom group
for each independent variable, proving our hypotheses.
Stepwise multiple regression analysis was used in order
to validate the previous bivariate analyses. Several
regression runs were performed, eliminating the correla-
tion eects between the independent variables.
4. Research results
4.1. Case study ndings
After nishing interviews, document reviews, and
observation in the research step 1 (see Fig. 1), the con-
tent analysis pointed to the following SPM factors on
OPM level critical to success in high-velocity industries
projects under seven major headings standardized
PM process, organization, information management
systems, tools, metrics, project culture and leadership.
Table 2
Factors aecting the success of development projects
Factor critical to project success Publications that identied the factor as critical
PM process Zmud [20]
a
; Deephouse et al. [21]; Brown and Eisenhardt [6]; Sobek et al. [19];
Davidson et al. [27]; Cooper [2]; Hartman and Ashra [14]
Project organization Larson and Gobeli [28]; Deephouse et al. [21]; Davidson et al. [27]; Cooper [2];
Hartman and Ashra [14]; Shenhar et al. [13]
Information management system Davidson et al. [27]
PM tools Zmud [20]; Might and Fisher [3]; Sobek et al. [19]
PM metrics Davidson et al. [27]; Hartman and Ashra [14]
Project culture Deephouse et al. [21]; Sobek et al. [19]; Davidson et al. [27]
Project leadership Sobek et al. [19]; Davidson et al. [27]
a
Note: Italicized are sources relating to high velocity industries. Other sources are from other industries.
As already mentioned, literature review was performed
as part of this case study research [22], and directly-re-
lated (references relating to high velocity industries)
and indirectly-related references (references from other
industries) are included into Table 2.
In particular, the rst step indicated that:
SPM factors on OPM level may have a positive cor-
relation with project success. In other words, increas-
ing standardization degree of the factors may lead to
increased project success.
Some interviewees believe that there is an inection
point in this standardization increase. Specically,
increasing the degree of standardization of the factors
to a certain point may lead to the increase in project
success. Increasing the degree of standardization of
the factors beyond that point tends to lower project
success. Where this inection point exactly is appears
to be company-specic, meaning that it varies from
company to company.
To verify these ndings from research step 1, we
chose a simple design for next two research steps
(Fig. 1). In research step 2 we formulated hypotheses
to test our rst ndings SPM factors on OPM level
may have a positive correlation with project success
(next section). In research step 3, we conducted fol-
low-up interviews to learn more about our ndings
and second nding from research step 1 the inection
point.
Why did we choose this research design? This is an
exploratory study trying to develop an understanding
of basic correlations such as what SPM factors may help
improve project success. Adding to this is the number of
data points that is limited and relatively simple (single-
item constructs). Given such intent and data set we
thought that simple correlation coecients and linear
regression would be a right choice of testing tools. When
it comes to the inection point and its location, which is
subjective in nature, we believe that a qualitative method
of follow-up interviews is appropriate.
4.2. Hypothesized factors critical to project success in
SPM
In research step 2, the seven SPM factors were used in
formulating hypotheses and developing questionnaire to
collect data for hypotheses testing. By using the intervie-
wees justication for why these SPM factors impact
project success on the OPM level and acknowledging
the ndings from the literature focused on individual
project success, we hypothesize that project success in
SPM on the OPM level in high-velocity industries likely
depends on standardization of the PM factors aecting
project success. In particular, project success likely de-
pends on these hypothetical factors:
Hypothesis 1. Hypothesis 1 focuses on Standardized
PM Process for OPM: A higher degree of standardizing
PM process tends to increase the success of development
projects in high-velocity industries.
Rationale: Several studies identied the PM process
as an important success factor in development projects
[2,14,20,21]. Based on this logic, then, standardizing
the PM process for development projects on the OPM
level may also lead to their success. In particular, such
a standardized process may drive the quality of execu-
tion of all elements of the process to a higher level,
including standardized project life-cycle phases, project
activities, and milestones. In the words of one group
of researchers, SPM process on the OPM level can save
project participants the cost of reinventing a new pro-
cess for each individual project and have a positive im-
pact on project success [19].
Hypothesis 2. Hypothesis 2 deals with Standardized
Project Organization for OPM: Development projects in
high-velocity industries organized by more standardized
practices of the project organization are more successful.
Rationale: Multiple researchers have found that
cross-functional, team-based project organizations are
more successful than those without such organization
[2,28]. Instead of this well-researched project-level view
of the project organization, our study investigates an
OPM level project organization, a relatively new organi-
zational design said to have an important impact on
project success. Frequent components of OPMs organi-
zational design are project oces tasked to take care of
specic PM practices, aiming at standardizing ways to
align organizational projects with the organizations
business strategy. Examples of these practices are pro-
ject prioritization, resource capacity management, and
portfolio balancing. The expectation is that the stan-
dardized practices will facilitate the accomplishment of
project goals. As a consequence, this integration of the
companys projects should lead to increased project suc-
cess [1].
Hypothesis 3. Hypothesis 3 concerns Standardized
Information Management System for OPM: Using a
more standardized OPM-level information management
system leads to higher success of development projects in
high-velocity industries.
Rationale: Software-based PM information systems
are often seen as contributing to project success
[27,29]. Until recently, these systems were solely focused
on the desktop software. Currently, an emphasis is also
being placed on a standardized information manage-
ment system on the OPM level, which is designed to
integrate the desktop with Internet and enterprise sys-
tems. That enables management to integrate individual
projects into a coordinated pool, including standardized
information input from individual projects and output
for the pool and individual projects. Also, this helps
management to keep an eye on the pool and allocate
necessary resources to it. Consequently, the pool is less
prone to yield negative surprises and unexpected results.
In this way, the systems capacity for gathering, integrat-
ing, and disseminating the standardized information
output facilitates the controls in development projects
in high-velocity industries, thus contributing to project
success.
PM Tools for OPM: Development projects in high-
velocity industries that use more standardized PM tools
tend to increase their project success.
Rationale: PM tools include procedures and tech-
niques by which a PM deliverable is produced. While
many argue that adequately deployed PM tools have a
signicant role in accomplishing project goals, the re-
lated research evidence is scanty. The little available evi-
dence points to the use of certain tools as factors in
project success [3,13,20]. We posit that deploying more
standardized PM tools as an OPM approach ensures
higher quality in implementing project activities and,
thus, a smoother process and the contribution to the
success of projects. Examples of the tools that are often
standardized are a WBS and the Gantt chart.
Hypothesis 5. Hypothesis 5 considers Standardized PM
Metrics for OPM: Development projects in high-velocity
industries using a more standardized system of metrics to
measure and monitor project performance will have higher
project success.
Rationale: Historically called project performance
measures, metrics help measure and monitor project
performance. They are often cited as a key to a develop-
ment projects success [27]. If metrics were designed as a
standardized system for OPM, they would include a
structured and consistent set of measures for all strategic
areas of project health. Such a set would also be tiered to
reect success indicators for all management levels in a
project. Additionally, the sets metrics would be mutu-
ally compatible to create a further level of uniformity
on the OPM level. When consistently applied, this stan-
dardized set would help detect how well the project
strategy works and where and why it is awed. It can
also help devise actions to eliminate the aws, hence
increasing chances for success.
Project Culture for OPM: Development projects in high-
velocity industries where cultural values are more stan-
dardized tend to have increased project success.
Rationale: Organizational culture has been cited as a
key success factor in development and innovation pro-
jects [30]. This culture is expressed as a set of clearly
articulated, performance-oriented values [31] that are
designed into PM practices/behaviors and then uni-
formly practiced (we call this a standardized culture).
The intention here is that project personnel in OPM
have a sense of identity with the cultural values and ac-
cept the need to invest both materially and emotionally
in their project. This should make them more engaged,
committed, enthusiastic, and willing to support each
other in accomplishing the project goals. As a result,
they should work harder and be more eective, increas-
ing success.
Hypothesis 7. Hypothesis 7 is related to Standardized
Project Leadership for OPM: Development projects in
high-velocity industries that are managed by project
managers with more standardized skill sets tend to have
improved project success.
Rationale: The concept of a strong project leader as a
key to project success has been a recurring theme of
many studies and many experts [32]. As a consequence,
there is a strong drive in todays OPM approaches to de-
ne standardized project leadership skills. Examples of
the skills include customer intimacy and risk mitigation.
The expectation is, as Sobek et al. [19] argued, that pro-
ject managers equipped with the same set of standard
skills will be more eective in accomplishing their tasks,
hence driving success of development projects.
4.3. Results from hypothesis testing
Tables 3 and 4 present a summary of the bivariate
analysis and stepwise regression results of testing
hypotheses 17. We view these results as tentative be-
cause of the exploratory nature of the study [33]. In
summary, out of seven factors hypothesized to have an
impact on project success, three were found to be of
interest: standardized PM tools, leadership, and process.
4.3.1. Standardized project management tools, leadership,
and process are of interest
As shown in Table 3, correlation coecients of 0.48,
0.46, and 0.43 show a signicant relationship between
the standardized PM tools, leadership, and process,
respectively, and project success. t-tests conrmed that
there are signicant dierences in the standardization
of these three variables between the high and low
groups. This means that there is a possibility that higher
standardization of PM tools, leadership, and process
may contribute to higher project success. Still, the im-
pact of these three SPM factors on project success is
not very high.
Stepwise multiple regression was used to validate the
previous bivariate analyses (see Table 3). Only one fac-
tor standardized PM leadership entered the equa-
tion. In the analysis, one predicted variable may
capture the explained variance of the dependent variable
by using its correlated factors. As a result, the correlated
factors may not enter the equation. Since some SPM
factors were strongly correlated with leadership for
example, the correlation values between the leadership
and PM tools and process are 0.42 and 0.39 (at
p < 0.01), respectively it is quite possible to get a short
list of factors in the equation. Specically, our list in-
cludes only PM leadership as this predicted variable
was statistically signicant at 0.03 level. The equation it-
self was also strongly signicant at the 0.004 level. The
explained variance (adjusted R
2
) of project success by
using leadership as predictor was 0.25, indicating that
other important factors beyond standardized PM lead-
ership, standardized PM tools, and process impact pro-
ject success as well, not an unusual phenomenon in
studies of this type. For example, the well-cited study
of Cooper and Kleinschmidt [24] had adjusted R
2
scores
of 0.27 and 0.21. This modest explained variance indi-
cates that other important factors beyond SPM factors
impact project success. In summary, Hypotheses 1, 4
and 7 were supported.
4.4. The four standardized project management factors of
lower interest
The four factors with little or no impact on project
success in the statistical analysis were standardized met-
rics, the information management system, project cul-
ture, and project organization. This nding was
further corroborated by the stepwise regression, wherein
none of these SPM factors enter the equation (Table 3).
Because they do not appear to impact project success,
Hypotheses 2, 3, 5 and 6 are NOT supported.
Note that in research step 3, we discuss these ndings
with the practitioners to enrich and rene these ndings.
The results of these multiple-case interviews are summa-
rized in the next section.
5. Discussion
5.1. The state of PM standardization
We made some observations about the overall state
of SPM, something not in our original plan of research.
It appears that the level of PM standardization in our re-
search sample is solid. When we calculated the mean
standardization score for all three critical SPM factors,
we found that the mean value is 3.20. A value of 3.20
out of 5.00 may look like a mediocre level of PM stan-
dardization. However, the following two reasons pro-
vided by our interviewees oer an explanation. First,
the PM standardization concept is a relatively new phe-
nomenon that has not had much time to inltrate com-
panies. Second, an approach of lower standardization
with a sucient amount of variation in PM methodol-
ogy is actually linked to the inection point we learned
about in the research step 1 (Fig. 1). In particular, we
learned from preliminary interviews that increasing the
degree of standardization of the factors to the inection
point may lead to the increase in project success. How-
ever, increasing the degree of standardization of the fac-
tors beyond that point tends to lower project success.
Also, the location of the inection point seems to be
company-specic. In the follow-up interviews of the step
3, we heard the same. The rationale is that because of
their high speed, complexity and risk level, lower degrees
of SPM factors with a sucient amount of variation in
SPM are a more appropriate approach to running pro-
jects in high velocity industries. Brown and Eisenhardts
Table 3
Impact of standardized project management factors on development project success (bivariate analysis, N = 55)
Standardized project management factor Correlation
Coeecient
a
Mean values of standardization of project
management factors
Top vs. low group,
t-test
Low group
b
project success
Middle group
b
project success
Top group
b
project success
Standardized PM process 0.43
c
(p < 0.01) 2.33 2.40 3.25 2.01 (p = 0.05)
Standardized project organization 0.05 3.00 2.68 2.92 .14
Standardized information management system 0.27 2.50 2.28 3.21 1.19
Standardized PM tools 0.48 (p < 0.01) 2.33 2.88 3.88 3.65 (p < 0.01)
Standardized PM metrics 0.24 2.00 2.88 3.29 2.53 (p = 0.00)
Standardized project culture 0.08 2.33 3.28 3.21 1.62
Standardized project leadership 0.46 (p < 0.01) 2.33 3.40 4.00 4.39 (p < 0.01)
a
Correlation coecients.
b
Mean values of standardization of each PM factors for low, mid, and top groups of projects in terms of project success.
c
Bold numbers are statistically signicant.
Table 4
Multiple regression analysis of project management success versus
standardization of project management factors (multivariate analysis)
Standardized project management factor Beta coecient (p-value)
Standardized Project Leadership 0.24 (p = 0.03)
N = 55; R
2
= 34%, R
2
adj
25%, signicant at <0.01 level.
research conrms these beliefs of the interviewees in
high-velocity industries [6].
What we have not found out was at what standardi-
zation degree the inection point was determined. Try-
ing to be pragmatic, it seems that most companies
opted to create an SPM methodology and set a broad
rule that project managers are allowed to decide when
to veer o the SPM, and simply improvise within the
boundaries of SPM. In words of one of the interviewees,
we want our project mangers to be process experts, not
process slaves. The point is that this company has a
standardized PM methodology but empowers project
managers who really know the methodology inside out
to change it as an uncertain project task and environ-
ment pose challenges. Some companies followed a pro-
cedure that project managers had to request an
approval for deviating from SPM.
5.2. Three standardized project management factors of
interest
Based upon our results, there is a possibility that
higher standardization of PM tools contributed to high-
er project success in our sample of companies. To better
understand the nature of standardizing PM factors, we
conducted several follow-up interviews (note the small
number of interviews a limitation factor), which also
yielded several best practices, shown in Table 5. If stan-
dardized PM tools are not oered to project managers,
the interviewees argued, it is not reasonable to presume
that each one of them especially the less-experienced
would have the resources and expertise to quickly and
consistently select their own set of tools. According to
the interviewees, having standardized PM tools helps
with project success: more punctual schedules, more sat-
ised customers, better cost-eectiveness, and higher-
quality accomplishments.
This nding was somewhat surprising to us. First,
some research studies found PM tools to drive project
success on the individual project level [3,13]. From this
perspective, our nding is not a surprise. What was a
surprise is that our study indicated that standardized
PM tools (as a group of tools) on OPM level may impact
project success; this is new. The reason for this, as seen
by the interviewees, is perhaps rooted in the practice of a
great many companies, where the standardized PM tools
are integrated with the PM process in order to consis-
tently support process deliverables at necessary times.
According to our results from statistical analysis and
the follow-up interviews, project managers with stan-
dardized project leadership skill sets are likely to be
more successful and eective, thus inuencing project
success. It appears that our interviewees believe that
such skill sets are critical because project managers in
development projects in high-velocity industries often
act in a matrix environment, where they have no direct
Table 5
Examples of best practices in standardized project management factors
Factors that may impact project success in SPM Examples of best practices
Standardized PM Tools Select mutually compatible tools that work in sync; use them consistently.
Balance simple and advanced tools.
Integrate tools with the standardized PM process; each process deliverable is
supported by specic standardized PM tools.
Start o with template tools; adapt the templates for use in a specic project.
Standardized Project Leadership Both lead and manage; managing provides functions of planning, organizing,
and controlling projects; leading adds the ability to develop project vision,
communicate the vision, inspire and motivate project participants.
Standardize business skills (e.g., customer intimacy or reading
nancial statements).
Standardize process skills (e.g., project scope and schedule management).
Standardize interpersonal skills (e.g., conict management and negotiations)
and intrapersonal skills (e.g., self-motivation).
Standardize technical skills (e.g., knowledge of project product applications).
Standardized PM process Build a shared process, where all project managers use the same standardized
PM process.
Build a repeatable process that provides the same sequence of project phases,
end-of-phase gates, milestones, activities, and major deliverables to each project.
Build a exible process that clearly encourages and states how to adjust the
standardized process to account for specics of projects with signicantly dierent
size and complexity.
Build an integrated PM process whose elements are linked with upstream and
downstream processes (e.g., strategic planning) to provide the integration of the
overall business process across the organization.
authority over project team members but still bear the
responsibility for delivery of the project. Faced with
this dicult task, project managers are more likely to
deliver on cycle time, customer satisfaction, quality,
and cost goals when given a standardized skill set that
can address all sorts of project challenges than they are
when left to randomly develop such skills. We were not
surprised by this nding. The earlier research in con-
ventional manufacturing industries, for example, that
of Sobek et al. [19] corroborates our nding.
Testing results also point to the possibility that pro-
jects organized via standardized PM processes contrib-
ute to improved project success in our sample of
companies. Our interviewees argued that customers
expect projects to be delivered according to their
requirements. In an organization engaged in many
projects, this means repeatability. The organization
must be able to consistently deliver a stream of con-
secutive projects per customer requirements every
time. As a consequence, such projects minimize varia-
tion in how they are executed, improving speed and
quality, leading to lower cost because they result in
less rework, fewer mistakes, fewer delays and snags,
and better use of time. The interviewees believed that
the level of repeatability is higher when a standardized
PM process is in place. This nding was not unex-
pected, even that there is no prior SPM process re-
search on OPM level. Many researchers have found
that the PM process may be a factor in project success
on the individual project level [4,19,27,1,13]. Perhaps,
quality management initiatives total quality manage-
ment and ISO 9000, for example that were intro-
duced to the corporate world and PM in the 1980s
and 1990s which strongly emphasized process stan-
dardization also helped PM process standardization.
In summary, standardized PM tools, leadership, and
process on the OPM level may have an impact on higher
project success and, therefore, are candidates for more
detailed future research. This tentative statement should
be viewed in the context of the exploratory nature of this
study, its research design, and the small number of fol-
low-up interviews.
5.3. The four standardized project management factors of
lower interest
We described the four SPM factors the standard-
ized project organization, information management sys-
tem, PM metrics, and project culture as low interest
factors because the statistical analysis in this exploratory
study showed them to be of little signicance. Our fol-
low-up interviews help us in interpreting this nding.
According to the interviewees, the concepts of stan-
dardized project organization and information manage-
ment system (on OPM level) are new to most
companies. Because of this short timeframe, the two
SPM factors as the interviewees explained might
have not been widespread enough in our sample in order
to make a discernable impact.
As for standardized PM metrics, the interviewees
have seen the metrics as a required part of SPM but
not of high importance. Perhaps this may hint to
the modest correlation of the metrics with project suc-
cess (correlation coecient is 0.24; t-test conrms this;
Table 3).
In our discussions with the interviewees, many of
them expressed the view that standardized project cul-
ture equated with organizational culture, which they
saw as the province of executive management, not
project personnel; i.e. as not being important to pro-
ject participants.
5.4. This studys ndings vs. industry practice
To see how much our ndings are in agreement with
the practices in the industry, we referred to Project Man-
agement Body of Knowledge (PMBOK) [29], a widely
accepted document. We found that PMBOK talks about
SPM practices on more than 15 occasions taking up 1.5
pages out of 200+, while placing a strong emphasis on
the standardized PM tools and processes, but ignoring
other SPM factors. Over all, PMBOK is light on
SPM, focusing primarily on the individual project level.
OPM3, another standard from PMI, a recently released
document on the OPM level is heavy on SPM, suggest-
ing standardization as a rst step in the implementation
of all processes in project, program, and portfolio man-
agement. The major emphasis is on PM process and
tools, although some emphasis is placed on metrics,
organization, and information systems. Over all, while
PMBOK 2000 showed some support, OPM3 [7] points
to a high level of support of industry practices for
SPM and our ndings.
6. Managerial implications
This exploratory studys objective was to identify and
then get a better understanding of the factors that may
impact project success and, thus, be of interest in future
research related to SPM eorts in development projects
in high-velocity industries. The ndings of the investiga-
tion point out that some factors are of higher interest
than the others. In this section, we sum up our learning
from the investigation.
Standardized PM may drive project success. Our nd-
ings indicate that increasing the level of standardization
of some PM factors may lead to higher project success.
Building a standardized PM toolbox may help. Creat-
ing a standardized PM toolbox on the OPM level, this
study found, may help accomplish project goals, an es-
sence of project success.
Growing project managers with standardized project
leadership skills may matter. It appears that project man-
agers with standardized project leadership skill sets may
be a factor in project success.
Insisting on a standardized but exible PM process.
This is another major message coming out of this
exploratory research. Deploying a standardized PM
process from the OPM level may increase project success
but only to a certain point. Increasing standardization
further beyond this point which we referred to as an
inection point may actually stie project success.
Hence, providing exibility in the form of allowed vari-
ation in SPM methodology beyond the point is
recommended.
Using a contingency approach in standardizing PM.
This approach means that one size of SPM factors does
not t all organizations. In short, project success and
SPM factors that may enhance it will be customized to
t the strategic purpose of the company, and thus each
organization may have its own set, or size, of SPM
factors on the OPM level.
It is wrong to assume that standardizing PM factors
will automatically enhance project success. Standardizing
PM may not necessarily improve project success and we
cannot argue that increasing the level of standardization
of PM factors will automatically lead to an increase in
project success.
The most original contributions from this research
study are in the OPM and exibility areas. In the
OPM area, a primary contribution is the focus on the
overall organizational orientation. In particular, most
of other the well-known studies of critical project suc-
cess factors such as [2,14,20,21,27,28], took what Eng-
wall [34] called a lonely project approach. This means
developing the factors to accomplish success in individ-
ual projects. Our study takes a dierent view, looking at
issues of interest related to those factors standardizing
PM practices that help successfully manage projects
individually and collectively. Our approach, although
only exploratory, opens up the research on success
factors thru standardization on the OPM level. The sec-
ond area of contribution, in the exibility area, is the
identication of an inection point, which hints to a
strong need for a certain level of variation in implement-
ing standardized practices in development projects in
high-velocity industries. This receives scant attention
in the existing studies on critical success factors. While
the contributions in terms of type of critical success fac-
tors that we identied are not unique tools, leadership,
and process, identifying them so solidly makes them
more useful for future researchers and practitioners.
The limitations of the study are its exploratory re-
search design and a relatively small number of data
points; in addition, the ndings reported here relied only
on development projects in the high-velocity computer
and software industries.
7. Conclusions
Signicant results and lessons of this exploratory
study can be organized around its two research questions.
First, what are the major factors in SPM eorts on the
OPM level? Second research question, what SPM factors
on the OPMlevel are of interest because they may impact
project success? We uncovered the seven factors that may
have a role in SPM eorts. These include standardized
PM tools, leadership, and process; and standardized
PMorganization, information management system, met-
rics and culture on OPM level. Testing of our hypotheses
indicated that the rst three factors are of higher interest,
the remaining four may be of lower interest.
These lessons learned underscore that major contri-
butions of this research are the identication of criti-
cal factors on OPM level, and the nding that
companies tend to standardize PM only to a certain
level (inection point), while maintaining a certain
level of exibility.
A further step in comprehending the evolving nature
of SPM on the OPM level would include more research
to validate that these SPM factors are critical. Also,
more empirical testing is necessary to learn more about
the correlation of standardized enterprise project orga-
nization, information management systems, and project
culture and project success. Light should be also shed on
how an organizations competitive strategy inuences
the architecture of its SPM. Finally, studying compa-
nies strategies for deploying SPM factors would be
another high-value research topic.
References
[1] Kerzner H. Appliedproject management. NewYork: Wiley; 2000.
[2] Cooper RG. Winning at new products. Reading, MA: Perseus
Books; 2001.
[3] Might RJ, Fisher WA. The role of structural factors in
determining project management success. IEEE Trans Eng
Manage 1985;32(2):717.
[4] Pinto JK, Slevin DS. Critical factors in successful project
implementation. IEEE Trans Eng Manage 1987;34(1):227.
[5] Shenhar AJ. One size does not t all projects: exploring classical
contingency domains. Manage Sci 2001;47(3):394414.
[6] Brown SL, Eisenhardt KM. The art of continuous change: linking
complexity theory and time-paced evolution in relentlessly shift-
ing organization. Administrative Sci Quart 1997;42:134.
[7] PMI, Organizational Project Management Maturity Model (OPM3)
2004. Newtown Square: Project Management Institute, 2004.
[8] Eisenhardt K. Making fast strategic decisions in high-velocity
environments. Acad Manage J 1989;32(2):54376.
[9] Lengnick-Hall CA, Wol JA. Similarities and Contradictions in
the Core Logic of Three Strategy Research Streams. Strategic
Manage J 1999;20:110932.
[10] Brooks FPJ. No silver bullet: essence and accidents of software
engineering. IEEE Computer 1987;20(4).
[11] Wheelwright SC, Clark KB. Revolutionizing product develop-
ment. Quantum leaps in speed. eciency, and quality. New
York: The Free Press; 1992.
[12] Pinto JK, Slevin DS. Project success: denitions and measurement
techniques. Project Manage J 1988;19(3):6773.
[13] Shenhar AJ, Tishler A, Dvir D, Lipovetsky S, Lechler T.
Rening the search for project success factors: a multi-
variate, typological approach. R&D Manage 2002;32:
11126.
[14] Hartman F, Ashra RA. Project management in the information
systems and information technologies industries. Project Manage
J 2002;33:515.
[15] Shachtman N. What to look for in metrics. Information Week
Online, 1998.
[16] Martinelli R, Waddell J. The program strike zone: beyond the
bounding box. PM World Today 2004;VI(1).
[17] Leidecker JK, Bruno AV. Identifying and using critical success
factors. Long Range Planning 1984;17(1):2332.
[18] Toney F, Powers R. Best practices of project management groups
in large functional organizations. Drexel Hill: Project Manage-
ment Institute; 1997.
[19] Sobek D, Liker J, Ward A. Another look at how Toyota
integrates product development. Harvard Business Rev
1998;76(4):3649.
[20] Zmud RW. Management of large software development eorts.
MIS Quart 1980;4:4555.
[21] Deephouse C, Mukhopadhyay T, Goldenson DR, Kellner MI.
Software processes and project performance. J Manage Inform
Syst 1995;12:187205.
[22] Eisenhardt KM. Building theories from case study research. Acad
Manage Rev 1989;14:53250.
[23] Yin R. Case study research: design and methods. 2nd edition.. In:
Bickman L, editor. Applied social research methods, vol.
5. CA: Sage Publications; 1984.
[24] Cooper RG, Kleinschmidt EJ. Determinants of timeliness in
product development. J Product Innovation Manage
1994;11:38196.
[25] Stevenson WJ. Production/operations management. Bos-
ton: Irwin; 1993.
[26] Nunnally JC. Psychometric theory. New York: McGraw-Hill;
1978.
[27] Davidson JM, Clamen A, Karol RA. Learning from the best new
product developers. Research-Technol 1999:128.
[28] Larson EW, Gobeli DH. Signicance of project management
structure ondevelopment success. IEEETrans Eng Manage 1989;36.
[29] PMI, Project Management Body of Knowledge (PMBOK) 2000.
Newtown Square: Project Management Institute, 2000.
[30] Prather CW. Keeping innovation alive after the consultants leave.
Res Technol Manage 2000;43(5):13745.
[31] Cooke RA, Rousseau DM. Behavioral norms and expectations: a
quantitative approach to assessment of organizational culture.
Group Organizational Studies 1988;13:24573.
[32] McDonough III EF. Investigation of factors contributing to the
success of cross-functional teams. J Product Innovation Manage
2000;17:22135.
[33] Cooper R, Emory CW. Business research method. Chi-
cago: Irwin; 1995.
[34] Engwall M. No project is an island: linking projects to history and
context. Res Policy 2003;32:789808.
The use of dependence structure matrix and domain mapping
matrix in managing uncertainty in multiple project situations
Mike Danilovic
a,
*
, Bengt Sandkull
b,1
a
Jo nko ping International Business School, Jo nko ping University, P.O. Box 1026, SE-551 11 Jo nko ping, Sweden
b
Malmo University, School of Teacher Education, SE-205 06 Malmo , Sweden
Received 21 February 2003; received in revised form 29 June 2004; accepted 17 November 2004
Abstract
Development of complex products is performed in multi-project environment in which it is crucial to explore interdependencies
and manage the uncertainty with the information exchange and the understanding of the context. The purpose of this paper is to
introduce a dependence structure matrix and domain mapping matrix approach that enables the systematic identication of inter-
dependencies and relations in a Multi-project environment. These approaches enables clarications of assumptions, the tractability
of dependencies, explores the information needed within and between dierent departments, projects and people. This creates a
transparency and enables the synchronization of actions through transformation of information and exploration of assumptions
within and between domains. The outcomes of this process are situational visibility creating direction and accountability and the
learning that takes place through communicating, reecting, understanding, and acting.
Keywords: Multiproject; Complexity; Uncertainty; Complex project; Dependence structure matrix; Domain mapping matrix
1. Introduction
Product development of complex products is usually
organized in many dierent projects. Each of these pro-
jects focuses on dierent functionality or physical parts
of the product. Due to the complexity of the product
and the scarcity of resources, projects run concurrently,
sequenced, or overlapped, which creates a huge demand
for an exchange of information between people in tem-
porary projects, the customers, and the suppliers. This
kind of environment may be labeled the multi-project
situation. It is characterized by the multitude of interde-
pendencies between projects, tasks and activities, people,
knowledge areas, technologies, products, and
components.
No matter how we organize the process for product
development, there will always be interdependencies be-
tween components, sub-systems, departments, projects,
groups, and individuals who need to share information
with others to fulll their tasks. Von Hippel [1], who
claims that a characteristic of product development is
the partitioning of tasks, activities, or components, rec-
ognizes this problem and argues that the character of
these interdependencies inuences the way in which
product architecture is organized into chunks or han-
dled by teams and individuals.
Precisely where the boundaries between such tasks
are placed can aect the project outcome and the e-
ciency of the task performance due to associated
changes in the problem-solving interdependence among
tasks. The core function of many innovation projects
doi:10.1016/j.ijproman.2004.11.001
*
Corresponding author. Tel.: +46 36 157588; fax: +46 36 161069.
E-mail addresses: Mike.Danilovic@jibs.hj.se (M. Danilovic),
Bengt.Sandkull@lut.mah.se (B. Sandkull).
1
Tel.: +46 46 13 46 77.
PROJECT
MANAGEMENT
and project tasks is precisely problem solving and the
generation of new information (Von Hippel [1, p. 407]).
Product development is a process of uncertainty
reduction in problem solving. Our approach in this pa-
per emphasizes uncertainty as the normal state we have
to face. The crucial issue of uncertainty is to understand
who needs information, what kind of information is
needed, why and when, and to nd ways to share and
exchange information with others. If information is
not available when it is needed the level of uncertainty
is increased as assumptions are needed to be made. This
view stresses the need for other principles than those
established that will promote management of uncer-
tainty by creating organizational settings to achieve a
high degree of coordination and integration in the prob-
lem solving. Communication and the ow of informa-
tion in product development need in product
development to take into account the mesh of relations
and interdependencies characteristic already in a single
project but crucial in a Multi-project environment.
In this paper, we consider complexity as originating
from three major sources: the functionality of a product,
chosen technology, and people involved. These three
dimensions are interwoven creating uncertainty that
management has to handle in project management and
organization. The traditional approach to manage the
complexity of a product is by systematic decomposition
of a product into components and elements or an orga-
nization into departments, and by integrating compo-
nents into chunks and sub-systems and people into
projects and teams [2,3]. Breaking down a complex sys-
tem or integrating items requires assumptions about the
content, interfaces between items and interdependencies.
All assumptions involve risk taking and produce uncer-
tainty. Justied needs for reappraisal of assumptions
may be avoided. Once you have done the work based
on a set of assumptions, you must test whether the
assumptions were correct. If you do not know what
assumptions you have made, you are in trouble. If you
do not even recognize that you have made any assump-
tions, you are in a heap of trouble [4]. One of the most
important characteristics of product development is that
the process is not linear; it rather encompasses cyclic and
iterative phases [5]. These phases can bring new ideas
into the process, or create rework due to wrong assump-
tions and change of requirements, or they create new
knowledge.
The purpose of this paper is to present an approach
based on the systematic analysis of interdependencies
and relations, the dependence structure matrix (DSM)
and domain mapping matrix (DMM). These approaches
focus on understanding interdependencies between
items, components, organizations, teams, or people, in
terms of the need for the information exchange to man-
age uncertainty through exploring assumptions within
one or between dierent domains in product develop-
ment. Applying multi-dimensional DSM and DMM
analysis will show how this approach might aect work-
ing in multi-project situation performing the product
development of complex systems within one project, be-
tween a project and the basic organization and between
a project and other interrelated projects.
2. Approaches to complexity in product development
2.1. Current approaches to multi-project situations
The traditional approach to project management is to
consider projects as being independent of each other.
Recently, the multi-project situation has been recog-
nized as a major issue for corporations and the focus
in research has shifted towards the multi-project situa-
tion. Several authors have attempted to create an in-
creased understanding of the multi-project situation.
Some indicators suggest that up to 90% (by value) of
all projects are conducted in a multi-project context.
The vast majority of these projects share resources with
other projects and thus the major issue is nding ways of
handling the resource scarcity according to the overall
strategic direction of the corporation [6].
However, there is a need to nd a balance between
the focus applied in one particular project and the
long-term strategy in a stream of dierent projects in
which dierences in goals, visions, and direction may
be seen between projects and long-term strategy [6].
Hendrix et al. [7] found the multi-project situation as a
problem of allocation of scarce resources (i.e., people)
to a diversied project portfolio. They suggest exible
resource planning taking into account the availability
of scarce resources and the need for special knowledge.
The multi-project situation is seen by Grey [8] as a nom-
inal umbrella grouping of projects mainly on the basis of
interdependencies among projects, sub-projects, or any
kind of project-type work activity. Grey suggests that
these interrelationships need to be recognized in terms
of vertical and horizontal relationships to create proper
coordination of project-type work among dierent pro-
jects. The issue of interrelationships between organiza-
tions, individuals and projects is also recognized by
van der Merwe [9], who suggests a similar solution with
the coordination of activities among projects in a ma-
trix-based analysis. The relations between projects are
recognized by Payne [10] and Ghomi and Ashjari [11]
as a major problem with choice of technical solutions,
cost and resource planning, and control.
In our view, complexity itself should be understood
as an analytical issue, while the eects it creates in terms
of uncertainty need to be seen as the issue facing man-
agement. Management does not normally deal with
complexity itself, but the impact of complexity in terms
of uncertainty. When management designs the basic
194 M. Danilovic, B. Sandkull / International Journal of Project Management 23 (2005) 193203
organization as well as temporary project structures, de-
ne the processes in the product development, organize
tasks and activities in project planning, work breakdown
structure and work packages, choose technology and de-
cide the features of the next product to keep up with the
time schedule, uncertainty is the issue. Management
decisions and actions are based on set of assumptions,
implicit or explicit. The levels of assumptions dene
the level of uncertainty.
2.2. Basic dimensions of complexity and uncertainty in
product development
We consider that the nature of the work being carried
through is the prime source of complexity to meet the
product specications and the functional demands on
technical solutions [12]. Complexity in product develop-
ment can be understood in terms of the technology
underlying a product, the technology chosen for compo-
nents and technical sub-systems in the product architec-
ture, and the corporate and social context in which
product development takes place. Complexity is a num-
ber of items interconnected by a multitude of relations
and dependencies between people, their tasks and
activities [1317]. Complexity is determined by the
interdependencies between people, technology, and
functionality although some researchers claim that com-
plexity resides in the minds of people! In that perspec-
tive, complexity is a consequence of our perceptions
and interpretation of the situation. Product architecture
is the basis for creating a task structure and activities to
be performed by engineers. The structure of the task is a
series of actions that people have to perform and that
essentially constitute the development process leading
to an end product. If we can analyze the task structure
according to the relations between product structure
and task structure, we may achieve the information
needed to redene the product structure. This new prod-
uct structure may help us create a dierent process, i.e.,
a set of tasks in a task structure that is more ecient in
terms of time, cost, and performance.
Uncertainty refers to the variation of items or ele-
ments upon which work is performed and the unpredict-
able behavior of people. Some measures of uncertainty
are based on variability of inputs, the number of excep-
tions encountered in the work process, and the number
of major product changes experienced [12]. As we have
pointed out, product development is a process of uncer-
tainty reduction. The risk is a consequence of uncertain-
ties in our assumptions or of uncertainty about future
development and events. Risk is actually a measure of
uncertainty [18]. The most important aspect of uncer-
tainty is to what degree we can understand assumptions
and analyze the information needed to reduce the uncer-
tainty and risk. There are dierent approaches to risk
and uncertainty. Risk management can be handled by
quantitative or qualitative approaches. One quantitative
approach is based on the mathematical approach focus-
ing on systematic analysis of historic and statistics data
[19]. Other is scenario approach focusing on situations,
where it is virtually impossible to specify eects and
probability to any reasonable degree of accuracy. In
such situations, risk is analyzed through scenario simu-
lations [20]. However, qualitative approach to risk and
uncertainty stress that uncertainty is not an objective
quantity, not a xed quantity, nor is it set from possible
situations. In such approach uncertainty is socially con-
structed by the context, rhetorical roles, the assumptions
of purpose, and the acceptance of knowledge claims, i.e.,
how the uncertainties have been constructed by individ-
uals. Such approach stress that uncertainty is con-
structed and reconstructed by individuals and that this
is a social process based on communication, information
exchange, and understanding of the social world as well
as the rational issues of product development. In this ap-
proach, uncertainty arise from ignoring the ignorance as
we take various features of a problem as given and focus
on other dimensions. Uncertainty is also related to a
purpose and goals and the rhetorical context and agency
involved [21]. In our approach, we are close to the social
constructionist approach stressing that communication
and information exchange is crucial for people to under-
stand their own role, the context, the interdependencies
to others, to explore and reduce assumptions to handle
uncertainty and risk in product development.
2.3. Complexity and uncertainty in the multi-project
situation
From the discussion of complexity in general, we can
see that the most important dimensions that we need to
understand concern the sources of complexity: the func-
tionality of a product, chosen technology, and people in-
volved. The traditional reaction by management to
complexity is to ignore it [21,22].
Fig. 1 scrutinizes the reasoning above and visualize
three major sources of complexity: functionality, tech-
nology and people and how they correspond to three
major sources of uncertainty: organizational settings,
product architecture, and project management.
Management issue:
Sources of uncertainty
O
r
g
a
n
i
z
a
t
i
o
n
a
l
s
e
t
t
i
n
g
s
P
r
o
d
u
c
t
a
r
c
h
i
t
e
c
t
u
r
e
Project Management
P
e
o
p
l
e
T
e
c
h
n
o
l
o
g
y
Functionality
Analytical issue:
Sources of complexity
Fig. 1. Complexity and uncertainty in product development.
M. Danilovic, B. Sandkull / International Journal of Project Management 23 (2005) 193203 195
The functionality-related source of complexity is re-
lated to customer demands, functional requirements,
and specications of the product. This dimension aects
project management and goal achievement. The organi-
zation of product development concerns the transforma-
tion of customer demands and product specications
into product architecture and choices of technological
solutions. The project management issue also focuses
on how the available knowledge base can be used to nd
technical solutions that will be feasible in meeting de-
mands on functionality.
The technology-related complexity dimension deals
with the product design, which includes the choice of
making a product modular or integrated, and all the
tasks that, have to be performed in solving the technical
problems.
The people-related complexity dimension aects deci-
sions on how to organize people in the temporary pro-
ject structure and the choice of personnel for the
project teams to match the skills available with the de-
mands of each project. In the multi-project situation, a
crucial issue is nding a balance between working in
projects and developing the long-term technical knowl-
edge of the basic organization. There is still the consid-
erable freedom of choice in a project when technology
and project team have been chosen. Work can be done
sequentially or in parallel. It can be organized according
to some functional logic or to logic of interdependencies.
With concurrent engineering a high degree of integra-
tion of departments and even suppliers and customers
are possible [16,17].
In the multi-project situation, numerous projects aim
at dierent functional solutions using various technolo-
gies that need to be coordinated and integrated in the
product. In many cases, product development is orga-
nized according to the technologies underlying business
decisions and separated into dierent projects. For
example, in the automotive industry, one project may
concern a truck chassis, another engine and drive line,
and a third the electronics, computer hardware and soft-
ware. Each of these projects is dierent regarding the
chosen technology, the people working in projects and
the tasks they perform. What these projects have in
common is that the nal output is not a question of
delivering chassis, engines, computers, or software.
The customers want a complete vehicle according to
the technical specications. It is managements responsi-
bility to organize product development in such a way
that the products can be delivered on time.
The timing of dierent projects, the tasks to be per-
formed, and the assignment of people in dierent orga-
nizational setups meeting the functionality demands of
the product are possibly the most important tasks that
management has to consider, understand, and address.
It lies near at hand to consider the multi-project situa-
tion oating because of the need to handle shared re-
sources and interdependencies between dierent
projects. It is a tricky task for management and even
engineers to understand where interdependencies exist
and to manage possible conicts between departments,
in the project teams and between departments and pro-
ject teams.
3. Application of dependence analysis matrix in a multi-
project situation
3.1. The dependence structure matrix (DSM) and domain
mapping matrix (DMM) approaches
In this paper, we argue that complexity arises from
the relationships and dependencies among items such
as product development-related tasks and activities,
product functionality, components in a product archi-
tecture, and people involved in the process. Variation
among and the number of dependencies and relations
determines the level of complexity [16,17]. When the
level of complexity increases, the level of uncertainty
will probably increase as well, because of the need to
make assumptions about relationships. The crucial is-
sue is how well we can identify dependencies, under-
stand relations, and explore assumptions to turn
assumptions into reasonable facts and thereby reduce
uncertainty.
The methodology that is used to represent and ana-
lyze dependencies and relations between items is known
as DSM or DSM and was introduced by Steward in
1967 [23] and 1981 [24]. These papers are considered
as the starting point of the DSM eld. The major idea
of Steward approach was to handle uncertainty in com-
plex systems by exploring the structure of a problem.
This structure is explored in terms of identifying items
of the problem structure and nding where and how
to make assumptions and make them explicit. The struc-
ture of the problem is seen as a spreadsheet showing for
each information item needed to solve the problem what
other items it directly depends on. These relations are
mapped in a matrix. Matrices are used to map a set of
items toward itself (N N) or to map a set of items to-
ward another set of items (N P).
Figs. 2(a) and (b) shows the principles of matrix-
based analysis, where the dependencies and relations
are plotted in rows and columns. Fig. 2(a) shows three
types of dependencies and how these three are repre-
sented traditionally in a graph and how they are repre-
sented in a DSM matrix. Fig. 2(b) shows how
information ow among six items can be represented
in a ow graph and how they can be represented in a
DSM matrix representation. The DSM represents and
visualizes interdependencies and relations between items
such as tasks and activities, components and sub-sys-
tems, and among people and teams.
A DSM analysis shows how the design of tasks,
sequencing of activities can be organized for the eective
problem solving in team-based work and the communi-
cation required within and between teams [25,26]. The
information captured in a DSM analysis is similar to
that in a directed graph or a PERT chart. However,
the matrix representation makes it possible to create a
more comprehensive model of the information ow
and interdependency analysis in describing and analyz-
ing complex projects. Unlike the PERT technique,
DSM allows tasks to be coupled or independent.
The initial Steward approach was based on one-
dimensional, square, matrixes focusing on activities. In
such a matrix, the analytical focus is to identify depen-
dencies and relations between items to rearrange these
items to nd the most ecient way of sequencing tasks
or activities. The partitioning algorithm used is moving
identied dependencies below the diagonal line. All
dependencies left above the diagonal are assumptions
that may lead to rework and feedback loops.
Over the years the original Steward approach has
been modied. Researchers at Massachusetts Institute
of Technology in Boston introduced new dimensions
in the analysis such as tasks [27], information ow
[28], product parameters, product functionality, and
product architecture [2], people and organizational-
based analysis [29], [30]. An extensive DSM literature
summary is presented by Browning [31]. However, both
the Steward and MIT approaches were based on square
matrixes. This means that analyses of dependencies were
one-dimensional, or in one product development do-
main. Browning [31] provided a taxonomy of these ap-
proaches and identied two discriminating dimensions
related to whether the DSM represented static or time-
based (temporal) dependences. While Brownings taxon-
omy identied four types of DSM applications in these
two dimensions and hypothesized additional applica-
tions and relationships, the analysis focuses on individ-
ual domains represented by square matrices.
In 2001, Danilovic presented studies of dependencies
between dual domains in product development. These
dual domain and matrix-based analyses are called
DMM [32]. The DSM/DMM approaches are comple-
mentary to each other. While the rst focus on one do-
main the other one focus on interactions between
domains.
N N approach is named DSM,
N P approach is named DMM.
In 2001, Danilovic introduced DMM studies on
product architecture vs. organization and in another pa-
per the same year a study on Systems vs. Organization
[33,34]. In 2003, another DMM study was presented
[35]. In this study, several DMM analysis was intro-
duced, Product requirements vs. Functional require-
ment, Functional requirement vs. Product architecture,
Product requirement vs. Product specications, and
Functional requirement vs. Product specications, and
Product specications vs. Product architecture. In
2003, Maurer and co-workers [36] showed one example
of a DMM analysis focusing on domains of product
architecture and customer requirements.
This study presented in this paper introduces a dy-
namic approach to product development by synchroniz-
ing two DSM and one DMM analysis to each other. In
real life, practitioners are dealing with uncertainty in
several dimensions simultaneously. As we suggest in
Fig. 1, uncertainty is about issues of how to organize
people in the basic organization and in many dierent
simultaneously ongoing projects, how to organize peo-
ple in specic project teams such as an engine project,
gearbox project, etc., and nally how to manage the pro-
cess in the developing complete systems, i.e., how to
organize the Multi-project environment and how to
coordinate people and integrate their tasks in many in-
ter-related projects. To manage all these dimensions,
we have introduced two one-domain DSM analysis in
the domains of basic organization and one engine pro-
ject and we have introduced one DMM analysis in the
Multi-project environment. The dynamics come from
the synchronization between these domains and between
DSM and DMM analysis.
3.2. A case using action research
The research approach underlying this paper is an
experiment using two DSM and one DMM analysis in
a real case. We were actively involved in initiating a
DSM REPRESENTATION FLOW REPRESENTATION
A B
A X
B X
Dependence
Structure
DSM
Representation
A B
A
B
A B
A
B X
Parallel Dependencies
Sequential
Dependencies
Pooled
Dependencies
A B C D E F
A
B X
C X
DX
E X X
F X X
A B D
C E
F
A
A
B
B
A
B
G
ie
v
s

I
n
f
o
r
m
a
t
io
n

T
o
Needs Information From
(a)
(b)
Fig. 2. (a) Typologies of dependence structures vs. DSM representa-
tion of dependences. (b) Graph representation of information ow vs.
DSM representation of information ow.
process of developing a new truck program in close col-
laboration with one large truck manufacturing corpora-
tion. This corporation had just started up a series of
inter-related projects aiming at developing new truck en-
gines, gearboxes, chassis, drive lines, and cabins. The de-
mands on management to keep the development within
the time schedule and cost level were high. There was a
need to avoid rework resulting from a lack of under-
standing of the complex situation and inadequate com-
munication among people within the project and in
other related projects, as well as between projects and
other parts of the basic organization.
Using the DSM and DMM approach, we were able
to intervene in the organizing of one engine project with-
in a multi-project situation of 10 other projects and a
functionally organized base organization. We performed
this study in one seminar and divided 60 persons into
three groups that simultaneously performed the DSM/
DMM analysis. The empirical data collected were then
used to reect upon the issues of the multi-project situ-
ation in which management and engineers were in-
volved. The nal data were given to participants and
managers. They together used the data to design com-
munication plans to handle all identied relations and
the need for information exchange needed.
3.3. The organizational premises in development of new
truck program
The experiment was conducted in a real-time situa-
tion at a large international truck-manufacturing corpo-
ration. One of the characteristics of this corporation is
that it has succeeded in modularizing its entire range
of trucks. Modularization has made it possible to intro-
duce continuous product development in each of the
modules under the assumption that the modules are
independent of each other. Some years ago, a major
product renewal program was undertaken: new chassis
and new truck cabins were developed together with sev-
eral new engines, gearboxes, and drivelines. At the same
time, a higher content of electronics was introduced
throughout the entire range of trucks. A great amount
of engineering work needed was performed in a dual
organization structure.
Fig. 3 is an application of Fig. 1 to the real situation
of this truck manufacturing company. Fig. 3 illustrates
the multi-dimensional organizing that characterizes the
development of new truck program. The top left-hand
organizational chart illustrates the prevailing basic orga-
nizational structure, which follows the traditional
departmental and functional logic. The top right-hand
chart illustrates the organizing of engine project. It re-
ects the product architecture of the engine, as each
team is focusing on dierent physical sections of the en-
gine. The bottom-hand chart illustrates the multi-project
situation the truck company faces. The development
program is managed by dividing it into a series of dier-
ent projects.
The basic functional organization has been long in
operation. As much as possible of the development work
was performed in a temporary project organization uti-
lizing cross-functional teams. The major problem con-
fronting top management was the question of how to
organize all the projects simultaneously while each of
these comprised dierent technologies in dierent mod-
ules of the truck system, and how to coordinate all the
tasks and activities among people in projects and in
the basic organization in order to keep to the time sche-
dule and maintain deliveries to the end customer.
Such a complex situation creates uncertainty in prod-
uct development for engineers and management. For
engineers, it is crucial to understand the product speci-
cations and the functional demands that they have to
meet in their engineering work. They are dependent on
other people performing other inter-related tasks some-
where else in other projects, departments, or organiza-
tions. For management uncertainty appears in product
planning and decision-making. How should manage-
ment delimit one project from another? How should
they design the work breakdown structure in order to
enable a high level of concurrency and cross-functional-
ity and at the same time keep the balance between the
demands made by the basic organization and the tempo-
rary organization? How can management keep projects
autonomous in order to enhance adaptation to changes
and at the same time keep track of the total achievement
of specications and functionality of the nal product?
On the project management level, one of the major
problems was to develop a communication plan to help
people perform their engineering work and keep to the
time schedule. For engineers in dierent projects, there
were major tasks in developing skills, keeping track of
what dierent people were doing in dierent projects
and understanding the whole picture of the system of
product development for the new generation of trucks
in which each person had only a limited role.
3.4. The application of DSM and DMM in managing
uncertainty
The DSM and DMM approaches were introduced
when the truck engine project was initiated. During
the kick-o of this project, with approximately 60 peo-
ple, two DSM and one DMM analyses were conducted
in three parallel workshop groups. One group focused
on interdependencies between tasks within the engine
project, another focused on interdependencies between
tasks between the engine project and functional depart-
ments within the basic organization, and the third group
focused on interdependencies between the engine project
and 10 other major projects. The questions asked during
the workshops were: WHAT interdependencies can be
identied. In this case, interdependence was dened in
terms of the need for information exchange in order to
fulll a task, WHO needs to communicate to WHOM
in order to solve their tasks? WHAT kind of informa-
tion need to be exchanged? WHY is this information ex-
change important to other people? WHEN should this
information exchange take place? HOW should people
involved share the needed information with each other
in order to handle interdependencies?
After the workshop, the information recorded was
analyzed and presented in DSM/DMM matrixes and
analyzed. The DSM/DMM analyses were presented to
all people and the outcome of this process was several
communication plans ensuring that identied interde-
pendencies were taken care as indicated above.
Following the above discussion, we have applied
three dierent DSM analyses investigating interdepen-
dencies between the departments of the basic organiza-
tion, within the project organization and between
dierent projects in the multi-project situation. The fo-
cus was on the interdependencies related to the new en-
gine project.
After data collection, identication, and mapping of
interdependencies in the matrix, information is plotted
in matrixes. Rows and columns are then altered in order
to nd clusters that are highly related to each other,
departments within the basic organization, teams within
the engine project, and between teams of the engine pro-
ject and other projects. This analysis is supported by
software tools that we have developed [34,35]. The
search for patterns of interdependencies shows where
the most critical intersections occur and point at those
where special eort are needed in order to enable
coordination.
In Fig. 4, we can see the two temporal DSM (top left
and top right matrixes in Fig. 4) and one DMM (bottom
matrix in Fig. 4) analyses when rows and columns are
altered in order to identify clusters according to identi-
ed interdependencies. The numbers in the boxes indi-
cate the level of dependencies identied. The number 3
signies that the identied interdependence at a specic
row and column intersection was of great importance,
while the number 2 indicates a medium level and the
number 1 a low level of interdependence. No numbers
in row and column intersection signies that no relevant
dependence could be identied.
The top left-hand DSM identies three clusters with-
in the basic organization that are highly related to each
other and that these departments have important inter-
dependencies with respect to the engine project and top
right-hand chart. The top-right hand DSM chart shows
one large and one small cluster between teams within the
engine project that are highly related to each other and
thus require special concern. This chart also indicates
two teams that are related to each other but much less
than the others. The bottom DMM chart shows one ma-
jor cluster of teams within the engine project and four
other projects that are highly related to each other on
the basis of a high level of interdependence. The outer
cluster, shadowed area, indicates that six other teams
have a high level of interdependence to eight projects,
but less intense than that of the other three teams. This
chart also indicates two projects that have few interde-
pendencies to teams in this engine project. In addition,
this chart shows that no teams and no other projects
are completely independent and autonomous.
We can see from these DSM/DMM charts in Fig. 4
that there are a great number of interdependencies be-
tween physically oriented structures of the engine pro-
ject, between this project and the basic organization,
and between this engine project and more or less all
other projects.
CEO
Development
Market &
Environment
Production Commercial Buses & MTR
ENGINE
PROJECT
Gearbox
Brakes
Electronic
System
Cabin
Drive
Line
Chassi
Project Management
V
a
l v
e
M
e
c
h
a
n
i s
m
A
n
a
ly
s
is
a
n
d
S
tr
e
n
g
th
C
ra
n
k
M
o
v
e
m
e
n
t
S
o
ftw
a
re
a
n
d
D
ia
g
n
o
s
e
L
o
n
g
-D
u
r
a
tio
n
T
e
s
t
C
o
n
tro
l
S
y
s
te
m
G
a
s
E
x
c
h
a
n
g
e
S
y
s
t
e
m
E
x
h
a
u
s
t
S
y
s
t
e
m
C
o
m
p
u
te
r
a
n
d
C
a
b
l
in
g
In
je
c
tio
n
S
y
s
te
m
C
o
m
b
u
s
tio
n
S
y
s
t
e
m
E
n
g
in
e
S
t
r
u
c
t
u
r
e
T0=Project
Start
T1=Project
Finish
O
r
g
a
n
i
z
a
t
i
o
n
P
r
o
d
u
c
t
a
r
c
h
i
t
e
c
t
u
r
e
Project interdependencies
Project
Management
Fig. 3. Managing uncertainty in product development.
4. Discussion
As shown in Fig. 4, that no matter how we organize
product development, there will always be intersections
between departments, projects, teams, and individuals
that are interdependent and need to share information
with others. As we have noticed uncertainty and risk
are related to the context and assumptions. The social
constructionist perspective stress communication and
information exchange to reduce the levels of uncer-
tainty. Therefore, a participative approach is important
and it has been used in this case both as a research ap-
proach and as impetus for inuencing the real life of this
truck manufacturing company. By denition, product
development is an iterative process, but the iterations
in the process of product development need to be mini-
mized. Iterations are necessary as a consequence of
changes in input information (upstream), updating of
shared assumptions (concurrent), and discovery of er-
rors (downstream), [25,37,38]. Mapping information
dependence may reveal the underlying structure for sys-
tems engineering, and an organizational team setting
can be designed on the basis of this structure. However,
tasks, specications, and interfaces change during prod-
uct development or when new information is intro-
duced. While product development is dynamic, the
application of DSM or/and DMM are instant. In order
to handle the dynamics of product development DSM
and DMM analyses have to be done repeatedly [34].
The crucial questions, then, relate to how management
and engineers involved in organizational and process de-
sign can deal with such uncertainty.
To confront these questions a systems approach is
suggested starting with three major questions [14]:
The rst question is who is the designer of the system
or the process?
The second question concerns the system evolution
and the processes of change.
The third question considers the role of management.
The rst question points out perhaps one of the most
important issues related to traditional management ap-
proach, i.e., who is designing the system and the process
in terms of organizational and project design. In this
case, we introduced participative use of DSM and
DMM and created a situation in which engineers sup-
posed to perform the engineering work communicated
their tasks with each other, discussed interdependencies,
and needs for information exchange. In addition, they
themselves were able to outline the design of this infor-
mation exchange process. Thus, the organizing of the
project became an issue engaging all involved and not
only a few managers. The DSM analysis provided the
enabling tool that created prerequisites for crucial
communication.
The second question regards the nature of the system
and its management. According to the systems approach
of Buckley [14], we can infer that the product develop-
ment process is equinal. That means that the desired
results may be reached by dierent trajectories with
varying costs and time requirements. However, the pro-
cess of organizing product development work or the
project management is multinal. The planning or the
Fig. 4. Application of dependence structure matrix and domain mapping matrix in product development.
managerial process does not control the progress of the
product development process. Dierent trajectories are
likely to produce dierent outcomes. The consequences
are that there are no ways to specify in advance a proce-
dure that will guarantee the desired outcomes. A partic-
ipative approach enables those involved to design the
organization of the project and the means of communi-
cation to suit their needs for information exchange and
interaction. The experiment showed that their individual
ambitions to solve engineering problems were basedon
knowledge that surpassed most of the managers. By
introducing participative DSM an arena for communi-
cation and mutual project design was created based on
shared understanding of the present and the future
situation.
The third question focuses on management and its
role in this participative process. Westley [39] stresses
that the structure and quality of the communication sys-
tem is a key aspect. Management in a company can use
strategic conversation, discrete communication about
strategic generalities of the project according to overall
goals and milestones and day-to-day activities between
superior and subordinate, as a means of supporting
and maintaining the dynamics of diverse social struc-
tures in collaborative settings. This process of inclusion
creates mutual understandings, feeling of not being a
stranger, brings clarity in areas of authority and respon-
sibility, and helps to shed light on issues of boundary
management. From being strangers, they now become
companions and partners. The dialogue that was devel-
oped during problem-solving when conducting DSM
and DMM analysis created mutual trust and tacit
understanding between team members, promoting sig-
nicant mutual responsibility, and collective commit-
ment [40]. The communicative arena where
participants from dierent departments and projects
meet tries to balance loyalties to the members disci-
plines while also maintaining a healthy respect for oth-
ers. The strategic conversation is a vital mean of
supporting the dynamic behavior of the company. In
this strategic conversation, people can perceive the pic-
ture of the world, within and outside the project. During
this conversation, people may inuence the agenda and
direction of management the project or change their
own views. The aim of this strategic conversation is to
nd ways of integrating the subject (matter?) with the
subjectivity and interpretations of people, substituting
self-organizing based on purposeful sense making for
the execution of power. This conversation needs to con-
sider the diversity of people and their feelings of trust
and integrity. In this respect, the management has the
important role of creating an arena for communicating
the strategic issues that they traditionally regard as their
exclusive prerogatives. Strategic aspects well communi-
cated will let the engineers see their role in the project
and relate it to the big world. The outcome should be
a shared understanding of what needs to be done and
why.
5. Conclusions
In this paper, we have argued that the main sources
of complexity in multi-project situations are the func-
tionally demands of the products, the technologies cho-
sen and the diversity of people involved. We took
complexity as the analytical starting point, while uncer-
tainty becomes the managerial issue. Only in trivial sit-
uations is a managerial control strategy based on
planning eective, even when using the quite sophisti-
cated DSM and DMM analysis as a tool. In the exper-
iment realized in a real-life situation in a truck
corporation, the DSM and DMM approach was used
in a participatory way allowing all involved to discuss
the project proposal and its organizing. The participants
were able to improve on the analysis presented and con-
tributed in designing a systematic means for communi-
cation. The combination of DSM and DMM analysis
enabled the visualizing of interdependencies and rela-
tions and exploring the need for information exchange
to reduce assumptions and uncertainty in product
development.
Traditional DSM-analysis focus on dependencies
and ow of information within one domain. These
one domain analyses can be carried out in dierent do-
mains simultaneously but these analysis do not reect
the dynamics of product development, the need for
transformation of information in one domain in to an-
other domain. In this paper, we introduce dual domain
DMM-analysis that focus on the dynamics in product
development in the sense that these analyses enables
information in one domain to be depicted against some
other or to be transformed into another domain.
DMM-analysis enables the transformation of informa-
tion between domains and by doing this the dynamics
of the development process is explored, and informa-
tion captured in one domain can be used in one
another.
From management perspective, these dual DMM-
analysis in combination with one domain DSM-analysis
provide managers with highly improved decision sup-
port and provide engineers with information of the total
systems. From engineers perspective, DSM and DMM
analysis creates situational visibility, in which people
can understand the context, interdependencies, and the
need for information exchange. This reduces the uncer-
tainty and risk, as people understand the situation. This
leads to transparency within and between domains, i.e.
with a project, between a project and the basic organiza-
tion and between projects.
The most important outcomes of the participative
DSM and DMM were that the management of
uncertainty became a shared responsibility for engineers
and managers. Everybody involved in the participative
process have to be responsible for project organizing
and problem solving, not only those formally assigned
to a management position [41].
Direction for actions of people is now coming from
the intensive interaction and understanding of the con-
text and not from the orders of their managers. Direc-
tion does not come from their hierarchy but rather
from the knowledge of the end customers needs and
business deals on an aggregate level and not only on
their action level. Accountability was earlier related to
what their own managers told them to do. Now
accountability is coming from understanding strategic
aspects of the whole business situation.
The experiment demonstrated as well the dynamic
nature of a product development process. To reect on
the dynamics and uncertainty that change over time
interdependency analyses by the DSM and DMM ap-
proach have to be repeated regularly. Probably one of
the most important outcomes of this process is the learn-
ing that takes place through communicating, reecting,
understanding and nally acting.
Acknowledgments
We express our gratitude to two anonymous review-
ers for their valuable comments on earlier versions of
this paper, and Don Steward that was inspiring us in
the work on DSM and development of DMM
approach.
References
[1] von Hippel E. Task partitioning: an innovation process variable.
Res Pol 1990;19:40718.
[2] Pimmler TU, Eppinger SD. Integration analysis of product
decompositions, Design theory and methodology DTM94,
DE-Vol. 68. ASME; 1994.
[3] Ulrich KT, Eppinger SD. Product design and development. New
York: McGraw-Hill, International Editions; 1994.
[4] Steward DV. A new business paradigm information driven
management, Napa, USA; 2000 [unpublished article].
[5] Adler N. Managing complex product development. Dissertation,
Stockholm School of Economics, The Economic Research Insti-
tute, Stockholm; 1999.
[6] Cusumano MA, Nobeoka K. Thinking beyond lean. New
York: The Free Press; 1998.
[7] Hendriks MHA, Voeten B, Kroep L. Human capacity allocation
and project portfolio planning in practice. Int J Project Manage
1998;17(3):1818.
[8] Grey RJ. Alternative approach to programme management. Int J
Project Manage 1997;15(1):519.
[9] van der Merwe AP. Int J Project Manage 1997;15(4):22333.
[10] Payne JH. Management of multiple simultaneous projects: a
state-of-the-art review. Int J Project Manag 1995;13(3):1638.
[11] Ghomi F, Ashjari B. A simulation model for multi-project
resource allocation. Int J Project Manage 2002;20:12730.
[12] Scott WR. Organizations: rational, natural, and open sys-
tems. Englewood Clis (NJ): Prentice-Hall; 1992.
[13] Perrow C. Complex organizations a critical essay. New
York: Random House; 1984.
[14] Buckley W. Sociology and modern systems theory. Englewood
Clis (NJ): Prentice-Hall Inc; 1967.
[15] Simon H. Administrative behavior: a study of decision-making
processes in administrative organization. New York: The Free
Press; 1957.
[16] Simon HA. The architecture of complexity. Proc Am Philos Soc
1962;106:46782.
[17] Simon HA. The science of the articial. Cambridge, Bos-
ton: Massachusetts Institute of Technology Press, Massachusetts
Institute of Technology; 1969.
[18] Bernstein PL. Against the god the remarkable story of
risk. Wiley; 1996.
[19] Wilson R. Analyzing the daily risks of life. Technol Rev
1979;81(4):416.
[20] Ross JF. The polar bear strategy reections on risk in modern
life. Readings (MA): Perseus Books; 1999.
[21] Jamieson D. Scientic uncertainty: How do we know when to
communicate research ndings to the public?. Sci Total Environ
1996;184:1037.
[22] Danilovic M. Loop leadership and organization of integration
in product development. Dissertation, Department of Manage-
ment and Economics, Linko ping University, Linko ping; 1999.
[23] Steward D. 1967, The design structure systems, General Electric
report no. 67APE6, San Jose, CA; 1967.
[24] Steward DV. The design structure system: a method for managing
the design of complex systems. IEEE Trans Eng Manage
1981;28(3).
[25] Eppinger SD, Whitney DE, Smith RP, Gebala DA. A model-
based method for organizing tasks in product development,
research in engineering design, vol. 6. London: Springer;
1994.
[26] Browning TR. Mechanisms for interteam integration: ndings
from ve case studies. In Proceedings of the 7th international
symposium of INCOSE, Los Angeles, August 37, 1997. p. 649
56.
based method for organizing tasks in product development. Res
Eng Des 1994;6(1):113.
[28] Morelli MM, Eppinger SD, Gulati RK. Predicting technical
communication in product development organizations. IEEE
Trans Eng Manage 1995;42(3).
[29] Kannapan SM, Bell DG, Taylor DL. Structuring information and
coordinating teams in product development, Design theory and
methodology, DE-vol. 53. ASME; 1993. p. 23342.
[30] Browning TR. 1997, Exploring integrative mechanisms with a
view toward design for integration, advances in concurrent
engineering CE97. In: Fourth ISPE International Conference
on Concurrent Engineering: Research and Applications, August
2022, 1997.
[31] Browning TR. Applying the design structure matrix to system
decomposition and integration problems: a review and new
directions. IEEE Trans Eng Manage 2001;48(3).
[32] Danilovic M, Browning T. A formal approach for domain
mapping matrices (DMM) to complement design structure
matrices (DSM). In: Proceedings of the sixth design structure
matrix (DSM) international workshop. September 1214th, 2004.
Cambridge, UK: Trinity Hall College, University of Cambridge,
Cambridge Engineering Design Centre; 2004.
[33] Danilovic M. Supplier integration in product development. In:
Proceedings of the 10th international annual IPSERA confer-
ence, April 811, 2001. Jo nko ping, Sweden: Jo nko ping Univer-
sity, Jo nko ping International Business School; 2001a. p. 253
65.
[34] Danilovic M. Managing multiproject environment. In: Proceedings
of the 3rd international dependence structure matrix (DSM)
workshop, October 2930, 2001. Massachusetts, Boston, Cam-
bridge, USA: Massachusetts Institute of Technology (MIT); 2001b.
[35] Danilovic M, Sigemyr T. Multi domain based DSM tool. In:
Proceedings of the 5th dependence structure matrix (DSM)
international workshop, October 2223, 2003, Cambridge, UK:
University of Cambridge, Cambridge, EngineeringDesignCentre;
2003.
[36] Maurer M, Pulm U, Lindeman U. Tendencies towards more and
more exibility. In: Proceedings of the 5th dependence structure
matrix (DSM) international workshop, October 2223, 2003.
Cambridge, UK: University of Cambridge, Cambridge, Engineer-
ing Design Centre; 2003.
[37] Smith RP, Eppinger SD, Gopal A. Testing an engineering design
iteration model in an experimental setting, Design theory and
methodology, DE-Vol. 42. ASME; 1992. p. 26976.
[38] Smith RP, Eppinger SD. Identifying controlling features of
engineering design iteration. Manage Sci 1997;43(3).
[39] Westley FR. Middle managers and strategy: microdynamics of
inclusion. Strategic Manage J 1990:33751.
[40] OReilly C, Chatman J. Organizational commitment and psycho-
logical attachment: the eects of compliance, identication, and
internalization on prosocial behavior. J Appl Psychol
1986;71(3):4929.
[41] Nonaka I, Takeuchi H. The knowledge-creating company how
japanese companies create the dynamics of innovation. New
York: Oxford University Press; 1995.
Project management turnover: causes and
eects on project performance
Stephen K. Parker, Martin Skitmore
*
School of Construction Management and Property, Queensland University of Technology, Gardens Point, Brisbane Qld. 4001, Australia
Received 18 December 2003; received in revised form 22 June 2004; accepted 22 October 2004
Abstract
Changes in management personnel variously termed displacement, succession or just turnover have been found by many to
have signicant negative eects on organisational performance. This paper provides the results of a web-based survey designed to
examine this in the project management context. The main ndings are that turnover occurs predominantly during the execution
phase of the project life cycle, with the main causes being related to career and personal development and dissatisfaction with
the organisational culture and project management role. The results also conrm that turnover disrupts and negatively aects
the performance of the project team, the project, and potentially negates the competitive advantage of organisations concerned.
Keywords: Management turnover; Management succession; Project life cycle; Performance measurement; Project management
1. Introduction
The importance of the project manager and continuity
of leadership is a recurring theme, both in practice and
research (e.g., Sotiriou and Wittmer [1]). For many suc-
cessful project teams, their invariable disbandonment on
project completion is a regrettable, if necessary, destabil-
ising factor (Heizer and Render [2]). Similarly, during the
project life cycle, the team composition often changes to
match the tasks to be implemented further decreasing
stability as well as adding an additional layer of manage-
ment complexity (Kloppenborg and Petrick [3]).
It is not surprising, therefore, that lack of continuity
of individual managers is thought to be a primary factor
behind inadequate project execution (e.g., Abdel-Hamid
[4]; Rondinelli [5]), completions, system upgrades, mor-
ale, teamwork, workloads, group stress levels and a host
of other intangibles (Longenecker and Scazzero [6]).
Although the occurrence of sta turnover in general
has been an area of substantial research,
1
only a rela-
tively small number have addressed the topic of manage-
ment changes variously termed displacement,
succession or just turnover with most concentrating
on consequences rather than causes. The majority of
these have pointed to a signicant negative impact on
performance and protability (Birdir [7]).
However, as noted by Carroll [9] researchers have of-
ten ignored the organizational context of succession, the
timing of succession relative to the organizational life
cycle, and the type of transfer undertaken in control sur-
faces. Adams and Barndt [10], for example, have also
suggested that the idea of specically choosing a project
manager to see the project completely through its life cy-
cle may need to be discarded in favour of selecting at
each phase point, a new project manager best suited to
the anticipated project environment.
doi:10.1016/j.ijproman.2004.10.004
*
Corresponding author. Tel.: +07 3864 2234; fax: +61 7 3864 1170.
E-mail address: rm.skitmore@qut.edu.au (M. Skitmore).
1
1500 studies of turnover have been conducted in the last century
(Bluedorn [8])
PROJECT
MANAGEMENT
This paper describes a web-based survey designed to
investigate this further. In particular, the goals were to:
nd the reasons for project management turnover;
examine the extent to which project management
turnover is associated with a particular phase of the
project life cycle; and
investigate the eects of project management turn-
over on project performance.
2. Management turnover
2.1. Generally
Numerous studies, research and theoretical develop-
ment have been conducted on the turnover of sta gen-
erally. The causes of turnover have been associated with
demographics, such as age, marital status and tenure
(Arnold and Feldman [11]) and include:
poor commitment and performance (Harrison et al.
[12])
inadequate pay, benets, working conditions, super-
vision, t with co-workers or company culture, deni-
tion and responsibilities (Woods and Macaulay [13])
alternative job possibilities (Mobley et al. [14])
Many believe employee turnover to have signicant
negative eects on the organisations involved (e.g.,
Herzberg et al. [15]). Others (e.g., Dalton et al. [16]) ar-
gue that some kinds and levels of turnover are actually
benecial or functional for organisations, as they help
prevent stagnation, maintain organisational develop-
ment and provide career opportunities (Ball [17]).
The turnover of management sta on the other hand,
has been attributed generally to:
dissatisfaction with the immediate supervisor (Tulacz
[18]);
organisational size (Harrison et al. [12]);
unpleasant experiences in management (Campion
and Mitchell [19]); and
a lack of resources/sta (Longenecker and Scazzero
[6]).
with the main causes of managerial departures in the
construction industry being due to (Tulacz [18]):
issues with the immediate supervisor;
promotion;
increased compensation;
stock ownership;
job security;
incompetent leadership;
job autonomy;
broken promises;
ethics and integrity; and
unpaid bonuses.
The eects of management turnover have been the
subject of several empirical studies, the overwhelming
majority of which have been conducted on sports teams
in US football, baseball and basketball, and UK soccer.
These have led to the development of three main as
opposing theories termed common-sense explanation,
vicious cycle and ritual scapegoating concerning the
relationship between turnover and organisational
performance:
Common-sense explanation. The common sense, or
one-way causality, theory, attributes a signicant
portion of responsibility for team performance to
the actions of the manager (Grusky [20]). Implicit in
this explanation is the assumption that team perfor-
mance will improve under a new manager (Fabianic
[21]) as, far from creating conict and tension, the
replacement of managers reduces team conict, which
indirectly improves performance.
Vicious-cycle theory. Vicious-cycle, or two-way cau-
sality, theory holds that manager departure is more
likely to occur in poorly performing teams and that
once the new manager takes over, team performance
deteriorates further (Grusky [22]).
Ritual scapegoating theory. Research by Gamson and
Scotch [23], although nding some support for the
previous two theories, found managerial turnover
mainly to have little impact upon team performance.
As Fizel and DItri [24] and others (e.g., Brown [25])
point out, this implies that the eect of rm perfor-
mance on turnover recurring theme in most turn-
over studies is typically a consequence of the
belief that organisational performance is attributable
to the leader or as a result of scapegoating.
Of course, managing a sports team is not necessarily
the same as managing a project and, although the re-
search previously undertaken appears to be comparable,
as the teams are similar in size, goals, internal structures
and environment to that of work groups or teams, it is
obvious that that further study is needed in other elds
of activity before any generalisations can be made. In
fact, as Bartol et al. [26] observe, the magnitude of the
managerial turnover problem and the disruptions that
are caused, strongly indicates the need for more con-
centrated research in this area.
2.2. Project management
From a project management perspective, six major
themes are of potential relevance, comprising:
206 S.K. Parker, M. Skitmore / International Journal of Project Management 23 (2005) 205214
1. Timing of departure. This concerns the project man-
agers state of well-being during the project life cycle
(e.g., Sommerville and Langford [27]; Gallstedt [28]).
2. Internal transfer. This involves the transfer of author-
ity across similar control structures, such as when one
direct manager replaces another or leaves one job for
another within the same organisation (e.g., Campion
and Michael [19]).
3. Gender dierences. Top-performing females have
been found to turnover rates that are 2.5 times those
of their male counterparts (Schwartz [29]).
4. Project eects. The consequences of project manage-
ment turnover can have a signicant impact on pro-
jects (e.g., Abdel-Hamid [4]).
5. Loss of organisational knowledge. There may be loss
of portions of the organisations memory once an
individual has left (e.g., Carley [30])
6. Arrival eects. The recruitment and selection of pro-
ject managers have been long-running problems
(e.g., Kerzner [31])
3. The survey
3.1. Data collection
The main questions of the survey questionnaire iden-
tied from the literature review were categorised into
ve sections:
1. General.
2. Impact of Project Management Turnover.
3. Intention to Turnover.
4. Retention.
5. Demographic Information.
Data was then collected by internet from a group of
project managers currently employed in each of the ma-
jor business units of an international aerospace com-
pany the primary utilisation of projects within the
company being to design, develop, manufacture, modify
and support through life of type, products associated
with the aviation and aerospace industry.
2
This in-
cluded nite projects whose objectives where the integra-
tion of weapons and weapon systems, the modication,
upgrade and support of military aircraft, the develop-
ment and installation of command, control and commu-
nication systems and the manufacture of both
commercial and military aircraft and associated compo-
nents. The projects themselves ranged from those of a
short-term duration (12 years), medium duration (35
years) and those with longer durations (510 years),
ranging in size from as little as 20 people to projects that
were made up of many hundreds.
The questionnaire was open for completion from 30
September 2003, when the request to participate in the
survey was released to the sample frame of project man-
agers (n = 150), through to the 10 October 2003, the
closing date for all submissions. A total of 67 web-based
surveys were completed, comprising 51 USA and 16
Australian nationals, equating to a 45% response rate.
3
The results follow. The individual nationality groupings
are not reported as no statistically signicant dierences
were found.
3.2. Results
3.2.1. The respondents
The majority (68%) of respondents are between 35
and 50 years of age, with 27% and 4% over 50 and below
35, respectively suggesting that the organisation is con-
servative in nature, requiring sta to be experienced in
the key elements of project management prior to attain-
ing the role of a project manager. 43% of respondents
hold a Master Degree, with a similar number holding
an undergraduate Degree. This indicates the necessity
for organisations project managers to be professionally
qualied, with an emphasis not only on undergraduate
qualications, but also on postgraduate qualications.
Respondents have worked an average of 17.5 years
per person for the company suggesting that they gen-
erally feel secure with the organisation, aligned with its
values and content to work there. 59% of respondents
have been employed as project managers for less than
5 years, with 33% between 5 and 10 years and 8% more
than 10 years indicating that the majority of
respondents have worked in other roles within the orga-
nisation, possibly in a project management and non-
project management discipline, prior to assuming the
role of project manager.
22% of respondents have only managed one project
during their tenure at the company, with 61% having
managed up to 3 projects and 82% having managed
no more than 5 projects. The majority of respondents
(62%) have not managed a project from start to nish,
with 53% having not managed the closeout and nalisa-
tion phase and 32% having not managed the concept
phase.
Not surprisingly, the older respondents have man-
aged more projects than the younger ones, with those
older than 50 having managed more projects than those
2
A four phased project life cycle was used as described by Verma
and Wideman [32] made up of the following phases; concept,
development/planning, execution and nalisation.
3
In general, questionnaires are criticized for having a low response
rate, Kartam et al. [33], especially in the construction industry, where
in the heat of managing projects, there is little time to respond to
survey questions. A rate of 45% is considered reective of a sampled
population for postal/e-mailed surveys (Fellows and Liu [34]).
S.K. Parker, M. Skitmore / International Journal of Project Management 23 (2005) 205214 207
between the ages of 35 and 50, who in turn have man-
aged more projects than those younger than 35. This
pattern is similar for those with dierent levels of expe-
rience, except that those respondents with less than 10
years project management experience have, on average,
managed more projects than those with more than 10,
and less than 5 years experience.
3.2.2. Importance of project managers
The respondents perceptions of the importance of
project managers were measured using a ve-point Lik-
ert scale with intervals ranging from 1 = strongly dis-
agree to 2 = disagree, 3 = neither agree nor disagree,
4 = agree, concluding with 5 = strongly agree. The re-
sponses were treated as scores and averaged for compar-
ative purposes. An overwhelming majority of
respondents (97%, mean 4.76) agree or strongly agree
that project managers are critical to project success
and that the leadership skills of project managers are
more important than management skills (76%, mean
3.97). The majority of respondents (94%, mean 4.61)
also agree or strongly agree that project managers can
signicantly aect the performance of project team
members. Of course, these results are not surprising in
view of all the respondents being project managers as
several previous studies have shown that people usually
rate their own professions contribution relatively highly
(e.g., Higgin and Jessop [35]; Faulkner and Day [36])
3.2.3. Insider succession and the orientation phase
36% of respondents agree it is better to promote an
individual from within the project team to the role of
project manager after the turnover event; 12% disagree,
with 46% neutral. 64% of respondents disagree with the
statement that new project managers are less committed
to resolving problems inherited from the departed man-
ager (mean 2.44).
31.5% of the respondents disagreed, 38.5% agreed
and 30% neither agreed nor disagreed (mean 3.03, stan-
dard deviation 1.1) that the project manager should
manage each phase of the project life cycle on the same
project; thus manage the project from conception to
closeout/nalisation.
3.2.4. Thoughts about moving
Most (71%) respondents had considered leaving their
current role to move to another project management
role within the company during the last 12 month.
67% of these have less than 5 years project management
experience, while 10% have 510 years experience and
the remaining 23% have more than 10 years experience
suggesting a slight increase in desire to move with
experience.
55% had considered moving into a non-project man-
agement role within the company within the last 12
months. The variance between respondents attitudes
was similar to that above in that 49% of managers with
less than 5 years experience, 64% of managers with less
than 10 years and 67% of those with greater then 10
years had considered such a move.
39% of participants have considered leaving the com-
pany in the last 12 months, with 61% indicating they
have not. 59% of respondents with less than 10 years
of experience as project managers have considered the
move, compared to 28% with less than 5 years experi-
ence and 33% with more than 10 years experience. This
again suggests that the project managers in the 3550
age category (64%) to be the most likely to turnover.
3.2.5. Causes of turnover
Using a ve-point Likert scale with intervals ranging
from 1 = not at all to 2 = to a small extent, 3 = to a
moderate extent, 4 = to a great extent, concluding with
5 = to a very great extent, respondents attitudes were
measured to determine the degree to which 13 individual
factors would cause them to leave their current role. The
respondents agree to some extent with all of the factors
presented (average mean 3.47, 0.9 standard deviation).
The results (Table 1) suggest that there are two main
groups of factors involved: (1) those related to career
motives and personal development, and (2), those re-
lated to dissatisfaction with the organisational culture
and job design. The rst group of factors consists of:
promotion, better career opportunity; and profes-
sional stagnation and lack of development and lack
of advancement opportunities. The highest rating factor
in group two is the issue of ethics and integrity employed
both within the organisation and project team. Other
factors in this group include a lack of teamwork and
cooperation, politics and inghting, feeling unappreci-
ated and unrealistic performance expectations.
The lowest score (mean 2.72), was related to whether
or not a poorly performing, or failing, project would
cause them to leave their role, although 40.3% still rates
this as to a moderate extent.
Only 18% of respondents provided additional rea-
sons, including: lack of support and/or commitment
from senior leadership/management, inability to get
along with the customer or for the customer to keep
the project funded, family circumstances, and current
policies and procedures that limited creativity and
exibility.
3.2.6. Causes of non-turnover
Respondents were requested to indicate the extent to
which 11 factors (Table 2) would cause them to stay in
their current role. These factors used the same Likert
scale as before, with the results then averaged and
ranked as before. The average mean of 3.95 (0.8 stan-
dard deviation) suggests that respondents agree, to a
large extent, that the factors presented would cause the
respondent to stay in their current role.
The two most important factors relate to organisa-
tional culture and job design challenging work and
the ethics and integrity inherent in the organisation
and its employees. Career motives are again also a
strong contributor, with development, growth and
advancement opportunities being very important. The
least signicant factor is job security, although this
would still to a moderate extent negate the occurrence
of the turnover event.
The results for project managers with less than 5 and
10 years experience, and for those respondents who are
less than 35 years old or between 35 and 50 years old,
are similar to the previous section with regard to job
security. Those over the age of 50 (27%), however, have
a lower mean of 2.61. Additionally, respondents with
more than 10 years experience as a project manager
(8%) have a signicantly lower mean of 1.83 (standard
deviation 1.2), indicting job security is a factor that
would only slightly minimise turnover for these particu-
lar groups of project managers with 23.1 and 27.3 years
tenure in the organisation respectively.
3.2.7. Eect of turnover on overall performance
9% agree, 34% were neutral and 54% disagree (3%
dont know) that project management turnover im-
proves project performance, with 49% agreeing, 21%
strongly agreeing and 22% undecided (mean 3.89, 0.8
standard deviation) that turnover disrupted project per-
formance. The majority of respondents (85%) disagree
(mean 1.74, 1.0 standard deviation) that project man-
agement turnover has no eect on project performance.
15% disagreed, 39% were neutral, 39% agreed (7%
dont know) (mean 3.27, 0.9 standard deviation) that
transferring from one project to another negatively im-
pacted project productivity and performance.
The majority of the open-ended comments concern-
ing this issue centred on the fact that while most believed
turnover has a negative impact on the performance of
the project team and on the project as a whole, it was
not always negative. For instance, if a project is being
led by a manager who was ineective, or one who was
not performing, then the turnover event would most
likely result in increased performance and in this case,
Table 1
Factors contributing to project management turnover
Factor Responses
1 2 3 4 5 Dont know Mean
n, % n, % n, % n, % n, %
Ethics/integrity 1 2 7 11 45 1 4.47
1.5% 3.0% 10.4% 16.4% 67.2% 1.5%
Promotion 1 0 6 22 38 0 4.43
1.5% 9.0% 32.8% 56.7%
Better career opportunity 0 2 9 34 22 0 4.13
3.0% 13.4% 50.8% 32.8%
Professional stagnation/lack of development 1 2 12 36 16 0 3.96
1.5% 3.0% 17.9% 53.7% 23.9%
Lack of advancement opportunities 3 4 12 32 16 0 3.81
4.5% 6.0% 17.9% 47.7% 23.9%
Lack of teamwork and cooperation 0 9 13 33 12 0 3.72
13.4% 19.4% 49.3% 17.9%
Politics and inghting 1 7 20 20 18 1 3.71
1.5% 10.4% 29.9% 29.9% 26.8% 1.5%
Feeling unappreciated 2 8 16 23 18 0 3.70
3.0% 11.9% 23.9% 34.3% 26.9%
Unrealistic performance expectations 1 9 19 24 14 0 3.61
1.5% 13.4% 28.3% 35.8% 20.9%
Ineective manager 5 10 11 22 18 1 3.58
7.5% 14.9% 16.4% 32.8% 26.9% 1.5%
Lack of resources sta 6 14 15 22 10 0 3.24
9.0% 20.9% 22.4% 32.8% 14.9%
Inability to take time o/get away from work 6 10 25 15 11 0 3.22
9.0% 14.9% 37.3% 22.4% 16.4%
Poor performing/failing project 5 23 27 10 2 0 2.72
7.5% 34.3% 40.3% 14.9% 3.0%
project management turnover is positive. Other com-
ments highlighted that respondents felt, from previous
experience, that management turnover tends to occur
towards the end of a project. The result of this turnover
is to signicantly increase the closeout schedule and
associated cost of the project.
3.2.8. Eects on individual factors
This section examined participants perceptions on the
extent to which turnover contributes to nine factors
(Table 3). A ve-point Likert scale was used intervals
ranged from 1 = not at all to 2 = to a small extent,
3 = to a moderate extent, 4 = to a great extent, con-
cluding with 5 = to a very great extent. The responses
to each question were again averaged and ranked for
importance.
As Table 3 shows, respondents felt the turnover of
the incumbent project manager contributed to all of
the identied factors. The factors all had negative im-
pacts to both the project team and project performance,
with the majority of responses falling into the to a mod-
erate extent and to a great extent categories (3.03 aver-
age mean, 0.9 standard deviation 0.9). The main factors
are communication breakdown, loss of focus and direc-
tion and increased workload for others. These are fol-
lowed by three, closely scored factors, comprising
additional turnover amongst sta, morale and motiva-
tional problems with the project team and diculty in
achieving performance goals. Factors such as the loss
of teamwork and cooperation, as well as chaos/disorga-
nisation were rated the lowest.
4. Discussion
4.1. Causes of turnover
The factors in our rst group of causes support
the literature in demonstrating that project managers
do leave their roles due to dissatisfaction with
their immediate supervisors, career prospects and lack
of advancement opportunities. Clearly, the continued
development of project managers appears to be para-
mount to job satisfaction and the minimisation of
unwanted turnover regardless of the experience levels,
or the age of project managers. A number of practical
activities aimed at enhancing management development
have been suggested that should be benecial, including
formal training, eective performance appraisal and re-
view, cross training, special assignments, formal career
Table 2
Factors minimising project management turnover
Factor Responses
n, % n, % n, % n, % n, %
Challenging work 0 0 4 38 25 0 4.31
6.0% 56.7% 37.3%
Ethics/integrity 2 1 7 26 29 2 4.22
3.0% 1.5% 10.4% 38.8% 43.3% 3.0%
Development and growth opportunities 0 2 8 33 24 0 4.18
3.0% 12.0% 49.2% 35.8%
Advancement opportunities 2 0 9 35 21 0 4.09
3.0% 13.4% 52.2% 31.4%
Loyalty 0 3 9 36 19 0 4.06
4.5% 13.4% 53.7% 28.4%
Being part of a team 0 3 9 40 15 0 4.00
4.5% 13.43% 59.7% 22.38%
Having organisational inuence/authority 1 5 5 41 15 0 3.96
1.5% 7.5% 7.5% 61.1% 22.4%
Eective manager 0 4 11 36 15 1 3.94
6.0% 16.4% 53.7% 22.4% 1.5%
Salary benets 1 5 13 30 18 0 3.88
1.5% 7.5% 19.4% 44.7% 26.9%
Recognition 4 4 19 25 15 0 3.64
6.0% 6.0% 28.3% 37.3% 22.4%
Job security 6 13 18 21 9 0 3.21
9.0% 19.4% 26.9% 31.3% 13.4%
development planning, mentoring, and on-the-job
coaching (Longenecker and Scazzero [6]). At the theo-
retical level, these results also support the argument that
people today need to satisfy their needs for esteem and
achievement, rather than a sense of belonging (Turner
[37]).
The factors in the second group seem to be more di-
rected at the organisational culture in which the work is
being performed. These ndings also support previous
research, except that the ranking and level of agreement
diers. In particular, the issue of ethics and integrity
has been rated much lower in previous studies. This
may be because the causes intrinsic to this group have
dierent levels of importance in the uncertain and com-
plex environment that project managers operate in,
when compared to their other managerial counterparts.
The proportionately high number of project manag-
ers who indicated they had, over a 12-month period,
seriously considered leaving their current roles also en-
forces the legitimacy of the factors in both groups.
While the gures are surprising, even more startling is
the nding that over half of the respondents (55%) indi-
cated they had considered moving into a dierent disci-
pline all together. In fact, those managers with between
5 and 10 years experience, and predominantly within the
3550 year old age grouping, were found to be the most
likely to turnover and the most at risk. Although these
ndings may not directly transfer into actual turnover,
previous researchers such as Lee and Mowday [38] have
reported that a willingness or intention to leave the cur-
rent role may indeed lead to actual turnover; this has
been found to be detrimental to project performance.
4.2. Association with the project life cycle
As reported, over half of the respondents (58%) have
not managed the closeout and nalisation phase. This
is followed by the concept phase (35%).
4
This suggests
that project management turnover occurs primarily in
the execution phase of projects with a signicant num-
ber of respondents moving into new projects prior to
nalisation of current projects. As it does not appear
that previous research has been conducted to determine
the phase where project management turnover primarily
occurs, these ndings are new. When moving into the
new project, it appears likely the majority of managers
are also skipping the concept phase, which normally oc-
curs prior to contract award, and directly entering the
design/planning or execution phases of the project lifecy-
cle. In addition, research conducted by Briner et al [39]
highlighted the theory that many project managers expe-
rienced complacency and diminishing enthusiasm in the
execution phase. It is suggested that these issues may
also contribute to the turnover event and the determina-
tion of the re-entry point where project managers join a
new project.
Table 3
Project management turnover contributes to a number of undesirable factors
Factor Responses
n, % n, % n, % n, % n, %
Communication breakdown 2 10 23 24 7 1 3.36
3.0% 14.9% 34.3% 35.8% 10.5% 1.5%
Loss of focus and direction 6 9 22 19 10 1 3.27
9.0% 13.4% 32.8% 28.4% 14.9% 1.5%
Increased workload for others 3 13 24 23 2 2 3.12
4.5% 19.4% 35.8% 34.3% 3.0% 3.0%
Morale/motivational problems with project team and sta 2 17 23 21 2 2 3.06
3.0% 25.4% 34.3% 31.3% 3.0% 3.0%
Additional turnover among sta 2 17 23 21 2 2 3.06
3.0% 25.4% 34.3% 31.3% 3.0% 3.0%
Diculty in achieving performance goals 3 13 28 22 0 1 3.05
4.5% 19.4% 41.8% 32.8% 1.5%
Increase in unresolved problems 7 15 25 17 1 2 2.85
10.4% 22.4% 37.3% 25.4% 1.5% 3.0%
Chaos/disorganisation 9 17 20 15 3 3 2.78
13.4% 25.4% 29.8% 22.4% 4.5% 4.5%
Loss of teamwork and cooperation 7 16 30 10 2 2 2.75
10.4% 23.9% 44.8% 14.9% 3.0% 3.0%
4
Interestingly, previous research (Gallstedt [28]) has shown these
two phases to be most associated with project managers stress and
pressure.
Furthermore, as each phase can be regarded as a pro-
ject, or sub-project, in its own right, and managed
accordingly (Stretton [40]) with dierent skills and task
knowledge required of the project manager, it is con-
cluded that it is advantageous for project managers to
have experience in each phase. An alternative, of course,
is Adams and Barndts [10] suggestion that individual
project managers should not manage a project through-
out its entire lifecycle, although the results obtained
from the project managers on this aspect were inconclu-
sive. However, for projects with short durations it may
be advantageous for project managers to lead and man-
age their individual projects from concept to closeout to
minimise the eects on performance.
4.3. Eect on project performance
The respondents generally disagree with the com-
mon-sense explanation, with over half of the population
(54%) disagreeing that project management turnover im-
proves project performance. In addition, approximately
one third of the respondents (34%) neither agrees nor
disagrees with the theory. This large percentage of neu-
tral responses may be due to the subjective nature of the
question, in that, if the project manager in question was
an ineective leader, then it is quite likely the turnover
event would improve performance. However, this posi-
tive outcome is seen as the exception to the rule. The
ndings clearly demonstrate that for the vast majority
of occurrences, project management turnover will nega-
tively aect the project team members. This leads to per-
formance issues, causing disruption and leading to the
project objectives being compromised for a period.
The results suggest that succession planning, in the
form of transferring/promoting someone from within
the project team to the project management role, is the
preferred approach to minimise the eects of the turn-
over event and orientation phase. Conversely, authors
such as Chapman [41] have argued that even if the
incoming team member has the luxury of a handover
period from the departing manager, the project informa-
tion is so voluminous and complex it cannot be passed
in totality from one individual. Irrespective, it is sug-
gested that this has the potential to mitigate a number
of the negative impacts experienced by the project team
and should be pursued.
4.4. Other ndings
Previous research determined that the main factor in
retention and continuity of employment was challeng-
ing work, followed by loyalty, having organisation
inuence and authority, advancement opportunities
and job security (Ghiselli et al. [42]; Longenecker and
Scazzero [6]; Scott [43]), and our results support this
with the addition of ethics and integrity. With the vast
majority of aviation and aerospace projects in the Amer-
ican and Australia accomplished in a cross-functional,
matrix setting, where project managers only have project
authority over the project team, the desire for organisa-
tional inuence and authority appears to be a key factor
and one that Sotiriou and Wittmer [1] dened as the
right to suggest to others what needs to be done and
when it needs to be done.
5. Conclusions
This paper has synthesised the results obtained from
a survey of project managers employed by an interna-
tional aircraft organisation, detailing and discussing
the causes of project management turnover, the phase
in which it primarily transpires, and the negative conse-
quences associated with its occurrence. In summary, the
results indicate that:
1. Project managers believe they are critical to project
success and have a signicant impact on the perfor-
mance of their project teams.
2. A considerable number of project managers consider
leaving their current roles and moving into other pro-
ject management roles, as well as non-project man-
agement roles within organisations.
3. Project management turnover occurs primarily in the
execution phase of the project lifecycle and for the
reason that, it may be associated with increasing risk,
cost and the likelihood of project failure.
4. The primary factors that cause project management
turnover can be categorised into two groups, these
being: career motives and personal development, as
well as dissatisfaction with organisational culture
and the project management role.
5. Project management turnover directly aects the pro-
ject team, negatively disrupting project performance
and potentially aecting the protability of the
organisation.
From a practical point of view, it is obvious from 5.
that some degree of action should be benecial in avoid-
ing its worst eects in project management. The more
obvious of these are:
Promote eective project management development
activities that increase and enhance current skills,
such as in formal training, eective performance
appraisal and review, cross training, special assign-
ments, formal career development planning, mentor-
ing, and on-the-job coaching.
When developing project managers, employ a rota-
tion process to ensure that project managers gain
experience in all life cycle phases.
Employ a great use of succession planning.
The results also have broad implications for future re-
search in the eld of management turnover in general. In
particular,
The ndings contradict and disagree with a number
of previous theories on the cause of management
turnover and theories formulated from the investiga-
tion and analysis of international sports teams. For
example, respondents disagreed with the common-
sense explanation, with over half disagreeing that
project management turnover improves project per-
formance. Additional research is needed to determine
the length of disruption to project performance, and
to investigate the eects of project management turn-
over from the project team member perspective.
The majority of studies have identied the factors
that cause the turnover event in isolation, instead of
taking a holistic view to ascertain if the identied
factors and nurturing conditions are interactive from
a systems perspective. Further research with this ori-
entation is therefore likely to be benecial for both
practice and theory.
Future studies may want to include not only insider
turnover, but also an investigation into the factors
and reasons that lead to personnel who voluntarily
or involuntarily leave the organisation in terms of
dysfunctional and functional turnover.
Additional opportunity exists for further research
regarding project management turnover of other
organisations, not only in the aviation and aerospace
industry, but also in a wider range of industries
including construction, defence, engineering, biotech-
nology and pharmaceutical.
References
[1] Sotiriou D, Wittmer D. Inuence methods of project managers:
perceptions of team members and project managers. Project
Manage J 2001;32(3):1220.
[2] Heizer J, Render B. Production and operations management:
strategic and tactical decisions. fourth ed.. New Jersey: Prentice-
Hall International; 1996.
[3] Kloppenborg TJ, Petrick JA. Leadership in project life cycle
and team character development. Project Manage J
1999;30(2):813.
[4] Abdel-Hamid TK. Investigating the impacts of managerial
turnover/succession on software project performance. J Manage
Inform Sys 1992;9(2):12744.
[5] Rondinelli R. Why development projects fail: problems of project
management in developing countries. In: Adams JR, Kirchof NS,
editors. Decadeof Project Management, Selected Readings from
the Project Management Quarterly, 1970 through 1980. p.
295300.
[6] Longenecker CO, Scazzero JA. The turnover and retention of IT
managers in rapidly changing organizations. Infor Sys Manage
2003;19(4):5863.
[7] Birdir K. General manager turnover and root causes. Int J
Contemporary Hospitality Manage 2002;14(1):437.
[8] Bluedorn in Harrison JR, Torres DL, Kukalis S. The changing of
the guard: turnover and structural change in the top-management
positions. Admine Sci Quart 1988;33(2):21132.
[9] Carroll GR. Dynamics of publisher succession in newspaper
organizations. Admin Sci Quart 1984;29(1):93113.
[10] Adams JR, Barndt SE. Organizational life cycle implications for
major projects. In: Adams JR, Kirchof NS, editors. Decade of
Project Management, Selected Readings from the Project Man-
agement Quarterly, 1970 through 1980. p. 12936.
[11] Arnold HJ, Feldman DC. A multivariate analysis of the
determinants of job turnover. J Appl Psychol 1982;67(3):
35060.
[12] Harrison JR, Torres DL, Kukalis S. The changing of the guard:
turnover and structural change in the top-management positions.
Admin Sci Quart 1988;33(2):21132.
[13] Woods RH, Macaulay JF. Rx for turnover: retention programs
that work. The Cornell Hotel Restaurant Admin Quart
1989;30(1):7990.
[14] Mobley WH, Grieth RW, Hand HH, Meglino BM. Review and
conceptual analysis of the employee turnover process. Psychol
Bull 1979;86(3):493522.
[15] Hertzberg et al in Williams CR. Reward contingency, unemploy-
ment, and functional turnover. Human Resour Manage Rev
1999;9(4):54976.
[16] Dalton et al in Williams CR. Reward contingency, unemploy-
ment, and functional turnover. Human Resour Manage Rev
1999;9(4):54976.
[17] Ball in Scott J. Management retention in the NHS. J Manage Med
2002; 16(4):292302.
[18] Tulacz GJ. Sta turnover plagues contractors despite remedies.
Eng News Record NY 2001;247(23):145.
[19] Campion MA, Mitchell MM. Management turnover: Experiential
dierences between former and current managers. Personnel
Psychol 1986;39(1):5769.
[20] Grusky O. Managerial succession and organization eectiveness.
Am J Sociol 1963;69(1):2131.
[21] Fabianic D. Managerial change and organizational eectiveness
in major league baseball: Findings for the eighties. J Sport Behav
1994;17(3):13547.
[22] Grusky in Fizel JL, DItri M. Managerial eciency, managerial
succession and organizational performance. Manage Decis Econ
1997; 18(43):295308.
[23] Gamson WA, Cotch WA. Scapegoating in baseball. Am J Sociol
1964;70:6972.
[24] Fizel JL, DItri M. Managerial eciency, managerial succession
and organizational performance. Manage Decis Econ
1997;18(43):295308.
[25] Brown M. Administrative succession and organizational perfor-
mance: The succession eect. Admin Sci Quart 1982;27:116.
[26] Bartol KM, Martin D, Tein MH, Matthews GW. Management: a
pacic rim focus. 2nd ed.. Sydney: McGraw-Hill; 1999.
[27] Sommerville J, Langford V. Multivariate inuences on the people
side of projects: stress and conict. Int J Project Manage
1994;12(4):23443.
[28] Gallstedt M. Working conditions in projects: Perceptions of stress
and motivation among project team members and project
managers. Int J Project Manage 2003;21(6):44955.
[29] Schwartz in Stroh LK, Brett JM, Reilly AH. Family structure,
glass ceiling, and traditional explanations for the dierential rate
of turnover of female and male managers. J Vocat Behav
1996;49(1):99118.
[30] Carley in Akgu n AE, Lynn GS. Antecedents and consequences of
team stability on new product development perform iance, J Eng
Technol Manag 2002; 19:26386.
[31] Kerzner in Hauschildt J, Keim G, Medcof JW. Realistic Criteria
for Project Manager Selection and Development. Project Manag J
2000; 31(3):2332.
[32] Verma VK, Wideman RM. Project manager to project leader?
And the rocky road between. In: Proceedings of the annual
seminar symposium Project management institute Leadership
in a world of change; 1994:62733.
[33] Kartam N, A-Darhani TG, Al-Bahar JF. Professional
Project Management Practices in Kuwait: Issues, dicul-
ties, and recommendations. Int J Project Manage 2000;18:
28196.
[34] Fellows R, Liu A. Research methods for construction. Blackwell
Science; 1997.
[35] Higgin G, Jessop N. Communications in the building industry.
2nd ed.. London: Tavistock Publications; 2001.
[36] Faulkner AC, Day AK. Images of Status and Performance in
Building Team Occupations. Constr Manage Econ 1986;4(3):
245260.
[37] Turner JR. The handbook of project-based management. 2nd
ed.. London: McGraw Hill; 1999.
[38] Lee TW, Mowday RT. Voluntarily leaving an organization: An
empirical investigation of Steers and Mowdays model of turnover.
Acad Manage J 1987;30(4):72143.
[39] Briner W, Geddes M, Hastings C. Project leadership. Alder-
shot: Gower Publishing Company; 1994. p.133.
[40] Stretton A. A basic generic project life cycle. In: Proceedings of the
Australianinstitute of project management 1997national conference
project managers: linking people and technology; 1997:40517.
[41] Chapman RJ. The role of system dynamics in understanding the
impact of changes to key project personnel on design production
within construction projects. Int J Project Manage
1998;16(4):23547.
[42] Ghiselli RF, La Lopa M, Bai B. Job satisfaction, life satisfaction,
and turnover intent among food-service managers. The Cornell
Hotel Restaurant Admin Quart 2001;42(2):2837.
[43] Scott J. Management retention in the NHS. J Manage Med
2002;16(4):292302.
A tool for managing projects: an analytic
parameterization of the S-curve
Denis F. Cio
*
Project Management Program, The George Washington University, Monroe Hall 302, 2115 G Street NW, Washington, DC 20052
Received 27 January 2004; received in revised form 30 March 2004; accepted 5 August 2004
Abstract
The solution to a dierential equation used frequently in ecology is found to reproduce the well-known S-curve seen in various
aspects of project management. The solution is modied in a minor way to t project management boundary conditions. An excel-
lent t of this theoretical curve to two samples of project cost data shows the utility of the formula. Numerical approximations valid
under typical project conditions are utilized to produce an analytic expression that can easily generate classic project management
evolution curves under a variety of conditions. The curves are normalized to two basic parameters: the total of the relevant quantity
(e.g., project costs) and the duration of the project. The user can choose the steepness of the climb and the point in time at which half
the total has been accumulated.
Keywords: Managing projects; Progress; Cost; Cash ow management; S-curve; Earned Value
1. Introduction: population growth in nature and cost
growth in projects
When displayed as a function of time, accumulated
eorts or costs of a project usually take a form described
as the S-curve. The guide to the Project Management
Body of Knowledge (the PMBOK
) denes the term

only by its appearance: Graphic display of cumulative
costs, labor hours, percentage of work, or other quanti-
ties, plotted against time. The name derives from the S-
like shape of curve (atter at the beginning and end,
steeper in the middle)... [1].
One earlier work in the project management litera-
ture showed how to construct a curve numerically by
building it from a normal distribution and forcing it
through the xed point of 5% progress at 10% of project
duration [2]. The curve was used to monitor progress in
a series of related Argentine projects.
By comparison, the more exible form presented here
should have uses in dierent contexts and in dierent
types of projects. The rst question that comes to mind
would be to discover whether project S-curves have
common characteristics within a single specic, narrow
industry (e.g., construction of houses) or type of indus-
try (construction as a whole), but dier as the type of
industry changes (to information systems, say). The
existence of known common characteristics would
greatly facilitate future industry-specic simulation and
planning.
As an example within a single project, an S-curve of
planned cash ow may assist risk analysis of project -
nances by showing altered spending rates needed to
achieve completion by dierent dates. Actual progress
measured against the planned S-curve can also inuence
scheduling adjustments. Also, project resources, both
human and material, show similar evolution, and the
curve can be applied to these data, too. Finally, earned
doi:10.1016/j.ijproman.2004.08.001
*
Tel.: +1 202 994 9533; fax: +1 202 994 2736.
E-mail address: denis.cio@gwu.edu.
PROJECT
MANAGEMENT
value calculations, where dierent S-curves are used to
represent actual costs, planned spending, and the budg-
eted cost of work performed, hold particular potential
(see, for example [3]). With this new formalism, produc-
ing curves to illustrate dierent possibilities for discus-
sion becomes a simple algebraic exercise, which should
encourage practitioners to take this perspective of pro-
jects more frequently.
In what follows, I will rst use the exact solution to
the dierential equation that generates an S-curve in
population studies to t project management data.
Then, approximations to the exact solution produce an
expression that can be used more easily, and this
approximate solution meets project management needs.
Most important, with this approximation the progres-
sion of the total cost of any project can be characterized
by two numbers: the slope of the rise in the S-curve and
the time at which half the total funds have been spent.
Eager readers may bypass the details of the equations
generation by proceeding immediately to the answer,
Eq. (7).
2. An equation for project management S-curves
Before proceeding with the mathematics, let us ask
why an S-shaped curve arises, whether in nature or in
project costs. The common characteristics of all systems
that demonstrate this behavior include slow growth fol-
lowed by rapid growth, which in turn is followed by
slow growth again to an asymptotic maximum hence
an S-shaped curve. Note that the Gompertz curve,
which is used in mortality calculations [4], does not show
the initial slow growth [5], and so it would not be useful
for modeling this eect.
In natural settings S-curves arise in closed systems
where the growth of a relatively small population is ini-
tially unlimited. At rst the population increases slowly
because the growth rate depends on the number of its
individual elements. As that number increases, the rate
increases and the population grows more swiftly. At
some point, however, limits are imposed, e.g., the food
or energy supply is nite, or in the case of an epidemic,
the number of potential new victims declines (essentially
everyone has already been infected). The population
then reaches a maximum.
Even the largest projects start with an initially small
number of tasks, but projects soon begin to tackle mul-
tiple activities simultaneously. These parallel, often
interconnected activities a key characteristic of pro-
jects that mandates project management increase the
spending greatly compared to the work at the beginning,
which by comparison is usually more limited and nar-
rowly focused (e.g., planning). But in almost all projects
(with the exception of some defense work!), a cap on the
total cost limits the budget and forces this large spend-
ing rate to decline. Because the tasks depend on each
other, most often in a startnish mode, they cannot
all end simultaneously. Activities dwindle to a small
number again as deliverables are completed, and eventu-
ally the entire project ends, with no further funds being
allocated. Thus, in projects the S-curve is driven by the
multiple interconnected activities that occur in the mid-
dle of a projects life.
Appendix A sketches the derivation of the logistics
dierential equation (Eq. (A.1)) in its common ecologi-
cal context. There three quantities determine the exact
progress of the solution (Eq. (A.3)) that models a popu-
lations growth in a given system: the birth rate, the
death rate, and the so-called carrying capacity of the
environment. Whether or not useful management ana-
logs of these quantities exist (and they may), the initial
boundary condition of the ecology equation (below)
does not further the cause of well-planned projects,
and its solution should be modied.
The growth of a living population, Y, from a low-lying
initial state begins with some pre-existing, ground-state
population, so at time zero (t = 0) the initial boundary
condition of the ecology equation requires a non-zero
quantity, Y = Y
0
. But in project management, the quan-
tity Y represents cost or eort (task duration multiplied
by resource intensity, e.g., [6]). A comprehensive plan
allows a well-managed projects costs to accrue only after
the project begins, and thus subtracting Y
0
from the
ecological solution changes the initial condition to a
more appropriate one: Y = 0 at t = 0.
One can write the new solution in terms of the same
parameters found in the ecological solution: the con-
stants d and Y
0
, and the maximum cost of the project,
Y
1
(to which the solution asymptotes at innite time).
But the ratio of Y
1
to Y
0
, which is generally much
greater than one, turns out to be a useful parameter.
Thus, we divide Y
1
by Y
0
and instead of using Y
0
explicitly, dene a constant c Y
1
/Y
0
; one can then
write a generic solution for the project management
S-curve as
Y Y
1
1 expdt
1 c expdt
: 1
At early times, i.e., at t 0, the growth is linear,
Y Y
0
dt. At late times, as t gets very large, Y Y
1
,
as desired. However, this equation will be more useful
for planning if the summed costs equal the total project
cost at the end of the project (t = t
1
), and not just at in-
nite time. The proper normalization in the solution that
follows (Eq. (7)) will ensure this equality, but for now we
need not worry about it; in most cases it will be approx-
imately correct as written (of order 10%, which will be
shown later, in Table 2).
These behaviors at the temporal extremes of the curve
replicate the verbal PMBOK
description noted previ-

ously, but does the equation truly work with project
216 D.F. Cio / International Journal of Project Management 23 (2005) 215222
data? That is, does the equation t well the accumulated
cost data of a project? Without overestimating the value
of a least-squares t to summed numbers, we should rst
ask if the standard (Pearsons) coecient of determina-
tion, R
2
, approaches one. For this test, instead of using
actual project data, which are often proprietary and dif-
cult to understand or duplicate, I took a set of numbers
from an example used in Version 8 of Scitors Project
Scheduler software, PS8 [7].
Fig. 1 shows daily cost data taken directly from the
intranet example in PS8. PS8 calculates the total cost
of each day for every day of the week; sometimes the
days cost is zero (e.g., weekends). Table 1 gives some
statistics of the raw data (i.e., not the accumulated
costs).
This example was chosen initially because of its avail-
ability, but the wide dispersion of the data and the
roughness of the resultant curve of the accumulated
costs make the test particularly appealing. The jagged
curve in Fig. 2 shows the accumulated cost data as a
function of time (in the unit days, which is irrelevant
to this discussion). The smooth, dashed curve is a
least-squares t
1
of the project management S-curve
equation, Eq. (1). An eyeball view of the graph alone
gives a powerful impression about the accuracy of the
t. The value of the coecient of determination,
R
2
= 0.996, conrms this impression (a low number
would cause concern). In this one example, then, Eq.
(1) represents well the S-curve seen frequently when
managing projects.
3. A form more useful for project management
The above form works well with project data, and
one can determine numerically the three parameters
Table 2
This table shows the calculated values of c and y
1
1 for ve
combinations of r
0.67
and b
1/2
. Also shown are the values of the
corresponding b
0
, which are the times at which y = 0.5 exactly, and
parenthetically, the b
1/2
parameters that one would need to use to
obtain the actual halfway points represented by the original numbers
used for b
1/2
r
0.67
c b
1/2
b
0
y
1
1 (b
1/2
)
0.5 5.389 0.500 0.454 0.119 0.5607
1 5.389 0.250 0.250 0.002 0.2505
1 52.60 0.500 0.496 0.018 0.5045
1 401.4 0.750 0.720 0.135 0.7889
2 2979. 0.500 0.500 0.0003 0.5000
0
500
1000
1500
2000
2500
0 50 100 150 200
C
o
s
t

(
D
o
l
l
a
r
s
)

P
e
r

D
a
y
Time(Days)
Fig. 1. The data points show the daily costs, in dollars, for a 207
calendar-day project. Many days (e.g., weekends) have zero cost. The
solid curve is the (arithmetically calculated) derivative of the exact
solution shown in Fig. 2, and so its units are also dollars per day.
Table 1
This table shows the statistics of the sample data set taken from PS8
Statistics of sample data
Number of points 207
Minimum 0
Maximum $2456
Sum $92,464
Mean $447
Standard deviation $590
0
2 10
4
4 10
4
6 10
4
8 10
4
1 10
5
0 50 100 150 200
S
u
m
m
e
d

C
o
s
t
s

(
D
o
l
l
a
r
s
)
Temporal Units (Days)
Fig. 2. The exact solution, Y (Eq. (1), dashed line), t to the sample
data of Fig. 1 (jagged solid line). The four t parameters here are:
Y
1
= 89,437; d = 0.03392; c = 16.88 and R
2
= 0.99638.
1
Via the general curve-t function of Kaleidagraph software,
Version 3.52.
D.F. Cio / International Journal of Project Management 23 (2005) 215222 217
necessary for a good t (d, Y
1
, and c). However, what if
the detailed planning that makes a t possible has not
yet occurred? How can we take advantage of this solu-
tion to create a rst guess of what the spending prole
might look like?
Again three quantities will parameterize the solu-
tion, but using the equation in the absence of detailed
data suggests a slightly dierent set of constants. First
one uses the nal cost of the project, now written
explicitly as Y
1
. The other two parameters are the total
duration of the project, t
1
, and the time at which the
project has used half its total funds, t
1=2
. With esti-
mates of these three numbers, at the start of any pro-
ject a manager can write an S-curve equation that can
indicate how labor or funds might be specied
throughout the project.
First we calculate this new time, t
1=2
. Letting Y = 0.5
Y
1
yields
t
1=2

1
d
ln c 2
Y
1
Y
1

ln 2
Y
1
Y
1
1

1
d
lnc 2: 2
In the second line of the above equation, we take advan-
tage of the near equality that occurs in many cases,
Y
1
Y
1
. Retaining the distinction here between Y
1
and Y
1
would not justify the resulting algebraic com-
plexity, and the dierence introduced can be corrected
easily with a simple numerical solution that converges
quickly (see Appendix B).
We want to express this time in terms of the total
duration of the project, t
1
, and so now dene b as the
ratio
b
t
t
1
:
We term the specic b where Y . 0.5Y
1
as b
1/2
, subject
to the condition that 0 < b
1/2
< 1. If the project manager
uses a so-called front-loaded distribution, where the
funds are disbursed earlier rather than later, b
1/2
will
sit closer to the beginning of the project. Other projects
will have this time more towards the middle (b
1/2
0.5)
or perhaps nearer the end of the scheduled duration
(say, b
1/2
J 0.7). An approximation to the slope of
the curve at b = b
1/2
will allow us to take full advantage
of this new formalism. From the original dierential
equation (Eq. (A.2)) and its solution (Eq. (A.3)), where
Y
1
= d/b, we nd
dY
dt
1=2
dY
1
4
; 3
which can only be an approximation because of the
changed boundary conditions; the 1/2 on the left-
hand side of the equation reminds us that this quantity
is calculated at b = b
1/2
. Based on the PMBOKs verbal
description of the curve, we will next introduce a numer-
ical approximation to this slope that permits an estimate
of d.
The classic S-curve is described as having three parts:
a gentle rise, a steep slope, and a gradual path to the
asymptote. To start, we can assume that these three
parts occur over equal intervals of time, each occupying
t
1
/3. We can further assume, temporarily, that the steep
slope in the center portion comprises two-thirds of the
rise from Y = 0 to Y = Y
1
. The remaining one-third of
the rise occurs throughout the two gently rising end por-
tions. To give the individual project manager the free-
dom to choose an approximation to this central slope,
we introduce r as the factor that describes the magnitude
of the rise in the middle third, and dene r
0.67
through
r
2
3
r
0:67
: 4
When r
0.67
= 1, two thirds of the rise occurs in the mid-
dle interval; r
0.67
> 1 steepens the slope.
With this denition, we nd an expression for d in
terms of r and t
1
: d = 8r
0.67
/t
1
. Using this form for d with
the previous equation for t
1/2
(Eq. (2)) yields the follow-
ing expression for determining the c parameter:
lnc 2 8r
0:67
b
1=2
: 5
These expressions may be inserted back into the original
equation (Eq. 1) to nd:
Y b
Y
1
1 exp8r
0:67
b
1 c exp8r
0:67
b
:
As written, this equation would provide a good t to
cumulative cost or eort data under the assumption that
Y
1
= Y
1
. When planning, however, one does not want
to imply that the workers total eort (and hence total
project cost) will be expended only after an innite time!
We can x this problem by dividing both sides of the
equation by Y
1
, dened through
Y
1
Y
1
1 exp8r
0:67
1 c exp8r
0:67
; 6
and writing the nal form of the equation in terms of the
ratio y = Y/Y
1
:
yb y
1
1 exp8r
0:67
b
1 c exp8r
0:67
b
; 7
where y
1
= Y
1
/Y
1
> 1. By denition, y = 1 at the end
of the project, and y !y
1
> 1 beyond that time. At
b = b
1/2
, y = y
1
/2.
Because this equation forces y to equal 1 at b = 1, it
has less freedom to t the data, but it still does an excel-
lent job. When the normalized data are t with Eq. (7),
the R
2
value drops insignicantly, from 0.996 to 0.993,
and with the exception of the end point (y = 1) the
graph is nearly identical to the display of Fig. 2 (and
so it is not reproduced); c = 12.1 and r
0.67
= 0.746. To
ensure that this one example is not a special case,
Appendix C shows the good t to another randomly
chosen data set.
Finally, how is it all used? For any project, the man-
ager can choose values for b
1/2
and r
0.67
, calculate c from
Eq. (5), nd the normalization factor (y
1
) from Eq. (6),
and plot the desired evolution curve with Eq. (7). If the
manager wants to insist that y = 1/2 at b = 1/2, perform-
ing the b
0
calculation (see Appendix B) will produce a
new b
1/2
(and a corresponding new c) that will fulll
the desired condition. In the t to the PS8 data, for
example, b
1/2
= 0.435, but y = 1/2 at b = b
0
= 0.433.
The conversion to actual durations and costs (i.e., with
dimensions of time and money) comes through the ac-
tual Y
1
and t
1
.
4. Adjusting the curve by changing the rise or the halfway
point
Textbooks (e.g., [8]) present typical S-curves as sym-
metric about both the abscissa and the ordinate, that
is, symmetric both in time and in cost. But this solution
(Eq. (7)) allows a project manager to change either or
both of the two determining parameters, r
0.067
and b
1/2
,
either to match the curves that result from the actual
scheduling or to inuence schedule planning by playing
with alternative cash outows while still in a projects
development stage. In this section, we see how the shape
of the curve changes as b
1/2
moves away from 1/2 and as
r
0.67
moves away from 1. At r
0.67
= 1, the curve produces
the strong rise in the middle noted in the derivation of
Eq. (4). Increases in r
0.67
steepen the rise.
If a manager wants spending symmetrical in time, b
1/2
should be set to about 1/2. When r
0.67
= 1, c = 54.6,
which is reassuringly much greater than 1, and
y
1
1 = 0.018. One front-loads projects by moving
b
1/2
closer to the beginning of the project. Similarly, a
project with most of its spending much later than the
midpoint would use a larger b
1/2
, closer to the end of
the project.
Table 2 shows the values of the dierent parameters
at three choices for the parameters r
0.67
and b
1/2
. Note
that when r
0.67
is small (0.5) or when b
1/2
is large
(0.75), the curve does not have time to approach its
asymptote suciently quickly, and y
1
1 is then of or-
der 1015%.
Figs. 3 and 4 show two sets of three curves corre-
sponding to the values in Table 2. The curves behave
as expected, giving condence in the approximations.
Fig. 3 groups curves with constant rise, r
0.67
= 1, at three
values of b
1/2
: 1/4, 1/2, and 3/4. The middle one is the
familiar textbook curve. The rst and third ones corre-
spond to families of front-loaded and rear-loaded
projects.
Fig. 4 shows three curves at a common b
1/2
= 0.5,
with the rise r
0.67
doubling from 0.5 to 1 to 2. Despite
the common b
1/2
parameter, the curves do not intersect
at y = 0.5 because the actual halfway points (the b
0
s) are
0.454, 0.496 and 0.500, respectively. The large rise in the
slope for the last one produces a large value of c that re-
sults in b
1/2
.b
0
.
The curve with the lowest rise, r
0.67
= 0.5, does not
show much of the familiar S-curve shape, but doubling
the standard rise produces a curve with little time
allowed from minimal spending to full cost. Thus,
again we have some condence that a reasonable
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
y
1/2
= 0.25 0.50 0.75
Fig. 3. The approximate solution, y = Y/Y
1
(Eq. (7)), shown at
r
0.67
= 1 for three values of b
1/2
.
0
0.2
0.4
0.6
0.8
1
0 0.2 0.4 0.6 0.8 1
y
r
0.67
= 2 1 0.5
Fig. 4. The approximate solution, y = Y/Y
1
(Eq. (7)), shown at
b
1/2
= 0.5 for three values of r
0.67
.
approximation was used originally, when r
0.67
= 1, and
in the current absence of further examined data, we
may expect most real projects to show r
0.67
1. The
range of the values about unity awaits analysis.
5. The derivative of the accumulated cost: the cost
distribution
The derivative of the accumulated cost as a function
of time yields the instantaneous cost rate, dY/dt, at any
given time, i.e., the spending distribution. (Fig. 1 shows
this curve for the sample data.) For a symmetric accu-
mulated cost (b
1/2
= 0.5), the plotted derivative looks
similar to a Gaussian (normal) distribution, but it does
dier slightly.
As one might expect, an asymmetrical spending rate
generates an asymmetrical accumulated cost. Many ref-
erences (e.g., [8]) show a symmetrical accumulated cost
but then one or more asymmetrical spending rates with-
out pointing out that these graph sets are internally
inconsistent.
The three curves of Fig. 5 derive from the curves of
Fig. 3, where r
0.67
is held constant but b
1/2
takes three
dierent values. Similarly, the three curves of Fig. 6 hold
b
1/2
at 0.5 while taking the three values of r
0.67
that gen-
erate the curves of Fig. 4.
6. Summary
This paper shows the derivation of a modied logis-
tics equation that project managers can use, in any stage
of a project, when working with costs or other limited
quantities. When plotted versus time, such quantities
typically take a form commonly known in the project
management community as the S-curve, and Eq. (7)
reproduces that shape. The modications used to pro-
duce the equation required only a few minor mathemat-
ical assumptions, and their validity is bourne out in the
results.
With this representation of the curve, a manager has
complete exibility to generate any desired smooth pro-
le by selecting the strength of the rise of the curve and
the point at which half the total (e.g., of costs) has been
expended. Future studies anticipate examining real data
to nd the parameters b
1/2
and r
0.67
and to determine,
for example, if they vary in some regular fashion with
projects in dierent industries.
Acknowledgements
The original solution of the Prigogine dierential
equation is courtesy of Dave van Buren. Nabil Bedewi
and Homayoun Khamooshi gave helpful comments that
improved the paper. Two anonymous referees also
zprovided constructive comments that led to important
ne-tuning, and one of them pointed out the epidemic
example that is noted.
Appendix A. The dierential equation, via Priogine [9]
In the chapter called Self-Organization, in a section
entitled Ecology, Nobel-Prize winner Ilya Prigogine
discusses structural stability and writes about a popu-
0
0.5
1
1.5
2
2.5
0 0.2 0.4 0.6 0.8 1
d
y
/
d
1/2
= 0.25
0.5
0.75
Fig. 5. Derivatives of the three curves shown in Fig. 3.
0
1
2
3
4
0 0.2 0.4 0.6 0.8 1
d
y
/
d
r
0.67
= 2
1
0.5
Fig. 6. Derivatives of the three curves shown in Fig. 4.
lation X in a given medium. Prigogine relates that one
often describes the growth of the population through
the following dierential equation,
dX
dt
bXN X
dX; A:1
where b is related to the rate of birth,

d is related to
mortality, and N is a measure of the milieus capacity
to support the population. Prigogine does not provide
an analytic solution to the equation, but instead refers
the reader to a gure that any project management stu-
dent or practitioner would recognize immediately as a
prototypical S-curve.
This curve, often known now as the logistics
curve, was used, for example, by Hubbert, who made
the rst calculations of the nite duration of fossil fuels
(e.g., [10,11]). The curve also models the growth rate of
a population of interstellar clouds created in galactic
simulations [12]. Those simulations determined the
cloud birth rate and mortality intrinsically (i.e., the
rates were not input), so the variables were redened
(and X changed to Y) to produce a form more appro-
priate both to the interstellar medium and project
management:
dY
dt
dY bY
2
; A:2
where in terms of Prigogines original variables,
d bN
d.
The general solution to this equation is
Y t
b
d
ce
dt

1
A:3
as can be demonstrated by dierentiating it (i.e., Eq.
(A.3)).
Imposing the boundary conditions appropriate to
project management changes its form slightly, to Eq.
(1), as explained in the main text. The transformation re-
quires subtracting the initial value, Y
0
, from the general
solution and dening Y
ss
= d/b = Y
1
+ Y
0
to remove Y
ss
in favor of Y
1
.
Appendix B. Obtaining the exact value of the one-half
point
By denition, the value of b at which y . 1/2 is b
1/2
.
Let b
0
equal the value of b such that y = 1/2 exactly. This
section explains how to calculate b
0
.
From the solution represented by Eq. (7), we can cal-
culate the slope at b
1/2
and join, with only a slight error,
b
1/2
and b
0
on a straight line of that slope. With this
approximation, we can nd the desired b
1/2
parameter
such that y = 1/2 at a chosen b
0
, as shown in Table 2.
(There the b
1/2
s corresponding to the chosen bs are
listed in the column under the parenthetical b
1/2
.)
We nd the new b
1/2
through:
b
1=2
b
0
Db B:1
where
Db
1
4r
0:67
y
1
1
y
1

c 1
c 2

: B:2
As an aside, I note that in deriving the above expres-
sion, one sees the consistency with the original slope cal-
culation. The slope used above equals that from Eq. (3)
multiplied by (c + 2)/(c + 1), which approximately
equals 1 for any large c.
Most project managers will probably not be con-
cerned about the small dierence Db, but for those who
would like to specify the exact point at which y = 0.5, a
quick iteration will generate the b
1/2
that corresponds
with the desired b
0
, as follows. First, set b
0
to the desired
time. The given r
0.67
and an initial guess at b
1/2
(one can
use the b
0
itself) determine the rst c. Calculate Db. Use
this Db with b
0
to obtain the rst new b
1/2
. The new b
1/2
yields a new c, from which one obtains a new b
1/2
, and so
forth. In usually fewer than ten loops, the equations
converge to a xed value of b
1/2
that corresponds to
the desired b
0
. Thus, the b
1/2
term is now only a param-
eter that is near the actual b
0
at which y = 1/2.
Appendix C. Fitting the curve to a second data set
To demonstrate that the example in the main text
does not represent any specially chosen case, the
approximate solution, Eq. (7), was t to an example ta-
ken randomly from a textbook [13] (in the book, it is not
used to demonstrate an S-curve). The data in Fig. 7 are
0
200
400
600
800
1000
0 10 20 30 40 50
C
u
m
u
l
a
t
i
v
e

E
x
p
e
n
s
e

(
$
1
0
0
0
)
Weeks
Fig. 7. A second example of data t by the approximate solution, Eq.
7; r
0.67
= 0.881 and c = 22.4.
the early-start-time weekly expenses in the LOGON
project, Table 9.5, in Nicholass book. These data vary
from the classically shown S-curve in two respects: (1)
The three points sitting at about 20 weeks have identical
values, and (2) The summed expenses continue to climb
at the end of the project. (If most projects showed this
type of accumulated cost growth, the phrase S curve
might not have arisen.)
Nevertheless, the solution ts suciently well. The
dierence between the t and the nal data point is
only about 6 percent: the curve would serve as a
working management model for the projects cost
evolution. If we add data points at the same or
slightly greater magnitude at the end to atten the
curve and produce a more standard prole, the t
improves.
References
[1] Project Management Institute Standards Committee, A guide to
the project management body of knowledge 2000 ed. (PMBOK).
Newtown Square, PA: Project Management Institute, Inc., 2000.
[2] Murmis GM. S curves for monitoring project progress. Project
Manage J 1997:2935.
[3] Cio DF. Completing projects according to plans: An earned
value improvement index. J Oper Res Soc 2004 [submitted].
[4] Weisstein EW. Gompertz curve, from MathWorldA Wolfram
Web Resource. http://mathworld.wolfram.com/GompertzCurve.
html, accessed 3 June 2004.
[5] Bourke P. Gompertz function. http://astronomy.swin.edu.au/
~pbourke/analysis/gompertz, accessed 3 June 2004.
[6] Cio DF. Managing project integration. Vienna, Virginia: Man-
agement Concepts, Inc.; 2002.
[7] The Sciforma Corporation, Project Scheduler software, PS8.
(http://www.sciforma.com/products/ps_suite/ps8_overview.htm)
(2001).
[8] Meredith JR, Mantel SJ. Project management: A managerial
approach. 5th ed.. New York: Wiley; 2003.
[9] Prigogine I. From being to becoming: Time and complexity in the
physical sciences. San Francisco: W.H. Freeman and Company;
1980.
[10] Hubbert MK. Energy from fossil fuels. Science
1949;109(2823):1039.
[11] Hubbert MK. Exponential growth as a transient phenomenon in
human history. In: Presented before the World Wildlife Fund,
fourth international congress, the fragile earth: toward strategies
for survival, San Francisco, 1976. Copyright 1976 by M. King
Hubbert, 1976.
[12] Cio DF, Shull JM. Simulations of supernovae-dominated
interstellar media in disk galaxies. Astrophys J 1991;367:96.
[13] Nicholas JM. Project management for business and technology:
Principles and practice. 2nd ed.. Englewood Cli, NJ: Prentice-
Hall; 2000.
Project Scheduling using Dependency Structure Matrix
J. Uma Maheswari
a,
*
, Koshy Varghese
b
a
Department of Civil Engineering, Building Technology and Construction Management Division,
Indian Institute of Technology, Madras, Chennai 600 036, India
b
Department of Civil Engineering, Building Technology and Construction Management Division,
Indian Institute of Technology, Madras, Chennai 600 036, India
Received 20 April 2004; received in revised form 25 May 2004; accepted 8 October 2004
Abstract
Dependency Structure Matrix (DSM) has been identied as a powerful tool to plan the activity sequences, identify and manage
information exchanges. However, its application in scheduling is very limited. So far, DSM has been used to enable critical path
calculations by assigning the amount of eort/work done as duration to the activities. This paper addresses communication time,
a new concept while estimating the normal project duration.
The other issue arises, while planning and scheduling compressed projects with DSM. When the activities are overlapped to
achieve the compressed duration, there arise two cases the natural overlap (involving minimum risk) and the forced overlap
(involves more risk). This paper focuses on the estimation of natural overlap project duration using DSM. Further, the author also
proposes a detailed implementation procedure focusing on the above ideas and is illustrated through an example.
Keywords: Managing projects; Processes and procedures; Scope of work; Time
1. Introduction
Conventional tools like CPM/PERT are not suitable
for sequence analysis because they cannot model informa-
tion ow [1,2]. Researchers have investigated Depend-
ency Structure Matrix (DSM) as a powerful tool in
planning the activity sequences by representing the feed-
back loops and also in identifying and managing informa-
tion exchanges [1,2]. However, its application in
scheduling is very limited. So far, DSM has been used to
enable critical path calculations by assigning the amount
of eort/work done as duration to the activities [3].
In reality, time is also spent in gathering the informa-
tion before/during the execution of the activity. This is
referred as communication time and the need for mode-
ling the same arises only when dealing with information
ows among activities (CPM/PERT models workow).
The primary inputs to schedule any project includes
the list of activities, dependency relationship and
amount of work done/eort in the form of duration.
Here, the authors have attempted to capture the com-
munication time along with the work done/eort (using
DSM) while estimating the normal project duration.
When the activities are overlapped to meet the com-
pressed project duration, there arise two cases namely -
natural overlapping and forced overlapping. Natural
overlapping is of interest to the managers as it involves
minimum risk (comparatively). Finish-to-Start (FS)
relationship is the conventional representation of rela-
tionship between activities in DSM, which alone is insuf-
cient to represent natural overlap projects. This paper
also focuses on the estimation of the natural overlap
duration by capturing the time taken to transfer the
doi:10.1016/j.ijproman.2004.10.001
*
Corresponding author. Tel.: +91 44 2257 8319; fax: +91 44 2257
8281.
E-mail addresses: uma@civil.iitm.ernet.in (J.U. Maheswari),
koshy@iitm.ac.in (K. Varghese).
PROJECT
MANAGEMENT
information between activities through Start-to-Start
(SS) relationship.
The proposed concepts are structured into a two-
phase procedure and are illustrated using an example.
These concepts are framed with two major assumptions
(for simplicity) as follows: (1) the example consists of
dependent and independent activities only (which im-
plies that the interdependent activities and cyclic loops
are ignored in the present work); (2) information ex-
change between any two activities occurs only once.
The remaining sections of this paper are organised
into six parts. The next section details an overview of
DSM. The following section reports the need for com-
munication time while estimating the normal project
duration and the next one discusses the types of overlap-
ping as natural overlapping and forced overlapping with
a special mention on estimation of natural overlap pro-
ject duration. The subsequent section presents a detailed
procedure for implementing the above concepts using an
example. This is followed by a discussion on the utility
of the procedure. Finally, the conclusions of the study
are presented.
2. Dependency Structure Matrix an overview
Frequently used project-planning tools such as CPM/
PERT are graphic descriptions of task ows [4]. These
tools can model independent and dependent activities
and they cannot model information ow. Further,
graph-based information-modeling tools such as
IDEFO are also not suitable for sequence analysis be-
cause of the complexity in modeling [5]. Researchers
have investigated DSM as a powerful tool in planning
the activity sequences and also in identifying and manag-
ing information exchanges [1,2]. A major advantage of
the matrix representation over the other tools lies in its
compactness, and ability to provide a systematic map-
ping among the elements that is easy to read regardless
of its size. It clearly represents where interdependence oc-
curs, and procedures to identify and evaluate sequence
options. DSM provides a better planning methodology
or framework for the managerial decisions.
The basic representation of activity DSM is a square
matrix containing a list of activities in the rows and col-
umns in the same order in a matrix form [6,7]. The order
of activities in the rows or columns in the matrix indi-
cates the sequence of execution. The relationship be-
tween the activities are represented with an X mark
in the o-diagonal cells. The activities have to be read
along the column as gives information to and along
the row as needs information from.
If any mark lies above the diagonal, it implies that
an assumption has to be made to execute the corre-
sponding sequence. The process of rearranging the or-
der of activities by moving an entire row and column
on either side (up/down and left/right) in such a way
that the resulting matrix has marks either below the
diagonal or close to the diagonal is called partitioning.
This process is mainly to minimize the number of
assumptions. In this paper (for simplicity), the authors
have assumed that there are no marks above the diag-
onal after partitioning process, which implies that there
are no interdependent activities and loops. The diago-
nal cells generally have no value but the duration for
each activity can be included. Even though DSM has
been proved to be a powerful planning tool, its appli-
cation in scheduling is very limited. The following sec-
tions bring out the extensions of the conventional
DSM from scheduling viewpoint.
3. Communication Time in Normal Project Duration
So far, DSM has been used to enable critical path cal-
culations by assigning the amount of eort/work done
as duration to the activities. Communication of infor-
mation exchanges between dierent activities/project
participants is essential for a projects success. Unlike
workows, information ows are more frequent be-
tween activities. In other words, considerable amount
of time is spent in gathering the information before/dur-
ing the execution of the activity. This time is referred as
communication time and it includes the time spent for
discussions, organising meetings, sending and receiving
mails, Internet browsing, waiting for decisions from
the higher ocials, etc.
With the basic inputs for scheduling, the authors have
proposed the estimation of normal project duration
(using DSM) by capturing the communication time
along with the work done for each activity. The normal
project duration inclusive of the communication time is
estimated with the formulas given below. Here, A
ij
rep-
resents a DSM, where the diagonal cells represent the
work done for each activity and the o-diagonal cells
represents the communication time.
EF
i
ES
i
A
ii
; 0 < i 6 n 1
ES
j
MaxEF
i
A
ji
; 0 < i 6 n; 0 < j 6 n 2
Normal project duration MaxEF
j
; 0 < j 6 n 3
where n is the number of activities; i all the (immediate)
predecessors of j ; j the current activity chosen in the or-
der as identied by partitioned DSM; ES the early start;
EF the early nish.
4. Overlap an overview
The sequential method of activity execution without
violating the FS relationship is called no overlapping.
224 J.U. Maheswari, K. Varghese / International Journal of Project Management 23 (2005) 223230
Owing to the demand in completing the projects in a
short span, activities are required to overlap as far as
possible. Conventionally, all information is released
from a particular upstream activity only after its com-
pletion and in the same way any downstream activity
starts to execute, after all the information is received
at the start of the activity. But in reality, information
can be released prior to the completion of the predeces-
sor activity; and the successor activity can continue its
execution based on this information. Thus, it need not
wait for the predecessor to fully complete or the succes-
sor to start resulting in natural overlap. Krishnan et al.
[8] had rightly addressed that for any overlapping to be
eective, upstream information availability and down-
stream information needs must be clearly understood.
The next type of overlapping arises when the two activ-
ities, which cannot be overlapped in the natural way
but in order to achieve the shortened project duration,
are forced to start more or less simultaneously or with
a lag, called as forced overlapping.
Let us consider two activities namely A and B,
where A gives information to B. The duration of A
is assumed to be d
A
, while for B is d
B
. When there is
no overlapping, the two activities would be represented
as seen in the Fig. 1(a). In reality, if A can release cer-
tain piece of information say x after t
A
(which is less
than d
A
) and if B requires the same information after
t
B
(which is less than d
B
), then overlapping naturally
is shown in the Fig. 1(b). But, if A is forced to release
x (in the form of x
1
) even before t
A
and/or if B re-
quires information before t
B
, then it is forced overlap
as in the Fig. 1(c). Researchers at MIT have addressed
the types of overlapping from a dierent viewpoint
[8,9]. As the managers are forced to plan for com-
pressed projects with minimum risk, the need for natu-
ral overlap emerges. The following sub-section
elaborates on the natural overlapping.
4.1. Natural overlap and time factor
As it has been stated earlier, natural overlap arises
by exactly matching/merging the time at which infor-
mation is exchanged between activities. This time is
represented (in DSM) in the form of a ratio called as
time factor. It is the ratio between the time taken to
exchange any information (either sending/receiving)
from the start of any activity to the corresponding
(predecessor/successor) activity duration as shown in
the Fig. 2. In this gure, let us assume there are two
activities P and S. Now, if p
1
units of time are re-
quired to release the information from activity P and
if p
2
is the duration of P, then the time factor of send-
ing the information from P (predecessor activity) will
be T
p
(p
1
/p
2
). Similarly, the time factor of receiving
the information for the successor activity S is calcu-
lated as T
s
(s
1
/s
2
). Hence, time factor has two compo-
nents namely T
p
(represented for the predecessor
activity) and T
s
(for the successor activity).
Here, the authors have assumed that the informa-
tion transfer between any two activities occurs only
once. Time factor is a number (ratio) ranging from 0
to 1 represented along the o-diagonal cells. Further,
it can logically be referred as the SS relationship asso-
ciated with lag. Since the time taken is calculated from
A
B
d
A
d
B
No Overlapping
t
B
A
B
t
A
d
A
d
B
x
Natural Overlapping
t
B
A
B
t
A
d
A
d
B
x
1
Final information
Preliminary information
Legend
Forced Overlapping
(a)
(b)
(c)
Fig. 1. Types of overlapping: (a) no overlapping; (b) natural overlap-
ping; (c) forced overlapping.
s
1
P
S
p
1
p
2
s
2
Fig. 2. The time factor of transfer of information for the predecessor
and the successor activity.
J.U. Maheswari, K. Varghese / International Journal of Project Management 23 (2005) 223230 225
the start of any activity, it can be referred otherwise as
SS relationship and, the time taken to exchange any
information (either sending/receiving) can be treated
as lag. Natural overlap project duration is estimated
by using the formulas given below. Here, the time fac-
tor of information exchange along with the duration
for each activity and their relationship is represented
in two separate matrices B
ij
(for all the T
p
values)
and C
ij
(for all the T
s
values):
ES
j
MaxES
i
B
ji
B
ii
C
ji
C
jj
;
0 < i 6 n; 0 < j 6 n 4
EF
j
ES
j
B
jj
; 0 < j 6 n 5
Natural overlap project duration
MaxEF
j
; 0 < j 6 n 6
where n is the number of activities; i all the (immediate)
predecessors of j; j the current activity chosen in the or-
der as identied by partitioned DSM; ES the early start;
EF the early nish.
Here, B
jj
is equal to C
jj
(which implies that the dura-
tion is same in both the matrices).
5. Solution procedure
This section presents the solution procedure for
estimating the normal project duration and the natu-
ral overlap project duration using an example. The
procedure is structured into two phases. The rst
phase involves in the estimation of the normal project
duration while the second, in the estimation of natu-
ral overlap project duration. For the ease in under-
standing, the example is explained along with the
procedure. The example consists of 10 activities from
A to J, and the list of activities along with the infor-
mation predecessors and the duration are listed in
Table 1.
5.1. Phase-1 Estimation of Normal Project Duration
using DSM
(1) Start Phase-1.
(2) The partitioned matrix is shown in the Fig. 3
Fig. 3(a) captures the DSM representation and
the Fig. 3(b) shows the reordered rows and
columns indicating the feasible execution
sequence. The steps involved in the formation
of partitioned DSM are not in the scope of this
paper.
(3) Enter the duration (referred as the amount of work
done) for each activity along the diagonal cells and
use a standard project management tool to nd the
conventional project duration.
The total duration for the example is 50 days
(4) Now, enter the communication time in the o-diag-
onal cells instead of X marks to form the matrix
A
ij
as seen in the Fig. 4.
In the above gure, A
21
has the value 1 which
indicates that it requires 1 unit of duration to
gather the information from A to C.
Table 1
List of activities showing the Information predecessors and the
duration
S. No. Activity ID Information predecessors Duration (days)
1 A 6
2 B D 8
3 C A 7
4 D A, F 4
5 E B 9
6 F A, C 1
7 G F, J 2
8 H I 10
9 I D, G, E 5
10 J F, B 3
A B C D E F G H I J
A
B
X
C
X
D
X X
E
X
F
X
G
X X
H
X
I
X X X
J
X X
DSM Representation
A C F D B J G E I H
A
C X
F X
D X X
B X
J X X
G X X
E X
I X X X
X H
Partitioned DSM
(a)
(b)
Fig. 3. Activity sequence representation using DSM.
(5) Then, apply the values of A
ij
in the formulas (1) and
(2) to nd (EF)
i
and (ES)
j
. Repeat the above two
formulas successively for all the n activities.
For example, (ES)
A
= 0 (no predecessors)
EF
A
ES
A
A
11
here; i 1 and n 10
0 6 6 from(1)
ES
C
MaxEF
A
A
21
here; i 1; j 2 and n 10
Max6 1 7
EF
C
ES
C
A
22
here; i 2 and n 10
7 6 13:
(6) OncetheESandEFfor all activities arefoundout, the
normal project duration can be calculated from (3):
Normal project duration MaxEF
j
0 < j 6 n
74:8 days
(7) End Phase-1.
5.2. Phase-2 Estimating Natural Overlap Project
Duration using DSM
(8) Start Phase-2.
(9) After step 3, enter the time factor of transfer of
information for the predecessor activity (i.e. T
p
)
for each mark to form the matrix B
ij
as shown in
the Fig. 5(a)
Here, 0.8 in B
21
implies that A can send the
information that is required for C at the end of
0.8 times its duration.
(10) Now, enter the time factor of receiving the infor-
mation for the successor activity (i.e. T
s
) for each
mark in a separate matrix C
ij
as in Fig. 5(b)
Here, 0.1 in C
21
implies that, it is essential for C
to receive the information from A only at 0.1
time its duration rather than at its start to con-
tinue its execution.
(11) Then, calculate ES and EF for all the n activities
following the order of execution from the matrix
B
ij
/C
ij
, using the Eq. (4) and (5).
Here, (ES)
A
= 0 (no predecessors)
ES
C
MaxES
A
B
21
B
11
C
21
C
22
here; i 1; j 2 and n 10
Max0 0:8 6 0:1 7 4:1
EF
C
ES
C
B
jj
4:1 7 11:1:
(12) Once ES and EF for all the activities are found out,
the natural overlap project duration can be calcu-
lated from (6):
A C F D B J G E I H
A 6
C 0.8 7
F 0 0.6 1
D 0.8 0.7 4
B 0.9 8
J 0.9 1 3
G 0.5 1 2
E 0.9 9
I 0.6 0.8 1 5
H 10
B
ij
=
(a)
A C F D B J G E I H
A 6
C 0.1 7
F 0 0.3 1
D 0.1 0.2 4
B 0.4 8
J 0.2 0 3
G 0 0.3 2
E 0.1 9
I 0.2 0.6 0 5
H 0.4
0.7
10
C
ij
=
(b)
Fig. 5. (a) DSM showing the duration and time factor (a1/a2) of
transfer of information from the predecessor activities. (b) DSM
showing the duration and time factor (c1/c2) of receiving information
to the successor activities.
A C F D B J G E I H
A 6
C 1 7
F 0 2 1
D 0.8 0.3 4
B 4 8
J 1.5 0 3
G 0.1 0.4 2
E 4.5 9
I 3.5 2 3 5
5 H 10
A
ij
=
Fig. 4. DSM showing the duration for each activity along with
communication time.
Natural overlap project duration MaxEF
j
33:1 days
(13) End Phase-2.
6. Discussions
Even though DSM is a powerful planning tool, it
has major drawback as a stand-alone Project Manage-
ment (PM) tool in showing time scale (time aspects)
[10]. Hence, researchers have integrated DSM with
PM tool (Gantt Chart [10], MS Project [11]) to over-
come the above drawback (this includes critical path,
oat, etc.). Since integrating DSM with PM tool can-
not solve most of the scheduling issues, research work
in enriching DSM as a stand-alone PM tool is in pro-
gress. Among them one such issue is modeling and
estimating normal and natural overlap project
duration.
The present discussion focuses on issues faced in
implementing the solution procedure when working
with real projects. For a given list of activities and
information dependency relationships, the various
steps in estimating the project duration (normal and
natural overlap) have been explained. In the rst
phase (Estimation of normal project duration), the
activity duration in the form of work done/eort
along with the communication time can give a practi-
cal estimate of the project duration. But, it is very dif-
cult to note down the time-spent for communication
for each activity relationships, especially for new
projects.
The next duration estimation is the natural over-
lap. Compared to the conventional project duration
estimation of 50 days (Fig. 6(a)), the natural overlap
project duration is 33.1 days (Fig. 6(c)). An analysis
of the Figs. 6(a)(c) reveals that the order of activity
execution changes drastically especially for overlap
scheduling based on the o-diagonal values of B
ij
and C
ij
. With stand-alone DSM, it is dicult to pre-
dict the order of execution of activities for natural
overlapping case. For instance, from the Fig. 5(a)
and (b), the sequence of execution is CFDB,
whereas in natural overlap, all the four activities are
executed in parallel with a lag as seen in the Fig.
6(c). For natural overlap project duration, the bar
chart represented from DSM gives the knowledge of
sequential and parallel activities, rather than the
stand-alone DSM sequence.
Moreover, the authors have assumed that between
any two activities, the information exchange occurs
only once. In reality, information is exchanged be-
tween any two activities more than once. Here, the
authors suggest breaking the activities into n number
of sub activities to retain the assumption on single
information exchange.
Further, even for conventional execution, the interde-
pendent activities and loops need assumptions. Assump-
tions are also forced to be made while modeling forced
overlapping. The authors have clearly stated that
assumptions are not represented for simplicity reasons.
In reality, if such assumptions have to be made and it
goes wrong, it leads to rework. Rework duration estima-
tion has been reported by [3,12,13]. Further, the rework
of a single/group of dependent activities in a cycle/circuit
is known as iteration.
If these iterations are performed purposely in projects
for a converging solution, then it is dened as planned
iteration. The other type of iteration namely unplanned
iteration arises from new information arriving during
execution of the project [14]. While the project is exe-
cuted, unplanned iterations play a major role, which
has to be addressed along with the planned iterations.
Currently, planned iterations and unplanned iterations
have been modeled separately [15,16]. But, the issue of
natural overlap along with iteration has not been ad-
dressed and the research investigation in this regard is
in progress.
Project plan updates are any modication to the con-
tents of the project plan. This update includes work
break down updates, activity list along with the depend-
ency relationship updates, schedule updates resource up-
dates and budget/cost updates [17]. Updating/
incorporating the changes in dependency relationship
among the activities creates unplanned iteration. To
incorporate the other updates, there may arise a need
to model dynamic DSM. Research in this critical area
is on the go.
The dependency relationship among the activities in
conventional DSM indicates the information ow.
There are other relationships between the activities
namely logical dependency (followed in conventional
CPM/PERT), resource dependency, etc. Single resource
and multiple resource dependency have been already
modeled using DSM [10,18]. Estimation of project dura-
tion along with the single and multiple resources is crit-
ical to be addressed.
Apart from the scheduling viewpoint, identifying the
activities as well as information dependency relation-
ship for each activity is a dicult task especially for
new projects (formation of Table 1). Signicant com-
mitment, time and interaction are required from the ex-
pert group in order to arrive at the activity list and the
information dependencies. Further, the partitioning
process is directly inuenced by the relationship be-
tween the activities viz. independent, dependent and
interdependent. There are various methods in the for-
mation of partitioned DSM and since it is not in the
scope of this paper, interested readers may be referred
to [5].
7. Summary and conclusions
Use of DSM for planning the activity sequences, in
managing information exchanges and in evaluating the
sequence options have been well documented. Even
though DSM proves to be a powerful planning tool,
its current state of usage from a scheduling perspective
is minimal. The limitations in the area of scheduling
using DSM have been addressed.
The solution procedure for nding the normal pro-
ject duration (along with communication time) and
the natural overlap project duration (with the help
of time factor in exchange of information) was dis-
cussed. Few extensions to the existing work were pro-
posed. The proposed concept requires renement as
discussed in the earlier section. Illustration from the
above example reveals that the proposed concepts
and procedure can be applied for any domain because
19
(a)
A
C
F
D
B
J
G
E
I
H
50 days
(b)
A
C
F
D
B
J
G
E
I
H
74.8 days
1 day
Scale 4d = 1unit
F
D
B
J
G
E
I
H
Overlap Project Duration = 33.1 days
A
C
0.7
4.8
(c)
Scale 2d = 1unit
Fig. 6. Estimation of: (a) normal project duration with duration alone; (b) normal project duration with duration and communication time;
(c) natural overlap project duration.
of its simplicity. There is a signicant need for the re-
search to be done in the overall application of DSM
in scheduling area.
7.1. Scope for further work
In addition to the extensions of the current work, new
areas of further work are:
(a) Multiple information transfer between activities:
The authors have recommended breaking the
activities into n sub activities to manage the infor-
mation transfer between activities. In reality, there
may be many information transfers across activi-
ties and splitting the activities into many sub activ-
ities leads to larger matrices and hence it becomes
dicult to control. Research investigation in multi-
ple information transfer is in progress.
(b) Incorporating interdependent activities and loops:
When the activities are split into sub activities, auto-
matically most of the interdependencies and loops
may be removed. Since, formation of sub activities
was not considered an ideal solution, research inves-
tigation in estimating normal project duration and
natural overlap duration incorporating the interde-
pendent activities (along with loops) is also in
progress.
(c) Estimation of natural overlap project duration
along with communication time: The authors have
dealt the above two issues separately in two sections.
In reality, both the situations occur together. There
is signicant amount of work to be done in this area.
(d) Estimation of rework duration along with natural
overlap: The authors have addressed the issue of nat-
ural overlap in detail and the procedure to estimate
the same using DSM. The rework duration is not in
the scope of this paper, but few researchers have con-
tributed in this area as discussed earlier. Here, further
work in estimating the rework duration along with
the natural overlap can yield wide benets for the
practitioners. This is a critical area for further work.
(e) Stand-alone PM tool: many researchers have
enriched DSM from a scheduling viewpoint as illus-
trated in the discussions. Here, the authors have
dealt time management alone. The next step in
investigation along this pace includes cost, resource
management along with time.
References
[1] Yassine A, Falkenburg D, Chelst K. Engineering design manage-
ment: an information structure approach. Int J Prod Res
1999;37(13):295775.
based method for organizing tasks in product development. Res
Eng Des 1994;6(1):13.
[3] Browning TR. Use of dependency structure matrices for product
development cycle time reduction. In: Proceedings of the fth
ISPE international conference on concurrent engineering:
research and applications, Tokyo, Japan; 1998.
[4] Eppinger SD. Innovation at the speed of information. Harvard
Bus Rev 2001;79(1):14958.
[5] Malmstro m J, Pikosz P, Malmqvist J. The complementary roles
of IDEF0 and DSM for the modelling of information manage-
ment processes. In: Proceedings of the fth ISPE international
conference on concurrent engineering: research and applications,
Tokyo, Japan, July 1517, 1998; p. 26170.
[6] Eppinger SD, Whitney DE, Yassine AA, Roemer T. The MIT
design structure matrix DSM home page, 2004. Available
from: http://web.mit.edu/dsm/.
[7] Steward DV. The design structure system: a method for managing
the design of complex systems. IEEE Trans Eng Manage
1981;EM-28(3):714.
[8] Krishnan V, Eppinger SD, Whitney DE. A model-based frame-
work to overlap product development activities. Manage Sci
1997;43(4):43751.
[9] Terwiesch C, Loch CH. Measuring the eectiveness of
overlapping development activities. Manage Sci 1999;45(4):
45565.
[10] Cho SH. An integrated method for managing complex engineer-
ing projects using the design structure matrix and advanced
simulation. MS Theses, 2001.
[11] Steward DV, Williams S. Problematics, 2004. Available from:
http://www.problematics.com/psm32/Help/MSProject.asp.
[12] Carrascosa M, Eppinger SD, Whitney DE. Using the design
structure matrix to estimate product development time. In:
Proceedings of the ASME design engineering technical confer-
ence, Atlanta, Georgia, USA; 1998.
[13] Chen CH, Ling SF, Chen W. Project scheduling for collaborative
product development using DSM. Int J Project Manage
2003;21(4):2919.
[14] Eppinger SD. Innovation at the speed of information. Harvard
Bus Rev 2001;R0101L:311.
[15] Smith RP, Eppinger SD. Identifying controlling features of
engineering design iteration. Manage Sci 1997;43(3):27693.
[16] Smith RP, Eppinger SD. A predictive model of sequential
iteration in engineering design. Manage Sci 1997;43(8):1104
20.
[17] The PMBOK
Guide. A guide to The project management

body of knowledge. The Project Management Institute Inc.,
2000.
[18] Yassine A, Browning T, Analyzing multiple product development
projects based on information and resource constraints. PD-Lab
working paper, PDL-2004-01, 2002.
Process improvement in project expediting: there must be a better way
Keith A. Willoughby
*
Department of Management, Bucknell University, Lewisburg, PA 17837, USA
Received 21 August 2003; received in revised form 14 November 2003; accepted 27 July 2004
Abstract
The development of process improvement approaches for the project expediting function is reported. The current expediting rela-
tionship can be quite confrontational and argumentative, loaded with disputes. Expediting failures often result from a mismanage-
ment of expectations and poor communications. These negative implications can contribute to cost overruns and schedule delays.
Based on interviews conducted with several professionals within the oil and gas industry, various suggestions are proposed to instill
a more cooperative relationship between owner rms and suppliers.
Keywords: General managing projects; Success and strategy; Contractual partnerships; Alliances
1. Introduction and literature review
The performance of large scale projects depends to a
major extent on the eectiveness of decision-making in
the materials management area.
Silver [1, p. 94].
As the above quote declares, materials management
(also known as procurement and logistics) plays a signif-
icant role in the performance of large scale projects. E-
cient performance allows one to excel on cost and
duration dimensions. Expediting represents an approach
for managing the materials used in a given project. Specif-
ically, it monitors the performance of suppliers and sub-
contractors so that required products are manufactured
to appropriate quality levels, within contractual deadline
dates. Therefore, one could postulate that the manner in
which the expediting function is executed plays a substan-
tial role in the performance of all types of projects.
This paper examines the nature of project expediting
operations, specically drawing commentary and
improvement suggestions from professionals within the
oil and gas industry. When undertaking projects, an
owner rm (such as Husky Oil or Nova) acquires
goods from suppliers or obtains the services of sub-
contractors. It is claimed, by those interviewed, that
the expediting function has become quite confronta-
tional, argumentative and dispute-oriented. We contend
that such an approach is dangerous to the performance
of all types of projects. Consequently, this paper will
discuss a number of process improvement initiatives that
can be taken to avoid the inherent problems of expedit-
ing, before such diculties materialize.
The accounts of costly and late projects are abun-
dant. Thompson and Perry [2] examined all projects
funded by the World Bank between 1974 and 1988. Of
the 1778 projects checked for cost behavior, a full 63%
came in over-budget. When the authors analyzed 1627
projects for schedule performance, 86% of them were
completed subsequent to predicted completion dates.
Other researchers have suggested process improve-
ment approaches in a variety of project environments.
Tabatabai-Gargari and Elzerka [3] discussed process
doi:10.1016/j.ijproman.2004.07.012
*
Tel.: +1 570 524 2939 (home)/577 1751 (oce); fax: +1 570 577
1338.
E-mail address: kwilloug@bucknell.edu.
PROJECT
MANAGEMENT
improvement in preconstruction activities. They exam-
ined computer-aided design and knowledge-based sys-
tems for expediting the generation of design
alternatives, specically focusing their work on the con-
struction of mezzanine structures. Previously, the prepa-
ration of design quotations was conducted manually,
taking about two hours. Now with this user-friendly
automated system (the authors claim that salespersons
with sparse computer literacy can be trained in a single
hour to use the system), quotation time has been sliced
to about ten minutes. More accurate cost estimates have
also been realized.
Ngee et al. [4] applied process improvement to build,
operate and transfer (BOT) project negotiations. In this
type of situation, the specic project is transferred to an-
other company at a later stage. The authors determined
suitable pricing structures for the nancial and contrac-
tual parameters associated with these types of contracts.
Instead of relying on time-consuming approaches to
negotiate pricing structures, the authors developed a
multiple regression model using the tari, concession
period, and rate of return as explanatory variables,
and internal rate of return as a response variable. In
the end, such a method eliminated the consumption of
considerable resources (namely time) that had occurred
under the previous system.
Cho [5] discussed the conversion of the Bergstrom Air
Force Base into a $600 million, 25-gate civilian airport
in Austin, TX. A program management venture was
adopted in the project, specically addressing the pro-
jects cleanup and environmental requirements. A rather
high degree of project eciency was attained; indeed,
the author noted that this model may help to spur sim-
ilar conversion eorts.
Wright [6] studied the construction of 32 pre-engi-
neered metal dormitories in 24 sites of the Texas Depart-
ment of Criminal Justice (TDCJ) prison state system in
a six-month period. The projects were handled through
a cooperative contracting agreement. This prevented an
adversarial relationship from developing between the
rms. In particular, the TDCJ facilitated frequent coor-
dination between the various rms, sometimes on an
hourly basis. Joint ventures were established, as rms
realized that they could accomplish more together than
by working as individual companies. A teamwork
atmosphere (if one of us failed, we all failed) prevailed
among the rms.
As the above literature illustrates, process improve-
ment is often required to ameliorate the performance
of large-scale projects and to mitigate the problems of
adversarial relationships. We do note, however, that
other industries have recognized that less confronta-
tional processes can lead to enhanced cooperation and
results. A discussion of some of these cases will serve
to strengthen our argument that improving project expe-
diting leads to better project performance.
Various retail and manufacturing industries have
appreciated the benets of improved supplier-customer
relationships. Kinsey [7] addressed the cooperative proc-
esses at work in the food industry. The author described
the Wal-Mart way of doing business, a model for
improving eciency and for allowing supply chain part-
ners to combine together in an eort to share consumer
sales data and inventory management information. In-
deed, the use of Wal-Mart as an appropriate benchmark
for assessing cooperative supply chains is well docu-
mented. Briggs [8] analyzed Wal-Marts approach to
collaborative planning, forecasting and replenishment
(CPFR), a benecial strategy for dealing with buyer
seller relationships. The company plans to implement
such relationships with over 100 of its suppliers.
Frequently, these cooperative processes use electronic
data interchange (EDI) as a means to eectively plan
these overall operations. Holland et al. [9] oer a thor-
ough analysis of EDI implementation. Using the apparel
industry as a case study, Schieier [10] showed that quick-
response technologies (like bar-code scanning and EDI)
permit a change in retailer/supplier relationships from
adversarial conicts to more cooperative alliances.
Moynihan [11] focused his analysis on the benecial
outcomes of cooperative relationships within the health-
care industry. In this particular case, improved interac-
tions occurred between healthcare providers and
product suppliers, as well as between providers and pay-
ers. In a study of the US automobile industry, Iskandar
et al. [12] discovered that managerial pro-activeness, an
important component of cooperative supply chains, was
the most signicant factor in explaining overall success.
This paper is organized as follows. In the next sec-
tion, we examine the nature of project expediting and
describe its current deciencies. Then, we present some
suggestions for improving project expediting. We make
special mention of the benets that could accrue from
implementation of these proposals. Concluding remarks
are provided in the nal section.
2. Nature of project expediting
In the mid-1980s, Silver [1,13,14] conducted a study
of logistics issues in the large scale projects of oil and
gas companies (the work undertaken by Silver served
as the genesis for this current paper). His analysis fo-
cused on over a dozen rms (both owner rms and con-
tractor businesses) in the Alberta area of western
Canada. When queried regarding the importance of
expediting in a project, all rms claimed that its role
was signicant. It had a substantial impact on project
performance. Traditionally, expeditors are those indi-
viduals in a company attempting to ensure that items
are delivered, or received, on time. In the event of sched-
232 K.A. Willoughby / International Journal of Project Management 23 (2005) 231236
ule delay, they seek alternative methods of (very
quickly) ensuring delivery reliability.
The nature of expediting has become quite argumen-
tative, dispute-oriented and confrontational. To more
fully investigate this environment, we conducted inter-
views with professional expeditors, owner companies
and contractors involved in the oil and gas industry.
To enhance the credibility of our eorts, we selected par-
ticular organizations that were among the industry lead-
ers in oil and gas projects (a brief listing is provided in
the Acknowledgment). All interviews were conducted
in face-to-face meetings between the author and the
industry professionals.
We noted a common belief held within the industry;
namely, that a supplier will not be able to produce a par-
ticular item within appropriate quality levels on or be-
fore a specied delivery date. As a result, owner rms
get on their supplier from day one. In truth, expedit-
ing begins on the initial day of a project!
Another common view realized from our interviews is
that a project will never be completed on time, given that
organizations are far too optimistic. In an eort to ob-
tain important contracts, vendor rms oversell their
capabilities. Further, owner rms and suppliers seem
to compete in a world of continual bickering. Owner
rms claim that suppliers are unreliable; suppliers per-
ceive that the manner in which bids are evaluated con-
tributes to the dispute-oriented process.
Granted, this type of relationship is not assumed to
occur in each and every project undertaken in the oil
and gas industry. Nonetheless, the fact that it does occur
with some regularity is cause for alarm.
A further negative ramication of current expediting
operations is the mistrust that can grow between owner
and supplier. Rose [15] claimed that there exists an in-
verse relationship between cost and trust on all types
of construction projects. Given that projects in the oil
and gas industry are usually quite costly, there seems
to be substantial basis for mistrust in this project man-
agement relationship.
The negative type of project expediting relationship
described above leads to some critical deciencies. Silver
[13] reported that the expediting function can be quite
costly. Large sums are spent to guarantee timely project
completion. In order to receive required goods, some
owner rms may be forced to pay for premium-priced
shipping (e.g. air transport, as opposed to truck or rail).
Ironically, excessive expediting may not increase pro-
ject completion time. If disputes arise, these could drag
out the project indenitely. Other unfavorable aspects
include the excessive managerial intervention required
to solve disputes. Clearly, if these disputes did not exist,
then precious time could be spent in more productive
pursuits.
Expediting can cause quality problems. If a particular
supplier is not able to meet a schedule and an unresolv-
able dispute entails, an owner rm may be forced to rely
on an alternative source. Quality may suer with the
rather short completion deadlines given to the substitute
source. Further, this source may produce the required
goods on an overtime production basis, thereby increas-
ing overall costs.
Disputes in oil and gas projects, if unresolved, jeop-
ardize the entire project. Consequently, it would be ben-
ecial to all parties involved if one could nd ways of
overcoming the dispute-oriented nature of project
expecting. We discuss some suggestions in the following
section.
3. Process improvement suggestions
One clear suggestion arising from our interviews for
improving the expediting process is to involve more
teamwork in the project. This could involve ameliorated
teamwork within, say, the representatives of the owner
rm, or between members of the owner and supplier
rms. The example of the Texas Department of Critical
Justice alluded to earlier oers a prime illustration of the
eectiveness of the teamwork concept in a project man-
agement environment.
Obviously, instilling teamwork within a project man-
agement is not simply a matter of stating, lets all work
together on this particular aspect of the project. Truly,
it is easier said than done. Moreover, certain behavioral
styles on the part of project participants may lead to en-
hanced growth within the levels of teamwork; on the
other hand, there exist traits held by those in a project
management situation that may diminish the intensity
of teamwork. Using the results of interviews with con-
struction practitioners, Nicolini [16] examined the broad
idea of project chemistry. The author suggested a theo-
retical framework aimed at identifying specic external
and project factors critical to teamwork success. In or-
der to test the degree to which inuence style, a key
behavioral trait, aected project performance, Shim
and Lee [17] collected data from 83 ongoing projects
in such industries as electronics/telecommunication,
chemical, and machinery. They determined that,
although dierent leaders made use of particular inu-
ence tactics, the inuence styles adopted by project lead-
ers did shape overall performance. In truth, getting
supplier and owner rms in the oil and gas industry to
participate in a cooperative teamwork relationship has
the potential to drastically reduce the number and dura-
tion of disputes. For some time, various academic refer-
ences (e.g. Meredith and Mantel, Jr. [18] and Nicholas
[19]) have advocated the use of teamwork in project
management. In particular, Nicholas reference (p.
201) includes a well-designed representation of project
teamwork.
K.A. Willoughby / International Journal of Project Management 23 (2005) 231236 233
There would appear to be at least three benets to
creating a more cooperative, teamwork-oriented situa-
tion in projects. In particular, such an approach would
allow problems to brought out into the open. By involv-
ing teamwork on both sides of the project, the notion of
hidden agendas can be laid to rest. Secondly, team-
work would permit dierent viewpoints and interests
to be taken into consideration. Without a teamwork
concept, the dominant player in a particular scenario
may be the one to call the shots. Teamwork may help
to ensure that various issues of multi-faceted problems
are considered. Finally, teamwork enables rms to de-
vise an action plan as well as assign tasks and dates
for implementation. If rms work in isolation, it can
then be quite dicult and time-consuming to assign
tasks between them. By remaining in close contact, it
is much easier to get the ball rolling through various
stages of a project.
A second suggestion for process improvement is to
break a project down into easily denable stages. In
other words, realistic and meaningful milestones are
established for the duration of a project. These mile-
stones have the eect of creating a workable environ-
ment within which owners and suppliers can operate.
Vague stages result in uncertainty, which is never pleas-
ant from a project standpoint.
Leech and Turner [20] indicate some precautions that
need to be taken when setting these milestones for pro-
ject performance. A breakdown that is not suciently
detailed results in the obscuring of important activities.
The overspending of both time and money may not be
pinpointed. This lack of detail will frustrate all eorts
to predict and closely monitor project costs and dura-
tion. On the other hand, a breakdown that is too de-
tailed is clearly sub-optimal. One may spend precious
time and money monitoring short and low-cost activi-
ties. In eect, a too-detailed breakdown may not provide
valuable information.
Using more concrete terms when establishing project
contracts is another approach that may improve project
performance and assist the expediting operation. Exam-
ples could include establishing clear conditions with re-
spect to what occurs in the event that a party fails to
perform as desired (the price of non-conformance),
providing estimated maximum task durations (so early
warning of problems is detected), and supplying clear,
detailed performance measures (project deliverables).
Individually and collectively, these would have the eect
of removing vague items and providing both parties
with adequate clarication of project requirements.
Another suggestion for process improvement is to use
a project neutral in the relationship between owner
rm and supplier. Hartman [21] demonstrated that the
use of a facilitator or mediator can improve the creation
of the contract, thus getting both parties o to a run-
ning start.
A fth possible process improvement tactic is to set
up a Pre-Award Meeting in projects. Specically,
one of the large oil and gas rms we interviewed made
use of such a meeting to call together groups of suppliers
to examine various details of the particular project. This
helped to establish the understandable terms and easily-
denable stages that would be necessary to complete the
entire project. Any number of qualied rms may be in-
vited to the Pre-Award Meeting, although not every
one of the rms is guaranteed to win the right to work
on the project.
Strategic alliances could be used to avoid the problem
of costly time-consuming expediting activities. A repre-
sentative of one of the rms contacted in our interviews
indicated that such alliances can assist in all aspects of a
project. Expensive disputes and sub-par performance
are avoided since, in a major project, an owner rm
can immediately engage with one company rather than
spending valuable time meandering through relation-
ships with several companies for extended durations.
In essence, the owner and supplier rms are both able
to hit the ground running in a major project.
Morton [22] advocated the continuous appraisal of a
projects development to alleviate expediting complexi-
ties. Such appraisal involves communication, coordina-
tion, involvement and commitment. In a way, this
concept is connected to the teamwork notion illustrated
earlier. By actually remaining in close contact with ven-
dors, an owner rm can alert themselves to potential
dangers before they occur. Proactive, rather than reac-
tive, pursuits become the rule. In order to ensure an
organization of appropriate quality within contractual
delivery dates, it may be appropriate for the representa-
tives of an owner rm to physically visit the supplier.
Poor, unreliable suppliers can present a problem. If a
certain supplier habitually experiences diculty in pro-
ducing items of sucient quality on time, then other
parts of a project may be delayed. This contributes to
expediting problems. Obviously, one could improve this
process by simply not hiring these rogue vendors.
However, the implementation of such an approach
may not be so straightforward. For example, a construc-
tion rm operating in a strategic alliance with an owner
rm may feel pressure from the owner rm to include a
particular vendor in a project team. If this vendor is
somewhat unreliable, then project problems become
exacerbated. Further, the desire to have a high local
content in certain projects [13] may result in a rogue ven-
dor being selected for a specic part of a project.
Hartman[21] encouraged the implementation of a con-
tractor screening program, a set of criteria by which
potential contractors can be evaluated. In fact, one of
the companies interviewed for this study has created a
Vendor Qualication software program, VQUAL, to as-
sist in vendor selection. Nonetheless, the trouble remains
that this process of screening vendors may discriminate
against newer suppliers. They may not have had the expe-
rience necessary to score highly on the computer pro-
grams. Caught in somewhat of a catch-22 situation,
what can be done to assist these new vendors? Possible
ideas include allowing such rms to qualify for particular
projects involving minimal risk. Then, these suppliers can
gain appropriate experience. Where feasible, an addi-
tional tactic would be to permit new vendors to work in
tandem with a more experienced rm on a large project.
Another method of avoiding rogue vendors would be
to adopt a policy currently used by some of the rms
contacted in our study. Specically, these rms created
an organizational position known as Coordinator of
Vendor Development. Such an individual would be
charged with the task of developing techniques for qual-
ifying vendors and monitoring their performance.
In summary, the following approaches may be used
to improve the expediting process:
Teamwork.
Break a project into specic (and useful) milestones.
Use concrete terms when setting up project contracts.
Use a project neutral.
Initiate a Pre-Award Meeting.
Implement strategic alliances.
Continuous appraisal of a projects development.
Fail to hire rogue vendors.
Contractor screening.
Create a Coordinator of Vendor Development
position.
It is our claim that successful implementation of these
suggestions into the expediting operations of oil and gas
companies can lead to substantial benets. The opportu-
nities exist for circles of improvement. As both owner
and supplier rms practice these principles, the expedit-
ing function would no longer be dispute-oriented and
confrontational. As relationships continue to improve
and greater planning and foresight are utilized in opera-
tions, more time would be available to identify addi-
tional cost savings and eciency opportunities. Thus,
process improvement breeds continual improvement.
Managers and employees in both types of rms would
no longer be involved in costly disputes.
Improved quality (both in terms of nal product and
intermediate decision-making) could also result from
implementation of these principles. Overall project costs
would likely decrease as the number of disputes
diminishes.
Another benet of such process improvement ap-
proaches is that they could be applied to other areas in
oil and gas projects. Nowhere do we claim that these sug-
gestions can solely be used by the expediting function. In-
deed, the same needs for project neutrals, continuous
appraisal of development, and establishing concrete con-
tract terms exist throughout the entire supply chain.
Moreover, such procedures could even be applied outside
the oil and gas industry altogether (in those industries or
situations in which improvement is warranted). Since a
considerable number of undertakings in real-world oper-
ations can be termed projects, the potential arena of
application for such suggestions is quite enormous.
4. Concluding remarks
This paper has attempted to provide approaches for
improving the process of project expediting, specically
within the oil and gas industry. Potential suggestions fo-
cus on the need for expediting to become proactive, not
simply the reactive procedure that is often encountered
today. Techniques for improving this process go beyond
the bounds of the expediting function.
Expediting problems appear to occur due to two
main reasons: the mismanagement of expectations and
poor communication. Our suggestions address both of
these issues. In Fig. 1, we illustrate the alignment of
our approaches under either main reason. For example,
the proposition that rms set signicant milestones in
the creation of project contracts would lead to similar
expectations on both sides of the ownersupplier rela-
tionship. Further, when eective teamwork is involved,
the problems of poor communication are alleviated.
We feel that using a project neutral and initiating
-Specific milestones
-Concrete terms
-Eliminating rogue vendors
-Contractor screening
-Coordinator of Vendor
Development
-Project
Neutral
-Pre-Award
Meeting
-Team work
-Strategic alliances
-Continuous appraisal
Mismanagement of Expectations Poor Communication
Fig. 1. Process improvement approaches.
K.A. Willoughby / International Journal of Project Management 23 (2005) 231236 235
Pre-Award meetings link to both causes. Either ap-
proach would allow for better communication, as well
as an enhanced understanding of overall expectations,
between all project parties.
This paper is not suggesting that there be a change in
the relationships used in the project environment of oil
and gas companies. It is perhaps appropriate that we
continue to have owner rms dealing with vendors and
various subcontractors. Nonetheless, we suggest that
the process used to manage the project relationship be
altered. The suggestions oered in this paper indeed rep-
resent an important change in the mindset of all players
in project management.
In terms of future research opportunities, it would be
appropriate to apply this process improvement frame-
work in a variety of real-world projects. Specically,
an empirical study could document the quantitative
and qualitative benets realized when various compa-
nies create a Coordinator of Vendor Development
position, break projects into signicant milestones, or
use Pre-Award Meetings. Successful implementation
could ideally point the way to additional process
improvement methods.
Acknowledgments
Without implicating them, the author thanks indus-
try professionals from such rms as Optima Engineering
and Constructors, Shell Canada Resources Ltd., The
SNC Group, and Esso Resources Canada Ltd. These
personnel gave of their time and expertise in allowing
the author the opportunity to probe the day-to-day
operations of their expediting functions.
References
[1] Silver EA. The timing and sizing of procurement and logistics
actions in large-scale projects. Project Manage J 1987;18(2):8695.
[2] Thompson P, Perry J. World Bank funded projects, 19741988.
Engineering construction risks: SERC Report, British Institute of
Civil Engineering, 1992.
[3] Tabatabai-Gargari M, Elzerka HM. Integrated CAD/BKS
approach for automating preconstruction activities. J Construct
Eng Manage 1998;124(4):25762.
[4] Ngee L, Tiong RLK, Alum J. Automated approach to negotia-
tion of BOT contracts. J Comput Civil Eng 1997;11(2):1218.
[5] Cho A. Air Force base goes commercial. ENR 1999;242(21):345.
[6] Wright G. Virtual organization speeds Texas prison program.
Build Des Construct 1995;36(2):368.
[7] Kinsey J. A faster, leaner, supply chain: new uses of information
technology. Am J Agric Econom 2000;82(5):11239.
[8] Briggs P. Putting the supply chain in perspective. Can Transport
Logist 2000;103(4):16.
[9] Holland C, Lockett G, Blackman I. Planning for electronic data
interchange. Strategic Manage J 1992;13(7):53950.
[10] Schieier RL. Quick response helps retailers, vendors. PC Week
1990;7(13):10910.
[11] Moynihan JL. EDI helps improve payer, provider, and supplier
relationships. Healthcare Financ Manage 1995;49(3):66.
[12] Iskandar BY, Kurokawa S, LeBlanc LJ. Adoption of electronic
data interchange: the role of buyersupplier relationships. IEEE
Trans Eng Manage 2001;48(4):50517.
[13] Silver EA. Procurement and logistics for large-scale projects
in the oil and gas industry. Working Paper 01-86, Faculty of
Management, The University of Calgary, Calgary, AB,
Canada, 1986.
[14] Silver EA. Policy and procedural issues in procurement and
logistics for large-scale projects in the oil and gas industry. Project
Manage J 1987;18(1):5762.
[15] Rose G. Cost trust relationship. Presentation of Construction
Institute Taskforce Report at the Construction Productivity
Conference, Austin, TX, 1993.
[16] Nicolini D. In search of project chemistry. Construct Manage
Econom 2002;20(2):16777.
[17] Shim D, Lee M. Upward inuence styles of R&D project leaders.
IEEE Trans Eng Manage 2001;48(4):394413.
[18] Meredith JR, Mantel Jr SJ. Project management: a managerial
approach. New York: Wiley; 1985.
[19] Nicholas JM. Managing business & engineering projects: concepts
and implementation. Englewood Clis (NJ): Prentice-Hall; 1990.
[20] Leech DJ, Turner BT. Project management for prot. London:
Ellis Horwood; 1990.
[21] Hartman F. Reducing or eliminating construction claims: a new
contracting process (NCP). Project Manage J 1994;25(3):7.
[22] Morton GHA. A practical approach to project planning. Project
Manage Quart 1977;8(2):3540.
The success of international development projects, trust
and communication: an African perspective
Amadou Diallo, Denis Thuillier
*
Universite du Que bec a` Montre al (UQAM), E
cole des Sciences de la Gestion, De pt. Management et Technologie,

315 Ste Catherine Est, CP 6192, Montre al, Que ., Canada H3C 4R2
Received 18 June 2003; received in revised form 16 January 2004; accepted 8 October 2004
Abstract
Project success is strongly linked to communication and cooperation between stakeholders. This research explores the relation-
ship between trust and communication and tests the inuence of these factors upon project success and success criteria for interna-
tional development projects nanced by multilateral institutions in sub-Saharan Africa. The research analyses the coordinators
perceptions of project success, communication climate and interpersonal relationship between himself and his stakeholders (task
manager in the multilateral agency, national supervisor) and within the project team. Data were collected from questionnaires com-
pleted by project coordinators of development projects. The statistical analysis conrms that trust and communication between
players are proxy variables. Trust between the task manager and the coordinator is the key success factor, whereas team cohesion
is the second most important factor. Trust between the coordinator and his national supervisor does not play a prominent role,
although the task manager considers signicant local autonomy for the coordinator a prerequisite for funding a subsequent phase
when the project comes to an end.
Keywords: Project success; Criteria; Success factors; International development; Trust; Communication; Stakeholders; World bank; Project manager;
Africa
1. Introduction
Most international assistance provided to developing
countries is managed by projects. These projects are -
nanced by multilateral development agencies (the World
Bank, the European Union, the United Nations Devel-
opment Program, the Inter-American Development
Bank, the African Development Bank, the Asian Devel-
opment Bank, etc.), bilateral agencies (USAID, the
French Cooperation, CIDA) and the many organiza-
tions and departments of international cooperation
established by former colonial rulers and the industrial-
ized countries. Over the last few decades, international
aid programs were successful in helping developing
and emerging countries to make real progress in the
health system, in agriculture and in the education sys-
tem. However, it is clear that the eectiveness of eco-
nomic reform projects is still being debated. Poverty
reduction remains a long-term objective [15].
Our intention here is not, however, to assess the
validity of development policies implemented by multi-
lateral institutions [6,7]. The success of an international
development project its long-term impact on the pros-
perity of the local population surely depends on how
well it was prepared, and the policies behind its design
(a project is always a more or less appropriate response
to specic needs). However, international development
projects (ID projects) are identied, prepared and imple-
mented within a specic context [8]. There are many
doi:10.1016/j.ijproman.2004.10.002
*
Corresponding author. Tel.: +1 514 987 3000x7783.
E-mail address: thuillier.denis@uqam.ca (D. Thuillier).
PROJECT
MANAGEMENT
stakeholders, there are signicant political risks, and
there are demanding local constraints. The local mem-
bers of the project management unit may have limited
project management skills and the economic rationality
on which project management is based does not always
t with local values [9,10]. The stakeholders belong to
dierent cultures, and nally, to make matters worse,
those preparing and conducting transactions are sepa-
rated by huge distances. Given this context and the very
transaction-based nature of assistance projects, one
might wonder whether the quality of interpersonal rela-
tionships and of communication between key players are
not critical success factors, independently of the specic
knowledge, skills and competencies required. This is pre-
cisely the focus of this research, which aims to assess the
inuence of interpersonal relationships, trust and com-
munication, on the success of ID projects.
The paper is organised into ve parts. The rst sec-
tion provides a review of the project management liter-
ature on success, success criteria and success factors.
The second section presents the unique characteristics
of international development projects and the third sec-
tion begins with a review of the literature on the role
played by trust between individuals, within work groups
and within project teams. This discussion leads to the
formulation of the principal issues addressed in this re-
search. The fourth section covers the methodology and
the statistical strategy used and the nal section presents
statistical results and related comments. The conclusion
is a discussion of the research results and their implica-
tions for ID project management.
2. Project success, success criteria and success factors
There is an abundance of literature on project success,
success criteria and success factors for traditional pro-
jects. Success criteria correspond to the dimensions (or
measures) on which the success of the project is judged
whereas success factors are key variables that explain
the success of the project. In other words, they are in-
puts to the management system that lead directly or
indirectly to the success of a project [11].
Success can indeed be evaluated only when the crite-
ria are adequately dened. For the project manager, suc-
cess criteria generally correspond to the traditional
constraints: time, cost and compliance with the clients
terms of reference or quality. In construction and
engineering, success is evaluated primarily through the
assessment of the output quality, and through the eval-
uation of the project management performance whose
criteria are objective, well-accepted and measurable.
But as the eld of project management now includes sec-
tors like biotechnology, information technology, process
reengineering, institutional strengthening, social work,
etc., the clients agenda is dierent. Whether it is a pri-
vate rm or an institution, the client cannot evaluate
the success of its project without referring to the objec-
tives that governed the identication, the preparation
and the project design. Beyond time and costs, the raison
de tre of a project lies in its objectives as stated in the
logical framework: project management success does
not mean project success [12] although in the case of
construction projects they are closely linked [13]. Fur-
thermore, success criteria will dier or will be weighted
dierently, depending upon whether the evaluation is
performed by a project manager, a client, or one of
the key stakeholders. Each stakeholder perceives the
success according to criteria (and a hierarchy of the cri-
teria) that comply with its own agenda. There is no
absolute success or consistency in success apprecia-
tion over time: there is only perceived success [14
16]. Even when everybody agrees on a list of criteria,
determining the success rate still remains a rather dif-
cult task. Schedule and budget management may be as-
sessed through direct measures while quality
management may be assessed through pass or fail crite-
ria. However, the clients satisfaction is not objectively
measurable and the same applies to the knowledge or
the experience accumulated throughout the project, the
magnitude of organisational impacts, or of any other
intangible benets induced.
The success factors themselves have made the object
of several studies [1725]. Pinto and Slevin [17,19] sug-
gest that success is linked to exogenous and endogenous
factors. These factors include the control level (espe-
cially schedule and cost), the impact on the client, the
support of the general management of the organization,
communication, etc., but also less controllable factors
such as the environment, the political context, the com-
petence of the project manager, etc. The diversity of the
factors mentioned by the project management literature
is considerable: these depend on the scope, the nature
and the originality of the projects. However, one is
struck by the fact that research reported in the project
management literature only rarely examines the link be-
tween the success factors and the success criteria (or
dimensions). However, it is obvious that one factor will
explain one or more success criteria, but not all of them
[24,25].
The literature on success factors and success criteria
for international development projects is scarce and
the empirical research specically dedicated to manage-
ment of ID projects is even more rare. This lead us to
undertake a preliminary exploratory investigation of
the success criteria (dimensions) for ID projects in sub-
Saharan Africa and an investigation of the criteria hier-
archy each stakeholder uses in assessing project success
[26]. More specically, our goal was to understand how
project coordinators perceived the success of their pro-
ject and how they perceived the main stakeholders
assessment of project success. We focused on an analysis
238 A. Diallo, D. Thuillier / International Journal of Project Management 23 (2005) 237252
of perceived success (at least as it is perceived by the
coordinator who is the central stakeholder). We relied
on the coordinators understanding with, as a premise,
the commonly accepted principle that individuals act
(and therefore manage a project) according to their
own perceptions of reality and act based on their percep-
tion of how the most inuential stakeholders feel. The
results of this preliminary investigation showed that
coordinators of development projects assessed project
success only with two criteria: the management perfor-
mance (time, cost and quality) and the projects pro-
le: the visibility and/or the reputation earned by their
project. The project impact, which captures the perfor-
mance of the project with respect to its objectives as sta-
ted in the logical framework, was not a signicant
criteria.
1
3. The characteristics of ID projects
According to Youker [8] international development
projects are medium to large public projects and/or pro-
grams nanced by multilateral development banks, the
United Nations associated agencies, bilateral agencies,
non-governmental organizations and government
departments in developing countries. Like others, ID
projects deliver goods or services. Originally, most pro-
jects were hard projects like civil works, railroads,
power plants, etc., but the portfolio has changed to in-
clude an ever-increasing portion of soft projects in
education, health, human development, capacity build-
ing, etc.
ID projects are managed either by national project
management units acting with autonomy, or by teams
of nationals embedded into ministries, national depart-
ments, or institutions. The management of the project
can also be delegated (as often occurs in bilateral assis-
tance) to executing agencies that may be private compa-
nies (such as engineering or consulting rms), NGOs or
international cooperation departments within various
institutions (i.e. universities and colleges for projects in
education, or hospitals for health and nutrition
projects).
In fact, the project management unit of an ID project
only manages administrative processes (as is also the
case for classic projects). Within the framework of
multilateral agency guidelines, the project team is in-
volved in the procurement, organisation and control of
activities carried out by engineering rms, subcontrac-
tors, consultants, etc. Five stakeholders are directly in-
volved in processes in ID projects:
1. The national project coordinator (or project man-
ager), who is the person responsible for the day-
to-day management. He or she is in charge of the
operations and leads the project team.
2. The task manager located in the headquarters of the
multilateral development agency, who supervises
the projects implementation and makes sure that
the guidelines of the international institution are strictly
respected by the projects national management unit.
3. The national supervisor, who is the high-ranking civil
servant (a national department director or sometimes
the minister himself) to whom the national coordina-
tor reports.
4. The project team, which is under the coordinators
authority. The team is not exactly an external player
but no matter what its inuence, the coordinator can-
not function eectively without the project team.
5. The various rms (engineers, subcontractors, consul-
tants, etc.).
It may come as a surprise that the real client does not
appear on this list. In multilateral aid projects, the client
is usually the countrys residents or a sub-set thereof
called the beneciaries. The beneciaries, who may
sometimes participate in the project identication phase
(needs assessment), can rarely be eective as clients once
a project is in execution. This is due to the lack of rep-
resentative authorities or organisations, especially when
it comes to validating the quality of the project outputs.
There are exceptions. Some projects, like the Social
Funds are designed and managed under a so-called
participative approach. This aims to enhance the po-
sition of the beneciaries as real stakeholders. They re-
main, in spite of their success, limited to social
interventions [27].
International development projects follow transac-
tional processes that have been codied by the lending
institutions under guidelines in order to guarantee that
projects maintain rigor and transparency in how tasks
are performed and contracts awarded. For example, a
multilateral institution or its technical representative
(the task manager) will not intervene directly in the pro-
jects day-to-day management. However, he or she is up-
dated on each step of the project, and the coordinator
must ask the task manager for a no objection when
it comes to proceed with major transactions (terms of
references, short lists, contracts awards, etc.). The task
manager can reject the coordinators request but such
decision is not made without good reason. Generally,
a rejection means the project team has strayed too far
from guidelines or that the process itself includes an
activity that was inadequately planned or simply does
not conform to the project plan. When the task manager
does not grant his no-objection, the process must be re-
peated at the local level and face local constraints again
before the coordinator makes a second request for a
1
Diallo and Thuillier [26] discuss possible reasons for such
surprising result.
A. Diallo, D. Thuillier / International Journal of Project Management 23 (2005) 237252 239
no-objection. This will result in a delay that disrupts
the project schedule and carries all the related impacts.
The eectiveness of actors and, by extension, the suc-
cess of the project itself is therefore very dependent on
the quality of interpersonal relationships and communi-
cation between stakeholders. The purpose of this study
is to examine the quality of interpersonal relationships,
trust and communication between coordinators and
their task manager, between coordinators and their na-
tional supervisor, and within members of the project
team. The goal is to identify the soft factors that
can play a decisive role in the overall success of a pro-
ject, or explain performance according to dierent suc-
cess criteria.
4. Trust and communication between individuals and
within the project team
4.1. The work groups
A work group is a social system in which individuals
with specic but interdependent roles collectively share
responsibility for the production of goods or services
[2730]. A project team is a work group, but the reverse
is not true. A project team is set up to achieve specic
objectives under constraints and within a given period
of time. Moreover, the entire group of actors in ID pro-
jects (coordinator, project team, task manager and na-
tional supervisor) also meets this denition, even if the
task manager and the national supervisor are more
functional than operational and could therefore be con-
sidered more as stakeholders than full members of the
team. This is a semi-autonomous team (control is exer-
cised by the coordinator and team activities are regu-
lated by the task manager) with only one key
member, the task manager, occasionally working lo-
cally. The literature on project teams and on work
groups in general should provide enough theoretical
background to grasp the nature of the problem pre-
sented by interpersonal relationships and communica-
tion, their impact on project success and on success
criteria.
There is no shortage of literature on work groups. The
subject has been examined by social psychologists or
organisational psychologists and according to dierent
schools (human relations, system dynamics, and
behaviourism). The empirical literature is abundant.
The concept of team originated in the 1930s in the Uni-
ted States. It proved of great economic value, and was
developed mostly with diverse but complementary ap-
proaches. Once the mechanism of work groups had been
understood, research focused on group productivity or
eectiveness. Management literature naturally took
over, gradually putting the accent on groups of manag-
ers or other professionals (and on research and develop-
ment teams). Comprehensive literature reviews can be
found in [3133].
4.2. The project team
Literature on project teams is less wide-ranging, of
uneven quality, and remains quite undierentiated.
One is obliged to cull work that distinctly resembles a
guru of the month approach (the expression from
[34]), the kind found in some professional publications.
A more scientic approach does, however, exist. It fo-
cuses on processes and attempts to:
identify the performance factors and the methods
used to speed up the team building or team devel-
opment process, in order for the group to quickly
achieve a high level of eectiveness [3540];
understand the role of the project manager, the kind
of person who is suitable for this position, the charac-
teristics of leadership and their eect on the teams
eectiveness and on project success [4143].
This literature identies many factors that explain
team performance. It is impossible to thoroughly sum-
marize the research, particularly since it includes
descriptive factors (such as the teams structure, organi-
zation or diversity), support factors (competencies, com-
munication) and more abstract factors that are dicult
to grasp, such as cooperation, team members commit-
ment or empowerment. These are latent variables or
complex constructs (concepts) of which only manifesta-
tions may be observed. But constructs boundaries are
unclear and new constructs are built upon parts
that well accepted constructs have in common. All this
makes the emergence of fundamental explanatory fac-
tors especially challenging. The authors do not always
make a clear distinction between support and process
factors (team building or team development) and, in
any event, one inuences the other. Furthermore, the
residual inuence of time has received little direct atten-
tion; in other words, the inuence that would be inde-
pendent of its implicit role in the processes mentioned
above [44]. Guzzo and Dickson [33] in a attempt to built
a taxonomy of team performance factors suggest that
factors may be classied into three categories:
organisational design (autonomy, interdependence,
denition of responsibilities),
contextual or support variables (such as competencies
or communication),
mediating variables such as cooperation, mutual aid
or cohesion.
But each variable in a given cluster also clearly de-
pends on other factors. The level of team cooperation
depends on factors such as the teams composition,
members status, or their shared history. Autonomy on
the other hand is related to how professional the mem-
bers are. It will increase with the level of each members
knowledge and competence (contextual variables) and it
will depend on trust among team members (see below).
The interdependence required is a function of the com-
plexity of the teams tasks and, last but not least, the
maturity of the team has an eect on cooperation, mu-
tual aid and communication. In spite of many excellent
attempts, a truly thorough listing of interpersonal fac-
tors of team eectiveness and of project success still re-
mains to be established.
4.3. Trust, communication, and the research questions
The concept of trust is not a new one. However it is
worth mentioning that it has only recently been the fo-
cus of research in project management [45,46]. Each
member of a team begins a project with some concerns
about what they can expect of their colleagues, carries
expectations concerning their work relationships and,
due to his or her own individual nature or circum-
stances, is inclined to behave in certain ways. When
team members meet for the rst time, trust, communica-
tion and cooperation within the team and between the
major stakeholders are not taken for granted. But with-
out trust, communication and cooperation, a team can-
not be eective in accomplishing goals.
Trust is a psychological state in which Individual A,
given a specic situation, takes the risk of assuming that
Individual Bs rst reex will be to adopt a behaviour
(judgement, a position or action) that meets Individual
As expectations. Trust takes the form of a wager on
the behaviour of another. A certain amount of risk is ac-
cepted (i.e. individual A is somewhat vulnerable . . .) in
exchange for a reduction in the transaction costs associ-
ated with the management of the situation [4752]. The
concept of trust is integral to what have become Blaus
classic theories of social exchange [53], and to the trans-
action costs theory developed by Coase [54] and Wil-
liamson [55,56]. Beccera and Gupta [57] have made an
attempt to integrate the concept of trust into these con-
ceptual frameworks.
Trust between individuals is either aect-based (emo-
tional) or knowledge-based (the result of a cognitive
process) and both can interfere [5860]. Aect-based
trust could be considered in certain extent as being sim-
ilar to trust at rst sight while knowledge-based trust
is built steadily on ongoing relations between the parties
over time. Knowledge-based trust emerges through
communication (particularly professional communica-
tion) in which each player implicitly reveals to the other
his or her values, expertise, integrity, consistency, loy-
alty, sense of justice, etc. [50,6367]. A perception of
the others trustworthiness develops over time, uncer-
tainty over basic issues gradually disappears, and a sense
of trust becomes established. Trust (of any kind) speeds
up negotiation processes and in most cases, cuts transac-
tion costs. Trust is a prerequisite for autonomy (hence
the denition of trust; if you trust me, you will let me
act independently). Trust is necessary for cooperation,
which is in turn the social lubricant that allows autono-
mous but interdependent group members (see the deni-
tion of the project team above) to achieve common goals
harmoniously [61,62]. Technically dependent members
of a group must cooperate, because cooperation is an
indispensable part of the relational dependence required
for their group to be truly functional. It is also likely
that, given the above denition, trust and cooperation
among group members become more important as their
tasks require more interdependence in their working
relationships. Trust may be considered an independent
variable when it is aect-based and a dependent variable
when it is knowledge-based. A minimum of trust is
essential because fair communication cannot occur if
information exchange is clouded with doubts over mo-
tives. In the analysis which follows, we take trust to be
an independent variable that generates autonomy, coop-
eration and, as a result, eectiveness. But we will also
consider trust a dependent variable that can be ex-
plained by the quality of communication between
stakeholders.
As it was the case for ID projects success, success cri-
teria and success factors, we were unable to nd research
papers on ID project teams and interpersonal relation-
ships between main ID projects stakeholders. Therefore,
building on the literature presented in the above sec-
tions, we are interested in:
(a) The main characteristics of interpersonal relation-
ships between the coordinator of an ID project
and the task manager, between the coordinator
and his national supervisor, and among members
of the project team.
(b) The inuence each of these characteristics may have
on the quality of communication between the coor-
dinator and the project stakeholders.
(c) The inuence of communication and interpersonal
relationships between stakeholders on ID projects
performance, both in terms of success and of suc-
cess criteria.
This is an exploratory investigation. However, it is
our hope to conrm through statistical analysis that:
Assertion 1:
communication, trust and autonomy are virtually inter-
changeable, i.e. they are almost perfectly correlated.
Assertion 2:
trust and autonomy accorded by one actor to another is
the result of communication experiences; i.e. it develops
over time.
Assertion 3:
in ID projects, trust is a signicant success factor
(although not the only one), both the trust between the
project coordinator and his task manager and the trust
between the coordinator and his national supervisor.
Assertion 4:
Trust within the project team (or any other proxy vari-
able) is strongly associated with the success of the project
and the various success criteria of ID projects.
5. Methodology
Diallo and Thuillier [26] provide a description of the
surveys database. We collected data by way of question-
naires delivered by mail. We received 93 completed
questionnaires from about 600 sent out to African pro-
ject coordinators (350 were sent to Francophones, 250
to Anglophones). The apparent response rate, modest
as it was (15%), is satisfactory considering that a number
of questionnaires were sent to postal boxes in institu-
tions where such mail does not necessarily reach the in-
tended recipient. The postmarks on responses indicated
that the questionnaires came from at least 26 countries
most of them south of Sahara. Francophone and Anglo-
phone response rates were proportional to linguistic
populations in sub-Saharan Africa. Diallo and Thuillier
[26] provide a discussion of possible biases arising from
the response rate and non-respondents, the geographical
representativeness of the sample, the distribution of
projects by sector and systematic bias due to socially
desirable responses. As a result of this discussion,
generalisation of ndings to the overall population of
projects in sub-Saharan Africa is considered reasonable.
However, we will elaborate more specically on the
robustness of empirical estimates in Section 6. Appendix
A presents the projects main characteristics and a
description of project coordinators status and income.
The research uses data from nine of the thirteen sec-
tions in the questionnaire. Listed in the order they ap-
peared in the questionnaire, these sections provide
information on:
General project description, such as the sector, dura-
tion, amount of funding awarded and respective con-
tributions of the principal donor agencies.
The global judgement of the coordinator on the suc-
cess of his project as he perceives it.
The coordinators appreciation of statements (items)
that make reference to success criteria (such as time,
budget, reputation and the beneciaries satisfaction).
The factorial analysis performed in the above men-
tioned research provided three macro-dimensions,
(or coordinators success criteria. . .) to be discussed
later.
The coordinators opinion on statements concerning
the nature and quality of interpersonal relationships,
trust and communication between:
the coordinator and the task manager in the mul-
tilateral development agency,
the coordinator and his national supervisor,
the members of the project team (see Appendix B).
Information on specic contextual events, including
the countrys suspension
2
by donors and stakeholder
turnover.
The coordinators opinion on how the stakeholders
judge the success of his project, in particular the task
manager in the international development institution,
his national supervisor and the members of the pro-
ject team.
Socio-demographic information on the coordinators
age, sex, professional training, previous project man-
agement experience, professional status and wages.
Information that refers to a subjective judgement was
rated on a Likert scale from 1 to 5 (i.e. from strongly
disagree to strongly agree) or on a binary scale
(0,1) when it was required to answer without any subjec-
tivity. It was mentioned above that the questionnaire in-
cluded a series of statements about the projects success
criteria. We will not review here the statements in detail
or the factorial analysis of these elementary dimensions
(see [26]). We would just say that the factor analysis re-
vealed three principal components or macro dimen-
sions (projects success criteria): MANAGEMENT,
PROFILE and IMPACT. Nominal logistic regression
show that only the MANAGEMENT
3
and PROFILE
criteria explained the coordinators judgement of the
projects success, at least as it was perceived by the coor-
dinator according to his or her response to the rst
assertion in the questionnaire:
My project is a success (SUCCESS).
Assertions describing the relationship between
stakeholders were tested for consistency by calculating
Cronbachs alpha for the total sample and for random
sub-groups. The results were satisfactory, always
exceeding 0.80 in those groups of statements that were
nally retained. For each of the research questions (a,
b and c) listed at the end of Section 4, the analysis
proceeded with a simple and direct statistical strategy:
2
Multilateral development agencies suspend disbursements when
debt repayments are overdue without just cause or when the local
political situation is beyond control.
3
Drawing on nominal regression it appears that the MANAGE-
MENT criteria was the most signicant (p < 0.000). Visibility (PRO-
FILE) came second (p < 0.002) and, surprisingly, as already mentioned
in note 1 Section 2, the IMPACT criteria did not appear to be
signicant (p < 0.264). [26] includes a discussion of this last result.
Factor analysis with the statements (Appendix B) in
order to identify meaningful latent variables or con-
structs that drive interpersonal relations between
stakeholders and within the project team.
Nominal regression
4
with the communication
between stakeholders and within the team as the
dependent variable and the components of the inter-
personal relations as factors.
Nominal regression with the success criteria (MAN-
AGEMENT, PROFILE, IMPACT) and the success
(SUCCESS) as dependent variables and the quality
of communication between stakeholders and within
the team as factor.
The same as above but with the components of inter-
personal relationship as factors of stakeholder com-
munication and team communication.
The most signicant results are discussed in what fol-
lows. For better understanding please note that TM
stands for task manager, CR for project coordinator,
NS for national supervisor of the coordinator and TE
for project team. Appendix B includes a complete
description of the questions the coordinators were asked
to respond to.
6. Results of the empirical (statistical) analysis
6.1. Components of relationships between stakeholders
6.1.1. The coordinatortask manager interpersonal
relationship
Optimization after orthogonal rotation revealed
three components. Co-ordinates lower than 0.5 after
rotation were removed in order to improve the emer-
gence of the constructs, whose meanings are discussed
later:
Component 1: TM AUTONOMY, TM TRUST, TM
RELIABILITY, TM RESPECT, TM VALUES, TM
UNDERSTANDING
This proved to be a very signicant and consistent
component. It demonstrates the quality of relation-
ships and, after rotation, explains 37% of the common
variance in responses to the statements in the ques-
tionnaire. The combination of these particular charac-
teristics is not only intuitively appealing but it is also
supported by the specic literature (see Section 3).
Non-parametric correlations show that trust and
autonomy are very highly correlated in our population
(a Kendalls s of 0.652), and the same is true of trust
and reliability between these two stakeholders (a Ken-
dalls s of 0.584). These variables are virtually inter-
changeable. We call this component TM TRUST
(for trust between the coordinator and the task
manager).
Component 2: TM AGE, CR VISITS TM, TM
FAMILY
The coordinators and their task managers are
approximately the same age. Coordinators visit their
task managers in the headquarters of the multilateral
funding institution, and also visit their task managers
at home (although this does not apply for each case)
during work-related visits. The variance explained by
this component, which we label CR VISITS TM, repre-
sents 17% of the common variance.
Component 3: TM VISITS CR, TM IN MY HOME
Component 3 is the reciprocal of component 2. The
task managers supervise project activities by regularly
visiting the project team and local ocials. They also
make social visits to the home of the project coordina-
tors, as is the customary in Africa. This component,
which we call TM VISITS CR, explains 13% of the com-
mon variance.
6.1.2. The coordinatornational supervisor relationship
In this case more statements were tested and retained
for analysis since we were trying to understand the inu-
ence of phenomena such as actors having known each
other as students (which may have given them more
interests in common than just belonging to the same
generation) or having a language in common other than
French or English, which might indicate that they be-
long to the same ethnic group (see Appendix B). Optimi-
zation after orthogonal rotation again produced three
distinct components.
Component 1: NS RELIABILITY, NS TRUST, NS
AUTONOMY, NS INFORMED, CR VISITS NS, NS
VALUES, NS VISITS CR
Just as in the relationship with the task manager, this
component exerts a strong inuence. Again we found a
correlation between trust and autonomy (with a Ken-
dalls s of 0.578). Professional visits, both of coordina-
tors to meet their national supervisors and vice versa,
show up in the same component. In fact, this variable
captured frequent contacts between local actors. Some-
times visits are informal or even impromptu (coordinators
4
Statistical analysis of Likert scales data is not tractable with
classical multivariate regression owing to the violation of usual
assumptions. Multiple discriminant analysis or multinomial logistic
regression stand as accepted alternatives for such surveys. These
techniques are common in business research, marketing, psychology or
medical sciences. Logistic regression does not require a normally
distributed dependant variable, linearity between dependent and
independents, homoscedasticity, independents to be intervals, etc.
However, logistic regression is sensitive to multicollinearity and sample
size (as maximum likelihood estimation implies asymptotic normality).
Reliability of our estimates may be altered by correlation between
variables and by the limited number of cases in our sample for each
combination of independents. For this reason, we tested robustness on
random sub samples to assess the stability of estimations before
jumping to premature conclusions.
oces are never far from the supervising departments).
It therefore makes sense that these variables become
grouped into the same component. Given this compo-
nents similarity to the rst component revealed in the
analysis of task manager-coordinator relationship, we
name it NS TRUST. It explains 30% of the common
variance.
Component 2: STUDIES, NS AGE, NS IN MY
HOME, NS FAMILY
This is a homogeneous group of variables that can
be understood in terms of friendships between the
coordinators and the national supervisor. They share
common backgrounds. Their relationship goes beyond
professional ties. The phenomenon of actors having
known each other as students in the same school
(STUDIES)
5
and the fact that they both socialise at
the family level lead us to call this component NS
FRIENDSHIP. It accounted for 14% of the common
variance.
Component 3: NS VALUES, NS RESPECT
The variable LANGUAGE was not included in this
construct because it weighted only 0.481, hence slightly
under the limit of 0.500 (which is arbitrary. . .). There
is clearly a group values-respect-language. We believe
that this construct captures the fact that both the coor-
dinator and his or her national supervisor belong to the
same cultural community. Since values and culture (and
language) are closely related, this component is named
hereafter NS CULTURE. It accounted for 12% of com-
mon variance.
6.1.3. Relationships in the project team
Members of a project team are generally appointed
by the local government, but coordinators may be
given the opportunity to participate in the selection
process. Most of the team members are civil servants
or civil servants seconded to the project but sometimes
contractuals from the private sector are hired for the
duration of the project. Statements in the question-
naire therefore took this into account. They also
included assertions dealing with interpersonal relation-
ships between team members (see Appendix B).
Component 1: NO ABSENTEEISM, ATMO-
SPHERE, NO RIVALRIES, MOTIVATION, TE
AUTONOMY, MUTUAL AID
This component is homogeneous and very strongly
weighted by the rst four variables. The component,
which we label TE COHESION, explains 29% of the
common variance.
Component 2: KNOW EACH OTHER, CR
KNOWS THEM
These statements reveal the background or the com-
mon heritage shared by team members. We call this con-
struct TE BACKGROUND. It explains 16% of the
common variance.
Component 3: TE FAMILY, TE SOLIDARITY
This factor shows the presence of relationships
between team members that went beyond professional
connections. They have personal relationships that
include knowing each others families and providing
assistance to each other. We name the construct
TE LINKS. It accounts for 15% of common variance.
Component 4: CHOICE, CONTRACTUAL
The coordinator may have chosen individuals in the
team, so factor analysis associates this with the presence
of contractual team members in the project implementa-
tion unit. We label the component TE CHOICE. It ex-
plains 12% of the common variance.
6.2. The communication and the interpersonal
relationships components
Communication was found to be characterised by
how well information circulated among the actors, be-
tween the coordinator and the stakeholders, as well as
among the members of the project team. Since the coor-
dinator is the team leader and also belongs to it as a
member, we did not consider the communication be-
tween them. The project team is not an exogenous stake-
holder from the coordinators point of view; the
coordinator leads the team and carries responsibility
for what it does. Therefore his or her judgment vis-a`-
vis the team is biased. On the other hand, the coordina-
tor is perfectly capable of judging how well information
circulates within the team without the risk of any such
bias.
By making communication variables (TM COMM,
NS COMM, TE COMM) between stakeholders
dependent, we assumed that it was explained a priori
by the characteristics of the relationship, in particular
by trust. We have also seen that the opposite may be
true; trust can be established through professional
communication (see Section 4.2). Non-parametric tests
were conducted to discern any signicant changes in
trust (and in communication) between the coordinator
and the two principal stakeholders that might have
occurred over time.
6
The level of trust between actors
was not found to have changed; a result that supports
the hypothesis that trust between actors is more aect-
5
African francophones have an expression to describe the shared
background resulting from completing part or all of their studies
together; they call the person their promotionnaire, which refers to
being of the same group of scholars.
6
Taking care to select only those cases where neither the task
manager nor the national supervisor changed since the beginning of
the project. The questionnaire included contextual variables: see
Section 4.
based than founded in communication. In this con-
text, it is reasonable to think of trust more as a var-
iable that can explain communication than the
reverse.
7
Nominal logistic regressions were conducted to nd
relationships between the quality of communication
and interpersonal relationship components identied in
Section 4.1. Nominal regression requires a minimum
of respondents in the classes of variables retained. We
nally re-coded the quality of communication (1, 2, 3)
before proceeding. Score 3 represented very good com-
munication; score 2, satisfactory communication and
score 1 was reserved for a communication failure.
As usual the score 3 (i.e. for the dependent variable
the coordinator strongly agrees that his communication
with his or her stakeholder is very good) acts as the
omitted score and thus acts as a reference in the statisti-
cal analysis.
8
Results are seen in Table 1.
These results lead to the following observations:
1. The pseudo R
2
are high. The degree of correlation
between trust and communication leads us to con-
clude that they are proxy variables (proving Assertion
1). Here we are assuming that trust is a factor of good
communication, but the literature suggests that
knowledge-based trust results from communication
(Assertion 2, to be tested below).
2. The overall quality of communication between the coor-
dinator and his or her task manager (TM COMM) is
explained primarily by the task managers trust in the
coordinator (TMTRUST) and (although to a lesser
extent) byhowfrequentlythe taskmanager comes tovisit
the project implementation unit (TM VISITS CR). The
importance of TMTRUSTconrms that it is adetermin-
ing factor, but the coordinators visits to the oces of the
funding institution (CR VISITS TM) had no signicant
eect on the quality of communication.
3. The same can be said for the quality of communica-
tion between coordinators and their national supervi-
sor (NS COMM). The strength of this link is even
stronger than that with the task manager, although
this does not appear in Table 1 because we only cal-
culated the probability of the null hypothesis to three
decimal places. It is interesting to note that a good
friendship (NS FRIENDSHIP) excludes the possibil-
ity of a complete lack of communication (31 is sig-
nicant). Nevertheless the fact that a coordinator
and his or her national supervisor are good friends
and are approximately the same age does not auto-
matically imply that they communicate very well (3
2 is non signicant). Finally, belonging to the same
cultural community (NS CULTURE) does not
appear to have a signicant eect on communication.
Table 1
Hierarchy of communication factors between stakeholders
Coordinator Task manager
TM COMM
Coordinator National
supervisor NS COMM
Project team
TE COMM
n = 86 n = 83 n = 86
Pseudo R
2
(Cox and Snell) 1 Global 2 1 Global 2 1 Global 2
0.649 0.676 0.625
TM TRUST 0.000 0.000 0.000
CR VISITS TM ns ns ns
TM VISITS CR 0.001 0.001 0.035
NS TRUST 0.000 0.000 0.000
NS FRIENDSHIP 0.037 0.020 ns
NS CULTURE ns ns ns
TE COHESION 0.000 0.000 0.000
TE BACKGROUND ns ns ns
TE LINKS ns ns ns
TE CHOICE ns ns ns
NB: Figures correspond to the probability of the null hypothesis. The lower the probability (particularly when under 0.05), the stronger the
components inuence on communication.
ns: non signicant.
7
However we were able to show that the statements My task
manager has condence in me and My national supervisor has
condence in me are strongly linked to We have common values
and We have a relationship of mutual respect. Hence recognizing
anothers values requires the passage of time and communication. We
could therefore conclude that knowledge-based trust plays a part in
total trust. It is very possible that our datas basic unit for the variable
time, a year, is too long to capture the establishment dynamic of
knowledge-based trust through communication, a phenomenon that
would undoubtedly occur in the rst months of a project.
8
The distribution across groups 1, 2 and 3 is not, however,
homogeneous. Groups (1) that correspond to a lack of communication
between stakeholders are under-represented (about 20% of the total
population). It should be noted that it was the communication within
the team that was the least likely to be rated very good. This should
not come as a surprise; there are in eect many members on a team,
and it only takes one of them holding back information to erode the
quality of communication across the team.
4. The quality of communication within the project
team (TE COMM) appears to be linked only to cohe-
sion (TE COHESION), which conrms what we
already knew and justies any eorts needed to secure
team building at the outset of a project. We did not
specically introduce the concept of trust as a specic
statement when describing relationships within the
project team. Nevertheless, it is clear that there can
be no cohesion in a team without trust between its
members, and that cohesion is a good proxy variable
when trust is not explicitly specied.
6.3. Communication, project success and success criteria
Interpersonal factors explain the quality of communi-
cation between actors, and the quality of communica-
tion between actors determines some aspects of project
success, whether it is the projects success or some of
its criteria. We ran nominal logistic regressions to assess
the inuence of the quality of communication on success
or success criteria. The results are shown in Table 2.
The following observations can be made:
1. The project SUCCESS
In general terms, a statistically signicant link was
found between the success of the project and the quality
of communication between the coordinator and the task
manager. A slightly less signicant link was found be-
tween success and the quality of communication among
members of the project team. The quality of communi-
cation between coordinators and their national supervi-
sor does not appear a key factor. This is not surprising,
since the organisational context of aid projects is such
that the coordinatornational supervisor professional
relationship is more based on functional responsibilities
than operational concerns.
2. The MANAGEMENT criteria
The quality of communication between actors did
not have a signicant eect on the MANAGEMENT
criteria, but TM COMM and TE COMM were both
very close to the threshold of statistical signicance
in the extreme case (from 3 to 1). It is interesting to
note that communication would appear to more readily
explain project SUCCESS (see below) than the MAN-
AGEMENT criteria specically (although the coordi-
nator believes that), among the three criteria of
success (as drawn from the project coordinators under-
standing), MANAGEMENT is the one that best ex-
plains the success of the project (see note 3 Section
5). Communication between the coordinator and the
task manager should therefore explain the project
PROFILE variable, another important success criteria
as perceived by the coordinator. As we will see this
proves to be true.
3. The PROFILE criteria
TM COMM and, to a lesser extent, TE COMM are
linked to the projects visibility. This is understandable.
On the other hand, no signicant relationship was
found between project PROFILE and NS COMM,
which is surprising, considering the role that a hierar-
chy can play in the political amplication of project
achievements. But the VISIBILITY variable is made
up of an internal or national visibility and an exter-
nal visibility with respect to the donor agency (see
Section 6.1). Non-parametric correlations showed that
internal visibility is explained by the quality of commu-
nication with the task manager or the fact that the task
manager often visits the project, more than it is ex-
plained by the quality of communication with the na-
tional supervisor. Communication with the minister
or department director would therefore appear to have
little impact on the projects internal or overall visibil-
ity. Nevertheless it is true that if the quality of commu-
nication does not play a decisive role, this does not
mean that the quality of the relationship between the
coordinator and his or her national supervisor does
not have an eect on the PROFILE variable. The pos-
sibility to secure eventually additional funding for the
project (ADDFUND is one of the three components
of PROFILE) is closely linked to the climate of trust
and the correlative autonomy that the minister grants
the project coordinator and the support shown by the
minister for the coordinator and the project. The
Table 2
Communication, project success and the success criteria
SUCCESS MANAGEMENT PROFILE IMPACT
n = 77 n = 85 n = 85 n = 85
Pseudo R
2
(Cox and Snell) 0.279 0.133 0.341 0.307
1 Global 2 1 Global 2 1 Global 2 1 Global 2
TM COMM 0.003 0.002 0.567 0.106 0.198 0.448 0.000 0.000 0.139 0.092 0.096 (0.664)
NS COMM 0.175 0.331 0.260 0.167 0.276 0.147 0.533 0.797 0.906 0.161 0.000 0.001
TE COMM 0.046 0.083 0.103 0.109 0.214 0.441 0.031 0.074 0.306 0.005 0.009 0.186
NB: Figures correspond to the probability of a null hypothesis. The lower the probability (particularly when under 0.05), the stronger the
components success or success criteria.
non-parametric correlations clearly show that funding
of project subsequent phases is conditional upon coor-
dinator autonomy. Task managers give up when the
project coordinators face excessive control or pressure
from their local hierarchy.
4. The IMPACT criteria
Communication between actors is a signicant factor
of project IMPACT. This result is dicult to interpret,
given that these are medium- and long-term impacts.
IMPACT is made up of components
9
upon which the
quality of communication between actors would appear
to have little eect. We have some diculty explaining
this result.
6.4. The interpersonal relationships, the project success
and success criteria
Intuitively we know that the interpersonal relation-
ships between stakeholders have an inuence on the
projects ultimate success. This is clearly documented
in the literature (see Section 4). We conducted nominal
regressions of success criteria (MANAGEMENT, VIS-
IBILITY and IMPACT) and of the SUCCESS itself
10
on factors of the stakeholder-to-stakeholder relation-
ship, and retained only those factors that were signi-
cant in these regressions. Then we estimated a model
that only specied those signicant factors as explana-
tory variables for each success criteria and for the suc-
cess itself.
1. The MANAGEMENT criteria
Generally speaking, trust between the task manager
and the coordinator (TMTRUST) and team cohesion
(TE COHESION) are signicant factors of project man-
agement performance. A high level of trust between the
coordinator and the task manager makes a serious pro-
ject management failure unlikely (thus explaining pro-
ject success).
However, the more often the coordinator visits the
task manager or the funding agency headquarters, the
poorer the project management. Poor project manage-
ment (MANAGEMENT from 3 to 1) in particular is
very strongly associated with frequent coordinators vis-
its. One could expect the opposite to be true. It would
appear that the cause-and-eect link for visits must be
analysed dierently according to their meaning: visits
by the task manager, even though they did not have
a signicant eect on the MANAGEMENT variable,
have a benecial eect. It is worth noting that TM
VISITS CR explains communication between both
(see Section 6.3), while the coordinator could be visit-
ing the donor agency because the task manager called
a meeting to x a management problem. Hence the
phenomenon appears especially signicant when it in-
volves a critical management issue (from 3 to 1) and
not minor problems (from 3 to 2). Again, remember
that CR VISITS TM does not improve their communi-
cation, which is consistent with this result, see Section
6.3.
2. The PROFILE criteria
Generally speaking, the analysis shows that visits by
the task manager (TM VISITS CR), the task managers
trust in the coordinator (TM TRUST) and the national
supervisors trust (NS TRUST) have positive eects on
the project PROFILE The signicance of other vari-
ables is weak.
More specically, the task managers trust, frequent
visits to the project, and the national supervisors trust
in the coordinator make poor visibility unlikely, i.e. they
play a fundamental role in explaining a projects high
PROFILE. We found factors that explained successful
project management (see above). But it is interesting
to see the eect a national supervisors trust can have
on the surface of the project. Earlier we saw that
the national supervisors trust, like the coordinators
autonomy, is indispensable in securing subsequent fund-
ing; multilateral institutions are not fond of dealing with
situations that are complicated or clouded with local
power struggles.
Cultural anities between the coordinator and his or
her national supervisor appear to have a negative impact
on project PROFILE, and very close cultural ties be-
tween these actors have an even more important eect
on the probability of the projects relative visibility
(from 3 to 2). This result was not expected, and we have
not found a satisfactory explanation.
3. The IMPACT criteria
The IMPACT is explained by team cohesion, the na-
tional supervisors trust (local factors) and to a lesser ex-
tent by the task managers trust. However, the inuence
of interpersonal factors on IMPACT is not a direct one,
as IMPACT is not exactly an operational construct.
Some caution is required therefore in interpreting poten-
tial meanings.
4. The project SUCCESS
The projects success factors are: the team cohesion,
the task managers trust (TM TRUST) and the make-
up of the team (TE CHOICE), which has a negative ef-
fect. We did not expect that when coordinators partici-
pate in the selection of their collaborators and/or
project team, including the possibility to hire contrac-
tual employees (team members who are not civil ser-
vants), it would have a negative eect on project
success. This component aects project SUCCESS but
surprisingly is not a factor of any success criteria. We
9
IMPACT is a function of SUSTAIN (the project built institu-
tional capacity), IMPACT (the project has a visible impact on the
beneciaries) and BENSATIS (beneciaries are satised). See [26].
10
As in the previous section, we re-coded the dependent variables, or
SUCCESS and its criteria, on (1, 2, 3).
tested for causality between TE COHESION and TM
CHOICE, thinking that dierences in salary or behav-
iour between the two groups might lead to tensions or
conicts in the team, but no evidence was found. TM
CHOICE is not aecting the quality of communication
within the team, either. It is unlikely that the coordina-
tor would support hiring incompetent contractual
employees, even though we know that contractual
employees are sometimes not always hired only on the
basis of their competencies. This is therefore a phenom-
enon that cannot be explained at this time, given the
information in this database.
6.5. Summary
A number of results emerged as signicant. They are
summarised here in the same order as our research ques-
tions and/or assertions were presented at the end of Sec-
tion 4:
(a) Trust, which in this case is a construct made up of
elements such as trust stricto sensu, delegated
autonomy, and reliable behaviour, constitutes the
overriding factor in the coordinators relationships
with the task manager and the national supervi-
sor. Team cohesion (which presumes a climate
of trust) characterises relationships between team
members.
(b) Communication between the coordinator and his
or her task manager is closely linked to the trust
the task manager has in the coordinator, and to
the task managers visits to project members.
The ministers or national supervisors trust of
the coordinator is indispensable for good commu-
nication, and good communication will in turn
reinforce social links. The link between team cohe-
sion and the communication between its members
is a decisive factor. The empirical results conrm
Assertion 1 (trustcommunicationautonomy are
virtually interchangeable) but we were unable to
conrm Assertion 2 (see Section 4): with this data
it is in fact impossible to isolate the building of
trust over time in such a way that the key role
of communication as a factor of trust between
the coordinator and project stakeholders can be
conrmed.
(c) Project success factors are: good communication
between the coordinator and his or her task man-
ager and good communication among team mem-
bers. Communication between the coordinator and
the national supervisor does not appear to play a
signicant role. The relationship between project
management and the quality of communication
between actors (no matter which actors) does not
appear to be signicant in this regard. On the
other hand, the trust a task manager has in the
coordinator plays a larger role in project success,
on the quality of project management, and on pro-
ject visibility than does cohesion within the team.
We have shown that project prole depends on
the trust established between the coordinator and
the task manager, but trust between the coordina-
tor and the national supervisor is a must for an
eventual extension of a project. Task managers
in the multilateral agency appreciate a project that
is running smoothly. Too much intervention or
local power struggles in a project clearly result in
the donor pulling out. This conrms what can be
observed in actual international development pro-
jects. Cohesion in the project team, which cannot
occur without relationships of trust among its
members (established beforehand or over time),
remains the only soft factor that can make a
contribution (along with a trusting relationship
with the task manager) to the success of projects.
Pre-existing friendships established at college or
shared cultural backgrounds, phenomena that we
would have considered signicant, seem to have
little eect.
It is therefore the coordinatortask manager rela-
tionship that is decisive, and to a lesser extent, the
interpersonal relationships within the project team.
The authors of this research, who have a fair amount
of experience in ID project management, welcome
such conrmation. The sheer strength of the statistical
evidence is compelling and conrms Assertions 3 and
4 (see Section 4). This carries a number of ramica-
tions. In fact, it is not uncommon for a multilateral
institution to transfer a task manager to another re-
gion, interrupting the continuity of projects. Consider-
able damage can result if the new task manager and
the project coordinator are not able to quickly estab-
lish an adequate level of trust. The authors have seen
that such transfers can quickly terminate projects that
were working smoothly. We have also seen the oppo-
site; a radical revival of a project, particularly where
the relationship with the former task manager was
dicult.
Appropriate measures are not taken to create, consol-
idate or improve social cohesion or trust in the project
team. This nevertheless appears to be instrumental to
a projects success; nothing is possible without a well-
integrated team. Some institutions hold launching semi-
nars, but it would be worthwhile for them to take the
time and set aside the funds (which would not be inordi-
nate, particularly at the beginning) to create a climate of
trust within each new project team. It is clear that the
team is important enough to deserve more attention;
at least this is one of the conclusions suggested by the
empirical analysis.
6.5.1. The limitations of the results
The studys potential biases and limits were described
in Section 5. We do not believe that these issues aect
generalisation of our results. However, there was a spec-
ication bias when estimating parameter signicance in
our models. We limited the specication to interpersonal
relationships and communication variables, and we can-
not be certain that those factors explain close to 30% of
the success of ID projects, like the pseudo R
2
might lead
one to believe (see Table 3). The specication of other
variables (such as the age of the coordinator, which is
strongly related to the success of ID projects) could af-
fect our estimates and therefore the importance of some
relational and communication variables. However, the
goal was not to build a good predictive model of ID pro-
ject success but to establish a hierarchy of signicance
between variables. In this context, the specication bias
has little eect on our results.
11
7. Conclusion
We have tried to describe and assess the inuence of
dierent aspects of interpersonal relations between key
actors in order to explain the success of international
development projects in sub-Saharan Africa. The re-
search did not provided answers to all the questions
we raised, but our analysis has lead to some conclu-
sions that are well supported by the statistical evidence.
The ndings pertaining to the interpersonal relation-
ship-communication-success causality are in complete
accordance with what is known from the body of re-
search on work groups or project teams. Projects are
dynamic systems in which perceptions become real-
ity. They cannot be carried out eciently without
trust between key stakeholders. This is also consistent
with the legacy of the literature on group dynamics.
Trust and communication are inseparable, and in inter-
national development, they are critical factors of pro-
ject success. Research also shows that the climate
(atmosphere) within the project team is decisive, and
therefore, that making more eorts in team building
during the rst months of the project is recommended.
The launching seminars organized by the donor agen-
cies focus more on selling the new projects to the lo-
cal stakeholders rather than creating a good working
climate within the team. The specic project team man-
agement and project team building seminars should be
organized as soon as the project team is set up. The
relationship coordinatortask manager becomes funda-
mental (even more than the relationship coordinator
national supervisor or task managernational supervisor)
and the quality of this relationship is directly linked to
the numerous on-site work related visits made by the
task manager to the coordinator. Despite the progress
of electronic communication, the semi-virtual ID pro-
ject management teams cannot avoid the physical
contact and face-to-face communication. The on-site
meetings are especially the ones that help establish
trust. Multilateral donor agencies should assess regu-
larly the trust climate, project by project, between the
task manager and the coordinator. Because it would
be a loss to break a winning team, one must avoid
Table 3
The components of stakeholder interpersonal relationships as factors of the project success and success criteria
SUCCESS MANAGEMENT PROFILE IMPACT
n = 77 n = 85 n = 85 n = 85
Pseudo R
2
(Cox and Snell) 0.279 0. 204 0.403 0.307
1 Global 2 1 Global 2 1 Global 2 1 Global 2
TM TRUST 0.006 0.007 0.608 0.007 0.010 0. 036 0.010 0.018 0.109 0.042 0.100 0.097
CR VISITS TM (0.029) (0.075) (0.211)
TM VISITS CR 0.039 0.034 (0.998)
NS TRUST 0.225 0.457 0.425 0.036 0.087 0.162 0.295 0.013 0.010
NS FRIENDSHIP
NS CULTURE (0.122) (0.083) (0.050)
TE COHESION 0.053 0.069 0.078 0.280 0.052 (0.448) 0.150 0.308 0.228 0.058 0.068 (0.950)
TE BACKGROUND
TE LINKS
TE CHOICE (0.008) (0.023) (0.012)
NB: Figures correspond to the probability of the null hypothesis. The lower the probability (particularly when under 0.05), the stronger the
components inuence on success or success criteria.
11
Furthermore, independent of the fact that the models are
incomplete, the limited number of cases by group (once recoded with
1, 2, 3) and the unequal distribution of cases among the three groups
could have had an impact on the accuracy of the estimates when three
or more variables were introduced. We therefore recalculated the
estimates in Table 3 with ten random sub-samples each representing
two-thirds of the total population. Even though there was some
instability among the less important variables, the overall estimates
regularly reproduced the hierarchy of signicance shown in Table 3.
This makes us believe that what we have learned would appear to be
valid for the entire population of development projects funded by the
multilateral system in sub-Saharan Africa.
transferring the task managers who have already estab-
lished a relationship based on mutual trust with their
coordinators.
The study does not come to any conclusions of a com-
parative nature, and does not reveal behaviours specic
to African managers as compared to Europeans or North
Americans. This was not our goal. This research could be
extended to Central and Latin America, Central Europe,
Asia and Indonesia, where multilateral development
agencies and bilateral organisations fund numerous
development projects. We plan on pursuing this further,
since databases are currently being assembled on these
projects. A transcultural analysis of the empirical results
from a larger survey would allow us to conrmthe results
from the African data and perhaps even to discover cul-
tural dierences in the importance of interpersonal and
communication factors.
Acknowledgements
The authors would like to thank the company SE-
TYM International Inc. (Montreal, Quebec, Canada)
for oering the use of its database of project managers,
coordinators and directors of projects nanced by inter-
national organizations in Africa.
Appendix B. Statements describing relationships between
stakeholders
Appendix A. Sample description: projects and project coordinators
Sectors: (n = 89)
% % %
Education 12.4 Rural development 19.1 Reform, governance 11.2
Energy 3.4 Urban development 3.4 Pop., health and nutr. 5.6
Environment 9.0 Public works 6.7 Comm. And telecomm. 2.2
Mining 2.2 Social development 9.0 Agetipe
a
15.7
Contributions by donors: (n = 83), (millions of US$)
Total per
project
World Bank ABD European
Union
UNDP Other Govt
n 86 61 23 17 23 36 63
Mean 36.08 25.94 9.50 9.78 1.82 15.60 7.75
Median 16.70 19.00 2.00 2.50 0.30 5.50 2.00
Mode 5.00 4.10 0.00 0.00 0.00 0.00 2.00
Minimum 0.06 0.00 0.00 0.00 0.00 0.00 0.00
Maximum 600.00 120.00 60.00 90.00 15.00 250.00 100.00
Project coordinators:
Sex (n = 91) Male: 89% Female: 11%
Country (n = 92) Francophone: 65% Anglophone: 35%
Education (n = 91) Undergraduate: 13% Graduate: 87%
Professional status
(n = 91)
Civil servant: 33% Seconded
civil servant:
27%
Contractual.: 34% Other: 6%
Salary and benets (n = 89):
(US$ equivalent) <2500 25005000 50007500 750010,000 >10,000
% 26.1 17.4 10.9 8.7 33.7
a
Agency managing mostly construction projects (Agence d Exe cution des Travaux d Inte re t Public).
Relationship Abbreviation
Coordinatortask manager
My task manager came to visit me
frequently.
TM VISITS CR
I visited my task manager frequently. CR VISITS TM
My task manager gave me autonomy. TM AUTONOMY
My task manager had condence in me. TM TRUST
We have common values. TM VALUES
We are approximately the same age. TM AGE
My task manager understands my local
constraints.
TM
UNDERSTANDING
I obtained rapid approval from my
task manager on important matters.
TM RELIABLE
We have a relationship of mutual respect. TM RESPECT
My task manager visited my home on
occasion.
TM IN MY HOME
I know the family of my task manager. TM FAMILY
We communicate well TM COMM
Coordinatornational supervisor
My national supervisor came to visit me
frequently.
NS VISITS CR
I visited my national supervisor
frequently at the Ministry.
CR VISITS NS
References
[1] Ravaillon M, Gaurav D, Van de Walle D. Quantifying absolute
poverty in the developing world. Rev Income Wealth
1991;37:34361.
[2] Collier P, Dollar D. Aid allocation and poverty reduction. Policy
Research Working Paper (2041) World Bank, Washington, DC,
1999.
[3] Collier P, Dollar D. Can the world cut poverty in half? How
policy reform and eective aid can meet the international
development goals. Policy Research Working Paper (2403) World
Bank, Washington, DC, 2001.
[4] Deaton A. Counting the worlds poor: problems and possible
solutions. The World Bank Res Obser 2002;16(2):12547.
[5] The World Bank. World development indicators. The World
Bank Publications. Washington, DC, 2004.
[6] Lucas RE. On the mechanics of economic development. J
Monetary Econ 1988;22:0322.
[7] Meier GM, Stiglitz E. Frontiers in development economics: the
future in perspective. Washington DC: Oxford University Press
and the World Bank; 2001.
[8] Youker R. The nature of international development projects.
Paper for presentation at PMI Conference, Baltimore, 2003.
[9] Dia M. Development and cultural values in sub-Saharan Africa.
Finance Dev 1991;28(4):103.
[10] Muriithi N, Crawford L. Approaches to project management in
Africa: implications for international development projects. Int J
Project Manage 2003;21:30919.
[11] Cooke-Davis T. The real success factors on projects. Int J Project
Manage 2002;20:18590.
[12] Baccarini D. The logical framework method for dening project
success. Project Manage J 1999;30(4):2532.
[13] Munns AK, Bjeirmi BF. The role of project management in
achieving project success. Int J Project Manage 1996;14(2):817.
[14] Stukenbruck L. Who determines project success? PMI Annual
Symposium, Montreal 1986:8593.
[15] Lipovetsky S. The relative importance of project success dimen-
sions. R&D Manage 1997;27(2):97106.
[16] Wideman RM. How to motivate stakeholders to work together.
In: Cleland DI, editor. Field guide to project management. New
York: Van Nostrand Reinhold; 1998. p. 2126.
[17] Slevin DP, Pinto JK. The project implementation prole: new tool
for project managers. Project Manage J 1986;17(4):5770.
[18] Baker BN, Murphy DC, Fisher D. Factors aecting project
success. In: Cleland DI, King WR, editors. Project Man-
agement Handbook. New York: Van Nostrand Reinhold;
1988.
[19] Pinto JK, Slevin DP. Project success: Denitions and measure-
ment techniques. Project Manage J 1988;19(1):6772.
[20] Pinto JK, Slevin DP. Critical success factors across the project life
cycle. Project Manage J 1988;19(3):6774.
[21] Freeman M, Beale P. Measuring project success. Project Manage
J 1992;23(1):817.
[22] Wateridge J. How can IS/IT projects be measured for success? Int
J Project Manage 1997;16(1):5963.
[23] Shenar AJ, Levy O, Dvir D. Mapping the dimensions of project
success. Project Manage J 1997;28(2):513.
[24] Lim CS, Zain MM. Criteria of project success: An explanatory re-
examination. Int J Project Manage 1999;17(4):2438.
[25] Westerweld E. The project excellence model: linking success
criteria and success factors. Int J Project Manage 2003;21:4118.
[26] Diallo A, Thuillier D. The dimensions of success for international
development projects: the perceptions of African project coordi-
nators. Int J Project Manage 2004;22:1931.
[27] Jack W. Social Investment Funds: An organisational approach to
improve development assistance. The World Bank Res Obser
2001;16(1):10924.
[28] Alderfer CP. Group and intergroup relations. In: Hackmann JR,
Suttle JL, editors. Improving life at work. Santa Monica: Good-
year; 1977.
[29] Hackman JR. The design of work groups. In: Lorsch JW, editor.
Handbook of organizational behaviour. Englewood Clis
NJ: Prentice Hall; 1987. p. 31542.
[30] McGrath JE. Studying groups at work: ten critical needs for
theory and practice. In: Goodman PS and associates, editors.
Designing eective workgroups. San Francisco CA: Jossey-Bass;
1986.
[31] Guzzo RA, Shea GP. Group performance and intergroup
relations in organizations. In: Dunnette MD, Hough LM, editors.
Handbook of industrial and organizational psychology, vol.
3. Palo-Alto, CA: Consulting Psychologists Press; 1992. p.
269313.
[32] Savoie A, Beaudin G. Les equipes de travail, que faut-il en
conna tre? Psychologie du travail et des organisations
1995;1(23):11634.
[33] Guzzo RA, Dickson MW. Teams in organizations: recent
research in performance and eectiveness. Annu Rev Psychol
1996;47:30738.
Appendix B (continued)
Relationship Abbreviation
I regularly informed my national supervisor
about the project
NS INFORMED
My national supervisor gave me autonomy. NS AUTONOMY
My national supervisor had condence in me. NS TRUST
We did part of our studies together. STUDIES
We are approximately the same age. NS AGE
We share a common language apart from
French or English.
LANGUAGE
We have common values NS VALUES
I get rapid approval from my national
supervisor on important matters.
NS RELIABLE
We have a relation of mutual respect. NS RESPECT
My national supervisor came to my home on
occasion.
NS IN MY HOME
I know my national supervisors family. NS FAMILY
My national supervisor helped when I
experienced problems.
NS SUPPORT
We communicate well NS COMM
Within the project team
The team members knew each other for
several years.
KNOW EACH
OTHER
I have known them for several years. CR KNOWS THEM
I participated in the choice of my team
members.
CHOICE
On the team there were one or more private
contractors.
CONTRACTUAL
My team bonded. MUTUAL AID
There was no rivalries among them. NO RIVALRIES
There was little absenteeism in the team. NO ABSENTEEISM
The working ambance was excellent. ATMOSPHERE
The team functionned well without me. TE AUTONOMY
Team members participed in social events
together.
TE SOLIDARITY
They met at their home. TE FAMILY
Everyone was concerned about the success of
the project.
MOTIVATION
Information circulated well within the team TE COMM
[34] Homan EJ, Kinlaw CS, Kinlaw DC. Developing superior
project teams: a study of the characteristics of high performance
in project teams. Proceedings of the PMI Research Conference
2000:2935.
[35] Thamhain HJ, Wilemon DL. Conict management in project life
cycles. Sloan Manage Rev 1975:3150.
[36] Thamhain HJ, Wilemon DL. Building high performing engineer-
ing project teams. IEEE Trans Eng Manage 1987;EM
34(3):1307.
[37] Wilemon DL, Thamain HJ. Team building in project manage-
ment. Proceedings of the Project Management Institute Confer-
ence 1979:37380.
[38] Thamain HJ. Team building in project management. In: Cleland
D, King W, editors. Project Management Handbook. New-
York: Van Nostrand Reinhold; 1988. p. 82346.
[39] Katzenbach JR, Smith DK. The wisdom of teams: Creating the
high performance organization. Boston: Harvard Business
School Press; 1993.
[40] Nurick AJ. Facilitating eective work groups. Adv Manage J
1993;58(1):226.
[41] Thamhain HJ, Gemill GR. Inuence styles of project manager:
Some project performance correlates. Acad Manage J
1974;17:21624.
[42] Elmes M, Wilemon DL. Organizational culture and project leader
eectiveness. Project Manage J 1988;19(4):5462.
[43] Zimmerer T. A leadership prole of American project managers.
Project Manage J 1998;29(1):317.
[44] Katz R. The eects of group longevity on project communication
and performance. Administrative Sci Quart 1982;27:10481.
[45] Hartman FT. The role of trust in project management. Proceed-
ings of the PMI Research Conference 1999.
[46] Zaghloul R, Hartman FT. Construction contracts: The cost of
mistrust. Proceedings of the IRNOP V Conference 2002.
[47] Deutsch M. Trust and suspicion. J Conict Resolut
1958;2:26579.
[48] Zand DE. Trust and managerial problem solving. Administrative
Sci Quart 1972;17:22939.
[49] Gambetta D. Can we trust trust? In: Gambetta D, editor. Trust:
making and breaking cooperative relations. Basil: Blakwell;
1988. p. 21338.
[50] Hosmer LRT. Trust: the connecting link between organizational
theory and philosophical ethics. Acad Manage Rev 1995:379403.
[51] Mayer RC, Davis JH, Schoorman FD. An integrative model of
organizational trust. Acad Manage Rev 1995;20:70934.
[52] Lewicki RJ, McAllister DJ, Bies RJ. Trust and distrust: New
relationships and realities. Acad Manage Rev 1998;23(3):43858.
[53] Blau PM. Exchange and power in social life. New-York: Wiley;
1964.
[54] Coase R. The nature of the rm. Economica 1937:386405.
[55] Williamson OE. The economics of organization: the transaction
cost approach. Am J Sociol 1981;87:54877.
[56] Williamson OE. Calculativeness, trust and economic organiza-
tion. J Law Econ 1993;36(1):45386.
[57] Beccerra M, Gupta AK. Trust within the organization: Integrat-
ing the trust literature with agency theory and transaction costs
economics. Public Administ Quart 1999;23(2):177203.
[58] McAllister DJ. Aect- and cognition-based trust as foundations
for interpersonal cooperation in organizations. Acad Manage J
1995;38:2459.
[59] Williams M. In whom we trust: Group membership as an eective
context for trust development. Acad Manage Rev
2001;26(3):37796.
[60] Jones GR, George JM. The experience and evolution of trust:
Implications for cooperation and teamwork. Acad Manage Rev
1998;23(3):53146.
[61] Ring PS, Van de Ven AH. Structuring cooperative relationships
between organizations. Strategic Manage J 1992;12:48398.
[62] Ring PS, Van de Ven AH. Developmental process of cooperative
interorganizational relationships. Acad Manage Rev
1994;19(1):90118.
[63] Victor B, Cullen JB. The organizational bases of ethical work
climates. Administrative Sci Quart 1988;33(1):10125.
[64] Butler JK. Towards understanding and measuring condition of
trust: Evolution of a condition of trust inventory. J Manage
1991;17:64363.
[65] Butler JK, Cantrell RS. Communication factors and trust: An
exploratory study. Psychol Rep 1994;74:334.
[66] Lewicki RJ, Bunker BB. Developing and maintaining trust in
working relationships. In: Kramer RM, editor. Trust in organi-
zations: frontiers of theory and research. London: Sage; 1996. p.
11439.
[67] Ruppel CP, Harrington SJ. The relationship of communication,
ethical work climate, and trust to commitment and innovation. J
Business Ethics 2000;25(4):31328.
Book review
Alan Wren, Gower, Aldershot, The Project Management
AZ: A Compendium of Project Management Techniques
and How to Use Them, 2003, ISBN 0 566 08556 9, A4
hardback, 436 pp., 99.00. Alternative formats: A4 loose-
leaf, ISBN 0 566 08557 7, 436 p., 225.00 and CD-ROM,
ISBN 0 566 08582 8, 295.00 plus VAT
Any new book on project management faces erce
competition from the many already available, several
of which are by acclaimed authors who have earned
an unassailable position in the eld, reinforced by fre-
quent updates. So, this new entry from an unknown
author with a cover price of 99 might, at rst sight,
not be said to have a competitive edge in a saturated
market. Mr. Wren, in his preface, modestly makes
no claim to add anything new and admits that he is
simply presenting what I have learned, used and ap-
preciated, in a direct-access format that I hope readers
will nd useful. So, what is so special about this
book?
Anyone picking up this volume for the rst time will
not fail to be impressed by its size. The format is A4 and
the book weighs in at over 1.6 kg. So one gets plenty of
book for the money but it is hardly a handy volume for
students to carry in their already well-lled bags, even if
they could aord the price. However, the presentation is
of durable high quality, and this large format has al-
lowed the author to produce clear illustrations through-
out, free of the cramped style often seen in smaller
formats. Project management is a subject that needs
space for its propertion expression, and here it has been
given that space.
The writing style is clear, direct and unashamedly di-
dactic. The text is arranged in over 70 short sections,
presented in alphabetical order of various topics. There
is also an appendix devoted to PRINCE topics. This ar-
rangement, supported by a good index, allows easy ref-
erence to the many project management techniques
described. Each section seems to me to strike the appro-
priate balance between the brevity associated with a bu-
isness dictionary and the longer treatment that one
would expect in a textbook. So subjects such as earned
value analysis and network analysis are given brief but
very clear explanations, with short but adequate exam-
ples. Each section ends with pointers to related sections
elsewhere in the book, but with inadequate references
for further reading.
From the (somewhat overlong) introductory bio-
graphical background notes it is clear that Mr. Wren
has spent all his project management life in the compu-
ter software industry, and this is apparent to some ex-
tent in the content of the book and in its frequent
references to PRINCE2, which (as we all know) began
as a tool for controlling software projects. However,
that does not detract too seriously from the usefulness
of this text as a general reference for projects in the
wider commercial and industrial eld.
My usual approach when reviewing a new book is
rst to scan the contents, and then dip into the pages
in search of errors and omissions. I found no signicant
inaccuracies and only two apparent weaknesses in the
main text:
1. There is little about scheduling, either in single pro-
jects or in programmes of projects.
2. There is a section on matrix management, which al-
though very clear on the advantages and disadvan-
tages of the matrix organization, does not allow for
further discussion on the merits or otherwise of teams
and dierent matrix strengths.
A subject often neglected in project management
books is project purchasing, which I have said (perhaps
too many times) is surprising considering that purchased
goods and services account for more than half the costs
of many projects. I was therefore, pleased to nd that
this text does include a useful account of purchasing
methods, albeit biased towards software projects. There
is also a section on contract management which contains
much common sense but does not mention any of the
standard forms of contract or any of the terms recog-
nized in engineering and construction projects.
The main text is preceded by a glossary. This is not
paricularly comprehensive when compared to the glos-
saries found in other project management books, but
the items that do appear are well and accurately ex-
plained. A bibliography comes at the end of the text,
but this has some astonishing omissions, with almost
none of todays recognized mainstream project manage-
ment authors featured.
So, here we have a book that presents well established
project management methodology in an accessible
and highly readable form with no serious errors, idio-
syncrases or surprises. This heavy and expensive volume
PROJECT
MANAGEMENT
will hardly be the rst choice of students and I suspect
that the principal resting place of this impressive hard-
back book will be on the shelves of libraries, where it
will become a useful reference resource. However, there
are other versions. One of these is a CD-ROM, which
includes an intranet license from the publisher to allow
its contents to be accessed by all interested company
sta. In spite of its high price, I judge that the most use-
ful format is the loose-leaf edition. Lecturers and train-
ing professionals will nd that the included photocopy
rights are valuable, allowing sections to be copied and
distributed freely to students as course handouts. The
accuracy and clarity of the text are ideal for that pur-
pose.
Dennis Lock
29 Burston Drive, Park street
St. Albans, Herts AL2 2HR, UK
Tel.: +44 1727 87 3246
E-mail address: dennis.lock@ntl.com
doi:10.1016/j.ijproman.2004.07.004
John M. Nicholas, Project Management for Business
and Engineering, second ed., Elsevier, Butterworth
Heinemann, Burlington, MA, USA, ISBN 0-7506-
7824-0, p. 603 (paperback), 29.99
The jacket of this heavy paperback carries a blurb
which includes the following declaration: This book
encompasses the full range of project management
everything from origins, philosophy, and methodology
to actual applications. Nicholas describes concepts and
techniques, such as project initiation and proposals,
scope and task denition, scheduling, budgeting, risk
analysis, control, project organization, and the often
overlooked people side project leadership, team
building, conict, and stress management. Many pub-
lishers make extravagant claims for their products but
this example is substantially accurate.
A good introductory chapter is written in ne style.
This explains that the book is a mix of the business side
of project management and the human and organiza-
tion side. Professor Nicholas writes that his earlier prac-
tical project management experience included R&D
projects in the aviation industry and software applica-
tions projects in banking. Currently he teaches project
management at Loyola University, Chicago, where he
has been based for more than 10 years. The author owns
that he has drawn not only from all this experience, but
also from the published works of many other authors
and suggestions from colleagues and reviewers. Thus,
this work is a compilation of experience from many
sources. It oers nothing new or startling, but gains its
strength from the richness of these sources and the
authors skill in presenting the material in a clearly writ-
ten and practical way.
The introductory chapter is followed by 16 further
chapters which form the main body of the text. These
are arranged in four parts. Everything is adequately
illustrated throughout with numerous tables and dia-
grams and the book contains many case studies. Almost
every chapter follows the same pattern, in which the
main subject text is followed by a chapter summary, re-
view questions, questions about a chapter case study,
further case studies, and endnotes. These endnotes in-
clude, sometimes with comments, a bibliographical list
of the many references used. There are three appendices,
the rst two of which I feel could easily and with benet
have been integrated into the main chapters.
There is no glossary of project management terms
and no separate bibliography, but there is a good index
of all the authors cited throughout the 17 chapters (giv-
ing just the authors names and page references). The
book ends with a fairly comprehensive general index.
Case examples and case studies are scattered liberally
throughout the work and some of these are developed
through more than one chapter. One project study, the
Logon Project, is used throughout the book to demon-
strate various methodologies and this projects very de-
tailed Logical On-line System Project Master Plan is
presented as the nal appendix. Not all these cases are
listed in the general index. It might be helpful in future
editions to provide a separate index for all the case
examples and studies, especially since this large book
is not particularly easy to navigate and the reader who
loses his or her place will spend some time in nding it
again.
Part I, Philosophy and Concepts, comprises two
chapters which discuss the various forms that project
management can take and contrasts these with other,
nonproject, forms of management. The systems ap-
proach to project management is dealt with at some
length, and there is a fairly substantial introduction to
project organization (a subject dealt with more fully in
Part IV). As in other parts of the book, there is a copi-
ous supply of real life project examples. These examples
are drawn from widely dierent business areas and from
projects of dierent shapes and sizes.
Part II, again comprising two chapters, outlines the
systems development cycle of a project. Many writers
would call this the project life cycle. However, that can
mislead because the true project life cycle does not end
until a project is scrapped at the end of its useful oper-
ational life, so I consider Nicholsons title to be more
254 Book review / International Journal of Project Management 23 (2005) 253256
appropriate. The author rst guides us through the con-
cept, proposal and contracting stages. Appendix B,
Types of Contracts, could have been included here.
Then, perhaps a little late in the sequence, project deni-
tion is detailed. This part of the book concludes by
describing the execution and operation stages of the sys-
tems development cycle. Case illustrations are drawn
from service organizations and government programmes
as well as from industrial organizations.
The eight chapters of Part III, Systems and Proce-
dures, form the largest part of this book. The rst of
these chapters deals with planning fundamentals. It in-
cludes a good description of the initial planning pro-
cesses, including work breakdown and organization
breakdown structures, before introducing planning and
scheduling using charts. Two following chapters give a
very good account of network analysis methods, ranging
from activity-on-arrow and activity-on-node logic dia-
grams to variants such as PERT and GERT. Resource
scheduling and levelling are included. All these methods
are well described with clear examples.
A chapter on cost estimating and budgeting explains
sensibly how costs are estimated, how errors arise, and
deals well with project cost structures. I agree, for exam-
ple, with the advice given here that the project manager
should approve bottomup estimates for work pack-
ages, but functional units should approve topdown
estimates for the work expected of them. Development
of time-phased budgets is covered in this chapter along
with cash ow schedules. There is a short section on
project cost accounting and management information
systems.
The chapter on risk management follows the familiar,
logical sequence of risk identication, assessment, prior-
itization and response planning. A supplement to this
chapter includes even more risk analysis methods.
Again, this is all dealt with in a very practical and clear
way although, there is nothing in the risk response plan-
ning section on the possibility of risk transference
through insurance.
A project control chapter relies very much on the
systems approach, in which data are collected, ana-
lysed, interpreted and used in forecasting. This chapter,
not surprisingly, is the home for earned value analysis
and performance analysis. There is mention of scope
control and a good section on controlling changes. De-
tailed case studies are given. However, there is insu-
cient stress placed on the fact that these procedures,
no matter how well implemented and how good the
data, are all simply analytical and predictive. They
are not in themselves control measures, but only a step
towards control. Control must itself come from the
readiness of managers to take appropriate action as
soon as any variance is predicted. So this chapter
describes a good basis for control, without dealing suf-
ciently with control itself.
Another chapter deals in greater depth with project
management information systems, and I was pleased
to nd that the author has included examples from sev-
eral computer-based systems in addition to the ubiqui-
tous Microsoft Project. However, a reference in the
rst, introductory chapter to the Microsoft Project disk
included with this book appears to be an error, since my
review copy had no such disk and no trace of ever hav-
ing had one. Artemis, Primavera and Welcom products
are among the packages illustrated and all the computer
screen prints are clearly produced, beneting from the
large (254 mm 204 mm) page format. There is, wisely,
no attempt to recommend any particular package, but
more could have been given on the methods for specify-
ing an organizations project management needs as the
basis for choosing one (in the manner of managing
any major project purchase using a specication and
bid analysis procedure). A separate section is devoted
to Web-based project management. The nal chapter
in Part III expands on the processes of project evalua-
tion during and after a project and there is much on re-
view meetings and reporting. After a section on project
termination, there is a short piece on project extensions,
which might more logically t in the earlier chapter that
dealt with project changes and changes in scope.
Part IV, Organization Behavior, contains four nal
chapters, the rst of which (Chapter 14) discusses pure
project teams, the project matrix, and problems of inte-
grating small sub-units within an organization as well as
integration across dierent companies participating in
larger projects. This discussion on organizations is pre-
sented with sound observations on the advantages and
disadvantages of the team and matrix. Joint ventures
and consortia are not given specic mention. Chapter
14 then proceeds into two sideline topics not often con-
sidered to be mainstream project management. The rst
of these is concurrent engineering, which I was pleased
to nd included and know to be a working philosophy
that can benet all the participants, including the cus-
tomer. However, the second of these sideline topics is
quality function deployment, which occupies an eight-
page section. This last section does have some value in
allowing the customers needs to be taken into account
but here, as in the remainder of the book, less attention
is given to dening what is meant by stakeholders in the
wider sense and the diculty in satisfying all their needs
(there is one paragraph on this in Chapter 15).
Most of Chapter 15 describes the roles of people in
project management and includes advice on recruiting
the project manager, complete with a collage of sample
newspaper advertisements. This is a good, exhaustive
chapter that also deals with roles outside the project
team, not forgetting top management. The next chapter
(16) continues the focus on people in projects with a
discussion on leadership and management styles, prob-
lems in teams, team building and inter-group problems.
Book review / International Journal of Project Management 23 (2005) 253256 255
Chapter 16 ends with a long discussion about manag-
ing conict and stress. The last chapter in this book
(Chapter 17) deals eectively and in some detail with
project failures, project successes, and factors that
can lead to either of these results. Project failure is rst
dened and then possible causes of failure are de-
scribed in detail. Similarly, project success is dened,
and then factors for project success are detailed.
Finally, there is a section that gives a Model and Pro-
cedure for Analyzing Project Performance, in which
the causes of failure and success are compared on a
force eld analysis chart.
Purchased materials and services account for a sub-
stantial proportion of project costs. Delays in obtaining
materials and components can add weeks, months or
even years to the duration of a project. Yet here is an-
other otherwise good book that makes the common error
of ignoring the purchasing function and materials man-
agement. There is no reference to materials nonconfo-
rmities or shortages as possible causes of project
failure. The only reference to materials, purchasing and
the supply chain that I could nd in the general index
was procurement management, which led to a brief ref-
erence in the context of project feasibility studies and
proposals.
Purchasing and materials management aside, this is a
valuable book at a very keen price. To quote again from
the jacket blurb, it is intended for business analysts,
engineers, system developers, systems analysts, and oth-
ers just getting started in project management, and for
managers and administrators with little project manage-
ment training. I am not sure about all those analysts,
but it would certainly be of use to practising and emerg-
ing project managers. This is a work that goes far be-
yond the requirements of a textbook for MSc or MBA
students on management courses where project manage-
ment is just one of many modules with the short time
usually available for reading they would be over-
whelmed. It should nd a place among students taking
higher degrees where project management is the princi-
pal subject. University lecturers on all postgraduate
management programmes will welcome the huge fund
of case studies that can be extracted and used for group
debates and coursework assignments.
Dennis Lock
29 Burston Drive, Park Street
St Albans, Herts AL2 2HR, UK
Tel.: +44 1727 873246
E-mail address: dennis.lock@ntlworld.com
doi:10.1016/j.ijproman.2004.12.001
256 Book review / International Journal of Project Management 23 (2005) 253256

IPJM Vol 23

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IPJM Vol 23

Uploaded by

Copyright:

Available Formats

1.

) denes the term

description noted previ-

Guide. A guide to The project management

cole des Sciences de la Gestion, De pt. Management et Technologie,

You might also like