core concepts of project management

Samuel J. Mantel, Jr.
Jack R. Meredith
Scott M. Shafer
Margaret M. Sutton

JOHN WlLEY & SONS, INC.


ACQUISITIONS EDITOR
MARKETING MANAGER
PRODUCTION EDITOR
SENIOR DESIGNER
OUTSIDE PRODUCTION MANAGEMENT
COVER DESIGN
COVER PHOTOGRAPH

Beth Golub
Jessica Garcia
Patricia McFadden
Harry Nolan
Suzanne Ingrao/Ingrao Assoc
Howard Grosstnan
OAndrew Sacks/Stone

Thts book was set in 10 W12 Goudy by UG / GGS Information Services, Inc. and printed and hound
by R. R. Donnclley & Sons. The cover was printed by Phoenix Color.
This book is printed o n acid-free paper.

(
00\

i/

Copyright 20010 John Wiley & Sons, Inc. All rights reserved
No part of this publication may be reproduced, stored in a retrieval system, or transmitted
in any form or by any means, electronic, mechanical, photocopying, recording, scanning
or otherwtse, except as permitted under Section 107 or 108 of the 1976 United States
Copyright Act, without either the prior written permission of the Publisher, or
authortzation through payment of the appropriate per-copy fee to the Copyright
Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax
(978) 750-4470. Requests to rhe Publisher for permission should be addressed to the
Permissions Department, John Wiley &Sons, Inc., 11 1 River Street, Hoboken,N J
07030,(201) 748-6011, fax (201) 748-6008, E-Mail: PERMREQQWILEY.COM.
To order books please call l(800)-225-5945.
ISBN 0-471-37162-9
Printed in the United States of America


To Dotti: gentle critic, careful editor, loving wife.
S. J. M. Jr.

To a brave 15-year-old traveling alone from Wales
to Virginia: Robert Meredith 1662-1 727.

J. R. M.

To Brianna and Sammy G., my most important
and rewarding projects.

S. M. S.

T o Frank, Kyle, and Ali for their support, encouragement, and tolerance.
And to Bobbi, leader and coach, who helped me discover why I love my career
as a project manager.

M. M. S.


THE APPROACH
Over the past several decades, more and more work has been accomplished through
the use of projects and project management. T h e use of projects has been growing at
an accelerated rate. T h e exponential growth of membership in the Project Management Institute (PMI) is convincing evidence, as are the sales of computer software devoted to project management. Several societal forces are driving this growth, and
many economic factors are reinforcing it. W e describe these in Chapter 1 of this
book.
A secondary effect has also been a major contributor to the use of project activity.
As the use of projects has grown, its very success as a way of getting complex activities
carried out successfully has become well established. T h e result has been a striking increase in the use of projects to accomplish jobs that in the past would simply have been
turned over to someone with the comment, "Take care of it."
What happened then was that some individual undertook to carry out the job with
little or no planning, little or n o assistance, few resources, and often with only a vague
notion of what was really wanted. T h e simple application of routine project management techniques significantly improved the consistency with which the outcomes resembled what the organization had in mind when the chore was assigned. Later, this
sort of activity came to be known as "enterprise project management," "management by
projects," and several other names, all of which are described as the project-oriented
organization.
Some of these projects were large, but most were quite small. Some were complex,
but most were relatively straightforward. Some required the full panoply of project management techniques, but most did not. All of them, however, had to be managed and
thus required a great many people to take o n the role of project manager in spite of little
or no education in the science or art of project management.
O n e result was rising demand for education in project management. T h e number
of college courses grew apace, as did the number of consulting firms offering seminars
and workshops. Perhaps most striking was the growth in educational opportunities

through post-secondary schools offering "short coursesn-schools such as DeVry Institute, ITT, and others. In addition, short courses were offered by colleges and community colleges concentrating o n both part-time and full-time education for
individuals already in the work force. A n exemplar of this approach is the University
of Phoenix.
Communications from some instructors in these institutions told us that they would
like a textbook that was shorter and focused more directly on the "technical" aspects of
project management than those currently available. They were willing to forego most of
the theoretical aspects of management, particularly if such were not directly tied to
practice. Their students, who were not apt to take advanced course work in project
management, had little use for understanding the historical development of the field.
They felt no need to read about the latest academic research on the management of
knowledge-based projects in a manufacturing environment. Finally, instructors asked

vii


viii

PREFACE

for increased use of project management application software, though they added that
they did not want a replacement for the many excellent "step-by-stepnand "computingfor-dummies" types of books that were readily available. They wanted the emphasis to
be on project management, not o n project management software.
These requests sounded sensible to us and we have tried to write such a book.

ORGANIZATION A N D CONTENT
With few exceptions, both readers and instructors are most comfortable with project
management texts that are organized around the project life cycle, and this book is so
organized. W e start by defining in Chapter 1 a project and differentiating project management from general management. After discussing the project life cycle, we briefly
cover project selection. W e feel strongly that project managers who understand why a
project was selected by senior management also understand the firm's objectives for the

project. Understanding those things, we know, will be of value in making the inevitable
trade-offs between time, budget, and performance.
Chapter 2 is devoted to the various roles the project manager must play and to the
skills required to play them effectively. In addition, we cover the various ways in which
projects can be organized. The nature of the project team and the behavorial aspects of
projects are also briefly discussed.
Project planning, budgeting, and scheduling are covered in Chapters 3-5. Beginning with planning in Chapter 3 and budgeting in Chapter 4, the use of project tnanagement software is covered in increasing detail. Software is used throughout the
book, where relevant, to illustrate the use and power of such software to aid in managing projects. Chapter 5 uses standard manual methods for building project schedules, and Microsoft Projectm is demonstrated in parallel. Risk management software,
Crystal Ball@2000, is referenced in several chapters. Excelm is used in Chapter 6 t o
solve a problem o n crashing a project. Detailed instructions are given. Chapter 6 also
deals with resource allocation problems in a multiproject setting. A major section of
this chapter is devoted to the insights of E. Goldratt in his book Critical Chain."
Chapter 7 concerns monitoring and controlling the project. Earned value analysis
is covered in some detail. The final chapter deals with auditing, evaluating, and terininating projects.
Interest in risk management has grown rapidly in recent years, but the subject gets
only minimal attention in most introductory level project management textbooks. W e
deal with risk throughout this book, introducing methods of risk management where
relevant to the subject at hand. For example, simulation is referred to in Chapter 1 during our discussion of project selection models and is demonstrated in Chapter 5 by using
Microsoft Excel@for the purpose. Simulation is also demonstrated in Appendix C using
Crystal Ballm 2000. Detailed applications are made to project selection, budgeting, and
scheduling problems. Crystal Ballm 2000 also simulates networks discussed in the section o n the Critical Chain (see Chapter 6).
W e are certainly aware that no text o n project management could be structured to
reflect the chaos that seems to surround some projects throughout their lives, and a
large majority of projects now and then. The organization of this book reflects a tidiness
and sense of order that is nonexistent in reality. Nonetheless, we make repeated references to the technical, interpersonal, and organizational glitches that impact the true
day-to-day life of the project manager.
*Goldratt, E. M. Critical Chain. Great Barrington, M A : North River, 1997


ix

PREFACE

PEDAGOGY
The book includes several pedagogical aids. The end-of-chapter material includes Review Questions that focus on the textual material. Discussion Questions emphasize the
implications and applications of ideas and techniques covered in the text. Where ap,
propriate, there are Problems that are primarily directed at developing skills in the tech,
nical areas of project management as well as familiarizing the student with the use of
relevant software.
In addition to the above, we have included lncidents for Discussion in the form of
caselettes. In the main, these caselettes focus o n one or more elements of the chapter to
which they are appended. Several of them, however, require the application of concepts
and techniques covered in earlier chapters so that they also serve an integrative

function.
More comprehensive cases are also appended to each chapter. A set of these beginning in Chapter 3 is associated with the same project-the planning, building, and marketing of an assisted living facility for people whose state of health makes it difficult for
them to live independently, but who are not yet ill enough to require nursing home
care. Each chapter is followed by another major case calling upon the ideas and methods covered in the chapter. With all these cases, integration with material in other
chapters is apt to be required.
W e have used ExcelB spreadsheets where appropriate throughout the book. Microsoft Office@ is widely available, and with few exceptions students and professional
project managers are familiar with its operation. W e include instructions in the body of
the text for running Excel'sm Random Number Generation and its Solver tools.
A free 120-day trial edition of Microsoft Project 2000@is included in each copy of
the book. The attached CD-ROM includes a complete version of Project 2 0 0 0 ~as well
as a comprehensive user's guide to the software and an overview of how to "get started"
using it. The CD-ROM also contains a complete tutorial with step-by-step instructions
on how to use the software including several case studies and descriptions of how specific companies use software to manage their projects. Preprogrammed, standard printouts are shown as illustrations throughout the text.
Microsoft ProjectB was chosen because it is a competent piece of software that is
used by a large majority of all project management software users. While Project 2000@
comes with this book, schools and professionals with access to earlier versions (specifically Project 4.0@and Project 98@)are not at a disadvantage. Almost all the relevant

commands are the same in all three versions, and the standard printouts are very similar. O n e exception is found in the case of earned value calculations and reports. There
are slight variations among versions, and all three vary slightly from the Project Management Institute standards. The differences are easily handled and are explained in
Chapter 7. With this exception, we do not differentiate between the versions and refer
to them all as Microsoft Project (MSP).
A free trial edition of Decisioneering's Crystal Ballm 2000 is also included in each
copy of the book. W e have noted in Chapters 1 , 4 , 5 ,and 6 some of the problems where
the use of statistical decision models and simulation can be very helpiul in managing
risk. Because we felt that some instructors might desire an option to delay consideration
of applied risk analysis to more advanced courses, applications of Crystal Ball@2000 are .
not integrated into the various chapters, but they are grouped in Appendix C. Detailed
instructions are given. In addition, a number of the end-of-chapter problems have been
rewritten to adapt them for solution by Crystal BallB. These can be found in the Instructor's Resource Guide along with added instructions for use of the software. Crystal Ball@
was chosen because it works seamlessly with Excel@and is user ti-iendly.


PREFACE

X

As we have noted elsewhere, projects have failed because the project manager attempted to manage the software rather than the project. W e feel strongly that students
and professionals should learn to use the basic project management techniques by
hand-and only then turn to software for relief from their manual efforts.
As is true with any textbook, we have made some assumptions about both the students and professionals who will be reading this book. W e assume that they have all had
some elementary training in management, or have had equivalent experience. W e also
assume that, as managers, they have some slight acquaintance with the fundamentals of
accounting, behavioral science, finance, and statistics. We even assume that they have
forgotten most of the statistics they once learned; therefore, we have included an Appendix o n relevant elementary statistics and probability as a memory refresher.

SUPPLEMENTS
T h e Instructor's Resource Guide will provide assistance to the project management instructor in the form of answers/solutions to the questions, problems, incidents for discussion, and end-of-chapter cases. This guide will also reference relevant Harvard

Business School type cases and readings, teaching tips, and other pedagogically helpful
material. T h e publisher maintains a web site for this and other books. T h e address is
www.wiley.com/college/~rojectmgt.The site contains an electronic version of the Instructor's Resource Guide, an extensive set of PowerPoint slides, sample course outlines, links
to relevant material organized by chapter, and sample test questions to test student
understanding.

ACKNOWLEDGMENTS
There is no possible way to repay the scores of project managers and students who have
contributed to this book, often unknowingly. The professionals have given us ideas
about how to manage projects and students have taught us how to teach project management. W e are grateful beyond our ability to express it.
W e are also grateful to a small group of individuals, both close friends and acquaintances, who have been extraordinarily willing to let us "pick" their brains. They graciously shared their time and knowledge without stint. We send our thanks to: James
Cochran, Louisiana Tech University; James Evans, University of Cincinnati; Karen Garrison, 3X Consulting Corporation; Timothy Kloppenborg, Xavier University, Ohio; Samuel
Mantel, 111, Cisco Systems, Inc.; Gerhard Rosegger, Case Western Reserve University; and
above all to Suzanne Ingrao, Ingrao Associates, without whom this book would have
been unreadable.
Finally, we owe a massive debt to those colleagues who reviewed the manuscript for
this book: George R. Dean, DeVry lnstitute of Technology, DuPage; William C. Giauque,
Brigham Young University; Bill Leban, Keller Graduate School of Management; J. Wayne
Patterson, Clemson Uniuersity; Patrick Philipoom, University of South Carolina; Arthur
C. Rogers, City University; Dean T. Scott, DeVry Institute of Technology, Pomona;
Richard V. Sheng, DeVry lnstitute of Technology, Long Beach; William A. Sherrard, Sun
Diego State University; Louis C. Terminello, Stevens Institute of Technology; and Jeffrey L.
Williams, University of Phoenix. W e owe a special thanks to Byron Finch, Miami University, for a number of particularly thoughtful suggestions for improvement. While we give


xi

PREFACE

these reviewers our thanks, we absolve each and all of blame for our errors, omissions,

and wrong-headed notions.
Samuel J. Mantel, Jr.
Joseph S. Stern Professor
Emeritus of Operations Management
College of Business Administration
University of Cincinnati
608 Flagstaff Drive
Cincinnati, OH 45215

Jack R. Meredith
Broyhill Distinguished Scholar
and Chair of Operations
Babcock Graduate School
of Management
Wake Forest University
Winston Salem, N C 27 109


(5 13) 93 1-2465

jack.meredith@mba. wfu. edu
(336) 758-4467

Scott M. Shafer
Babcock Graduate School
of Management
Wake Forest University
P.O. Box 7659
Winston Salem, N C 27 109

Margaret M. Sutton
Sutton Associates
46 North Lake Avenue
Cincinnati, OH 45246

scott.shafer@mba. eufu.edu
(336) 758-3687
www .mba.wfu.edulfacultylshafer


(513) 543-2806


THE WORLD OF PROJECT MANAGEMENT I
1.IWhat Is a Project? 1
1.2 Project Management vs. General Management 2
1.3 What Is Managed? The Three Goals of a Project 5
1.4 The Life Cycles of Projects 6
1.5 Selecting Projects 8
Nonnumeric Selection Methods 8
Numeric Selection Methods 9
1.6 The Aggregate Project Plan 16
1.7 The Materials in this Text 19
Review Questions 20
Discussion Questions 21
Problems 21
Incident for Discussion 22
Case: United Screen Printers 22
Case: Handstar lnc. 24

THE MANAGER, THE ORGANIZATION, AND THE TEAM
2.1 The PM's Roles 27
Facilitator 27
Communicator 29
Virtual Project Manager 30
Meetings, Convenor and Chair 31
2.2 The PM's Responsibilities t o the Project 31
Acquiring Resources 32
Fighting Fires and Obstacles 33
Leadership and Making Trade-offs 33
Negotiation, Conflict Resolution, and Persuasion 33
2.3 Selection of a Project Manager 34
Credibility 35
Sensitivity 35
Leadership, Style, Ethics 35
2.4 Project Management as a Profession 36
2.5 Fitting Projects into the Parent Organization 38
More on "Why Projects?" 39
Pure Project Organization 39
Functional Project Organization 41
Matrix Project Organization 42
Mixed Organizational Systems 45
The Project Staff Office 45

26


xiv

CONTENTS

2.6 The Project Team 46
Matrix Team Problems 47
lntrateam Conflict 47
Review Questions 50
Discussion Questions 51
Problems 51
lncidents for Discussion 51
Case: The Quantum Bank 52

PLANNING THE PROJECT

55

3.1 The Contents of a Project Plan 55
3.2 The Planning Process-Overview
57
3.3 The Planning Process-Nuts and Bolts 58
The Launch Meeting-and Subsequent Meetings 59
Sorting Out the Project 61
The Project Action Plan 63
3.4 The Work Breakdown Structure and Other Aids 69
The Work Breakdown Structure 69
The Linear Responsibility Chart-and Derivatives 72
3.5 Multidisciplinary Teams-Balancing Pleasure and Pain 73
Integration Management and Concurrent Engineering 73
Interface Coordination-Interface Management 75
Comments on Empowerment and Work Teams 76
Review Questions 77
Discussion Questions 78

lncidents for Discussion 78
Case: St. Dismas Assisted Living Facility-I
78
Case: John Wiley & Sons 80

BUDGETING THE PROJECT

82

4.1 Methods of Budgeting 83
Top-Down Budgeting 85
Bottom-Up Budgeting 85
4.2 Cost Estimating 86
Work Element Costing 86
The Impact of Budget Cuts 87
Activity vs. Program Budgeting 89
4.3 Improving Cost Estimates 91
Forms 91
Learning Curves 92
Tracking Signals 94
Other Factors 96
4.4 Budget Uncertainty and Risk Management
Budget Uncertainty 98
Risk Management 101
Review Questions 105
Discussion Questions 105

97

XV

CONTENTS

Incidents for Discussion 106
Case: St. Dismas Assisted Living Facility Project Budget Development-2
Case: Photstat Inc. 109

SCHEDULING THE PROJECT 111
5.1 PERT and CPM Networks 112
The Language of PERT/CPM 112
Building the Network 113
Finding the Critical Path and Critical Time 115
Calculating Activity Slack 117
Doing It the Easy Way-Microsoft Project (MSP) 118
5.2 Project Uncertainty and Risk Management 121
Calculating Probabilistic Activity Times 121
The Probabilistic Network, an Example 122
Once More the Easy Way 124
The Probability of Completing the Project on Time 127
Selecting Risk and Finding D 129
The Case of the Unreasonable Boss 131
The Problem with Mergers 131
5.3 Simulation 132
Traditional Statistics vs. Simulation 137
5.4 The Gantt Chart 140
The Chart 141
5.5 Extensions t o PERT/CPM 145
Precedence Diagramming 146
Other Methods 147

Final Thoughts on the Use of these Tools 148
Review Questions 149
Discussion Questions 150
Problems 150
Discussion Problem 151
Incident for Discussion 152
Case: St. Dismas Assisted Living Facility Project Action Plan-3
Case: Nutristar 155

ALLOCATING RESOURCES TO THE PROJECT 158
6.1 Expediting a Project 159
The Critical Path Method 159
Using ~ x c e l @
t o Crash a Project 165
Fast-Tracking a Project 170
6.2 Resource Loading 170
The Charismatic VP 176
6.3 Resource Leveling 177
Resource Loading/Leveling and Uncertainty 183
6.4 Allocating Scarce Resources t o Projects 185
Some Comments about Constrained Resources 185
Some Priority Rules 185

152

107


xvi

CONTENTS

6.5 Allocating Scarce Resources t o Several Projects 187
The Basic Approach 189
Other Priority Rules 189
Resource Allocation and the Project Life Cycle 189
6.6 Goldratt's Critical Chain 191
Multitasking 194
Common Chain of Events 195
The Critical Chain 196
Review Questions 198
Discussion Questions 198
Incident for Discussion 199
Problems 199
Case: St. Dismas Assisted Living Facility Resource Usage-4
Case: Charter Financial Bank 202
MONITORING AND CONTROLLING THE PROJECT

200

204

7.1 The Plan-Monitor-Control Cycle 204
Designing the Monitoring System 206
7.2 Data Collection and Reporting 207
Data Collecting 207
Data Analysis 208
Reporting and Report Types 209
Meetings 211
Virtual Reports, Meetings, and Project Management 212

7.3 Earned Value 213
7..4 Project Control 220
Purposes of Control 221
7.5 Designing the Control System 222
Types of Control Systems 223
Tools for Control 225
7.6 Scope Creep and Change Control 228
Review Questions 230
Discussion Questions 230
Problems 231
Incidents for Discussion 231
Case: St. Dismas Assisted Living Facility Monitoring-5
233
Case: Palmstar Enterprises, Inc. 236
EVALUATING AND TERMINATING THE PROJECT
8.1 Evaluation 238
Evaluation Criteria 239
Measurement 240
8.2 Project Auditing 240
The Audit Process 240
The Audit Report 243
8.3 Project Termination 245
When t o Terminate a Project 246
Types of Project Termination 247

238


xvii

CONTENTS

The Termination Process 248
The Project Final Report 249
Review Questions 250
Discussion Questions 251
Incidents for Discussion 251
Case: St. Dismas Assisted Living Auditing-6
Case: Datatech's Audit 254

APPENDICES 257
A: Areas under the Normal Distribution 257
B: Probability and Statistics 259
C: Risk Analysis Using Crystal Ball' 268

AUTHOR INDEX

285

SUBJECT INDEX 289

251





The World of Project Management

Once upon a time there was a heroine project manager. Her projects were never late.

They never ran over budget. They always met contract speclficatlons and invariably satisfied the expectations of her clients. And you know as well as we do, anything that begins with "Once upon a time . . ." IS just a fairy tale.
This book is not about fairy tales. ~ h ; o u ~ h o u tthese pages we will be as realistic as
we know how to be. W e wlll explain project management practices that we know will
work. W e wiITdescribe pro&i management tools that we know can help the project
manager come as close as Mothcr Nature and Lady Luck will allow to meeting the expectations o f & wko-k-ave Zsfiike in the outcome of the project.

i_

\

Why this emphasis o n project management? T h e answer is simple: Daily, organizations
are asked t o accomplish tasks that do not fit neatly into business-as-usual. A software
group may be asked to develop an application program that will access U.S. government
data o n certain commodity prices and generate records on the value of commodity inventories held by a firm; the software must be available for use o n April 1, 2004. The
Illinois State Bureau for Children's Services may require an annually updated census of
all Illinois resident children, aged 17 years or younger, living with an illiterate single
parent; the census must begin in 18 months. ,
Note that each task is specific and unique with a specific deliverable aimed at meeting
a specific need or purpose. These are projects. The routine issuance of reports o n the value
of commodity inventories, the routine counseling of single parents o n nurturing their
offspring-these are not projects. The difference between a project and a nonproject is
not always crystal clear. For almost any precise definition, we can point to exceptions.
A t base, however, projects are unique, have a specific deliverable, and have a specific

-

-

- -

2

CHAPTER 1 / THE WORLD O F PROJECT M A N A G E M E N T

due date. Note that our examples have 11 those characteristics. The Project Management Institute (PMI) defines a project s f X temporary endeavor undertaken to create a
uni ue product or service." [12, p. 167
rojects vary widely in size and type T h e writing of this book is a project. T h e reorganization of Procter & Gamble (P G ) into a global enterprise is a project, or
more accurately a program, a large integrated set of projects. The construction of a
fly-in fishing lodge in northern Manitoba, Canada is a project. T h e organization of
"Cat-in-the-Hat Day" so that Mrs. Chaney9s third grade class can celebrate Dr.
Suess's birthday is also a project.
Both the hypothetical projects we mentioned earlier and the real-world projects
listed just above have the same characteristics. They are unique, specific, and have desired completion dates. They all qualify as projects under the PMI's definition. They
have an additional characteristic in common-they are multidisciplinary. They require
input from people with different kinds of knowledge and expertise. This multidisciplinary nature of projects means that they are complex, that is, composed of many interconnected elements and requiring input from groups outside the project. The various
areas of knowledge required for the construction of the fly-in fishing lodge are not difficult to imagine. The knowledge needed for globalization of a large conglomerate like
P&G is quite beyond the imagination of any one individual and requires input from a
diversified group of specialists. Working as a team, the specialists investigate the problem to discover what information, skills, and knowledge are needed to accomplish the
overall task. It may take weeks, months, or even years to find the correct inputs and understand how they fit together.
A secondary effect of using mult~disciplinaryteams to deal with complex problems
is conflict. Projects a r e characterized by conflict. As we will see in later chapters, the
project schedule, budget, and specifications conflict with each other. The needs and desires of the client conflict with those of the project team, the senior management of the
organization conducting the project and others who may have a less direct stake in the
project. Some of the most intense and intractable conflicts are those between members
of the project team. Much more will be said about this in later chapters. For the
moment, it is sufficient to recognize that projects and conflict seem to be inseparable
companions.
It is also important to note that projects do not exist in isolation. They are often
parts of a larger entity or program, just as projects to develop a new engine and an improved suspension system are parts of the program to develop a new automobile. T h e

overall activity is called a program. Projects are subdivisions of programs. Likewise, projects are composed of tasks, which can be further divided into subtasks that can be broken down further still. The purpose of these subdivisions is t o allow the project to be
viewed at various levels of detail. The fact that projects are typically parts of larger organizational programs is important for another reason, as is explained in Section 1.5.
Finally, it is appropriate to ask, "Why projects?" The reason is simple. W e form projects in order to fix the responsibility and authority for the achievement of an organizational goal on an individual or small group when the job does not clearly fall within the
definition of routine work.

@

3

d

5

A project, then, is a temporary endeavor undertaken to create a unique
uct or service. It is specific, timely, usually multidisciplinary, and always conflict ridden. Projects are parts of overall programs and may be broken down
into tasks, subtasks, and further if desired.


3

1.2 PROJECT M A N A G E M E N T VS. GENERAL M A N A G E M E N T

Project management differs from general management largely because projects differ
from what we have referred to as "nonprojects." The naturally high level of conflict present in projects means that the project manager (PM) ust have special skills in c~
e fact the projects are unique means hat the PM must be creative
flict resolution.
<7--an flex~ble,an have the ability to adjust rapidly to c anges. When managing nonprojects, the general manager tries to "manage by exception." In other words, for nonprojects almost everything is routine and is handled routinely by subordinates. The manager deals only with the exceptions. For the PM, almost everything is an exception.
Certainly, general management's success is dependent o n good planning. For projects, however, planning is much more carefully detailed and project success is absolutely dependent o n such planning. The project plan is the immediate source of the
project's budget, schedule, control, and evaluation. Detailed planning is critically important. O n e should not, of course, take so much time planning that nothing ever gets
done, but careful planning is a major contributor to project success. Project planning is

discussed in Chapter 3.
Project budgeting differs from standard budgeting, not in accounting techniques,
but in the way budgets are constructed. Budgets for nonprojects are primarily modifications of budgets for the same activity in the previous period. Project budgets are newly
created for each project and often cover several periods in the future. T h e project budget is derived directly from the project plan that calls for specific activities. These activities require resources, and such resources are the heart of the project budget. Similarly,
the project schedule is also derived from the project plan.
In a nonproject manufacturing line, the sequence in which various things are done
is set when the production line is designed. The sequence of activities usually is not altered when new models are produced. O n the other hand, each project has a schedule
of its own. Previous projects with deliverables similar to the one at hand may provide a
rough template for the current project, but its schedule will be set by the project's
unique plan and by the date o n which the project is due for delivery to the client. As we
will see in later chapters, the special requirements associated with projects have led to
the creation of special managerial tools for budgeting and scheduling.
T h e routine work of most organizations takes place within a well-defined structure
of divisions, departments, sections, and similar subdivisions of the total unit. The typical project cannot thrive under such restrictions. The need for technical knowledge, information, and special skills almost always requires that departmental lines be crossed.
This is simply another way of describing the transdisciplinary character of projects.
When projects are conducted side-by-side with routine activities, chaos tends to result-the nonprojects rarely crossing organizational boundaries and the projects crossing them freely. These problems and recommended actions are discussed at greater
length in Chapter 2.
T h e discussion of structure leads to consideration of another difference between
project and general management. In general management, there is a reasonably welldefined managerial hierarchy. Superior-subordinate relationships are known and lines
df authority are clear. I n project management this is rarely true. The PM may be relatively low in the hierarchical chain of command. This does not, however, reduce his or
her responsibility of completing a project successfully. Responsibility without the authority of rank or position is so common in project management as to be the rule, not
the exception. '

p

3


4

CHAPTER 1 / THE WORLD O F PROJECT M A N A G E M E N T

With little legitimate authority, the PM depends on negotiation skills to gain the
cooperation of the many departments in the organization that may be asked to supply
technology, information, resources, and personnel to the project. The parent organization's standard departments have their own objectives, priorities, and personnel. The
project is not their responsibility, and the project tends to get the leftovers, if any, after
the departments have satisfied their own need for resources. Without any real command
authority, the PM must negotiate for almost everything the project needs.
It is important to note that there are two different types of negotiation, win-win negotiation and win-lose negotiation. W h e n you negotiate the purchase of a car or a home,
you are usually engaging in win-lose negotiation. T h e less you pay for home or car, the
less profit the seller makes. Your savings are the other party's losses-win-lose negotiation. This type of negotiation is never appropriate when dealing with other members of
your organization. If you manage to "defeat" a department head and get resources or
commitments that the department head did not wish to give you, imagine what will
happen the next time you need something from this individual. The PM simply cannot
risk win-lose situations when negotiating with other members of the organization.
Within the organization, win-win negotiation is mandatory. In essence, in win-win
negotiation both parties must try t o understand what the other party needs. The probe
lem you face as a negotiator is how t o help other parties meet their needs in return for
their help in meeting the needs of your project. W h e n negotiation takes place repeatedly between the same individuals, win-win negotiation is the only sensible procedure.
PMs spend a great deal of their time negotiating. General managers spend relatively little. Skill at win-win negotiating is a requirement for successful project managing. (See
[2, 7, and 131.)
O n e final point about negotiating: Successful win-win negotiation often involves
taking a synergistic approach by searching for the "third alternative." For example, consider a product development project focusing o n the development of a new inkjet
printer. A design engineer working o n the project suggests adding more memory to the
printer. The PM initially opposes this suggestion feeling that the added memory will
make the printer too costly. Rather than rejecting the suggestion, however, the PM
tries to gain a better understanding of the design engineer's concern.
Based o n their discussion, the PM learns that the engineer's purpose in requesting
additional memory is t o increase the printer's speed. After benchmarking the competition, the design engineer feels the printer will not be competitive as it is currently configured. The PM explains his fear that adding the extra memory will increase the cost of
the printer to the point that it also will n o longer be cost competitive. Based o n this discussion the design engineer and PM agree that they need to search for another (third)

alternative that will increase the printer's speed without increasing its costs. A couple of
days later, the design engineer identifies a new ink that can simultaneously increase the
printer's speed and actually lower its total and operating costs.
Project management differs greatly from general management. Every project is
planned, budgeted, scheduled, and controlled as a unique task. Unlike nonprojects, projects are often multidisciplinary and usually have considerable need
to cross departmental boundaries for technology, information, resources, and a
7
personnel. Crossing these boundaries tends to lead to intergroup conflict.
Unlike their general management counterparts, project managers have responsibility for accomplishing a project, but little or n o legitimate authority to
command the required resources from the functional departments. The PM
must be skilled at win-win negotiation to obtain these resources.


-- -

1.3 WHAT IS MANAGED? THE THREE GOALS OF A PROJECT

--

-

5

The performance of a project is measured by three criteria. Is the project on time or
early? Is the project o n or under budget? Does the project meet the agreed-upon specifications t o the satisfaction of the customer? Figure 1-1 shows the three goals for any project. T h e performance of the project, and the PM, is measured by the degree t o w h ~ c h
these goals are achieved.
I
O n e of these goals, specifications, is set primarily by the client (although the client
agrees to all three when contracting for the project). It is the client who must decide
what capabilities are required of the project's deliverables-and this is what makes the

project unique. Some writers insist that "quality" is a separate and distinct goal of the
project along with time, cost, and specifications. W e do not agree because we consider
quality an inherent part of the project specifications, not separable from them.
If we did not live in a n uncertain world in which the best made plans often go awry,
managing projects would be relatively simple, requiring only careful planning. Unfortunately, we do not live in a perfectly predictable (deterministic) world, but one characterized by chance events (uncertainty). This ensures that projects travel a rough road. Murphy's Law seems as universal as death and taxes, and the result is that the most skilled
planning is upset by uncertainty. Thus, the PM spends a great deal of time adapting to
unpredicted change. The primary method of adapting is t o trade-off one objective for
another. If a construction project falls behind schedule because of bad weather, it may
be possible to get back o n schedule by adding resources-in this case, probably labor
and some equipment. If the budget cannot be raised to cover the additional resources,
the PM may have to negotiate with the client for a later delivery date. If neither cost
nor schedule can be negotiated, the contractor may have t o "swallow" the added costs
(or pay a penalty for late delivery), and accept lower profits.
All projects are always carried out under conditions of uncertainty. Well-tested
software routines may. not perform properly when integrated with other well-tested routines. A chemical compound may destroy cancer cells in a test tube-and even in the
bodies of test animals-but may kill the host as well as the cancer. Where one cannot

Performance
Required ~erformance

Due date

Time
('schedule")

Figure 1-1 Performance, cost, and time
project targets.

-

6

CHAPTER I / THE WORLD OF PROJECT MANAGEMENT

find an acceptable way to deal with a problem, the only alternative may be to stop the
project and start afresh to achieve the desired deliverables. In the past, it was popular t o
label these technical uncertainties "technological risk." This is not very helpful, however, because it is not the technology that is uncertain. W e can, in fact, do almost anything we wish, excepting perhaps faster-than-light travel and perpetual motion. What is
uncertain is not technological success, but rather how much it will cost and how long it
will take to reach success.
Most of the trade-offs PMs make are reasonably straightforward and are discussed
during the planning, budgeting, and scheduling phases of the project. Usually they involve trading time and cost, but if we cannot alter either the schedule or the budget,
the specifications of the project may be altered. Frills o n the finished product may be
foregone, capabilities not badly needed may be compromised. From the early stages of
the project, it is the PM's duty to know which elements of project performance are
sacrosanct and which are not.
One final comment o n this subject: Projects must have some flexibility. Again, this
is because we do not live in a deterministic world. Occasionally, a senior manager (who
does not have to manage the project) presents the PM with a document precisely listing
a set of deliverables, a fixed budget, and a firm schedule. This is failure in the making for
the PM. Unless the budget is overly generous, the schedule overlong, and the specifications easily accomplished, the system is, as mathematicians say, "overdetermined." If
Mother Nature so much as burps, the project will fail t o meet its rigid parameters. A PM
cannot be successful without flexibility.
Projects have three interrelated objectives: to (1) meet the budget, (2) finish
o n schedule, and (3) meet specifications that satisfy the client. Because we live
in a n uncertain world, as work o n the project proceeds, unexpected problems
are bound to arise. These chance events will threaten the project's schedule or
budget or specifications. The PM must now decide how to trade off one project
goal against another (e.g., to stay o n schedule by assigning extra resources
to the project may mean it will run over the predetermined budget.) If the

schedule, budget, and specifications are rigidly predetermined, the project is
probably doomed to failure unless the preset schedule and budget are overly
generous or the difficulty in meeting the specifications has been seriously<
overestimated.

All organisms have a life cycle. They are born, grow, wane, and die. This is true for all
living things, for stars and planets, for the products we buy and sell, for our organizations, and for our projects as well. A project's life cycle measures project completion as a
function of either time (schedule) or resources (budget). This life cycle must be understood because the PM's managerial focus subtly shifts at different stages of the cycle [I,
91. During the early stages, the PM must make sure that the project plan really reflects
the wishes of the client as well as the abilities of the project team and is designed to be
consistent with the goals and objectives of the parent firm.
As the project goes into the implementation stage of its life cycle, the PM's attention turns to the job of keeping the project on budget and schedule--or, when chance
interferes with progress, to negotiating the appropriate trade-offs t o correct or minimize
the damage. A t the end of the project, the PM turns into a "fuss-budget" to assure that
the specifications of the project are truly met, handling all the details of closing out the


7

1.4 T H E LIFE CYCLES O F PROJECTS

Time

cycle.

books o n the project, making sure there are n o loose ends, and that every "i" is dotted
a d "t" crossed.
,;>:>I$&&
any projects are like building a house. A house-building project starts sJowlywfi
a lot of discussion and planning. Then construction be&nsadprogress is rapid. When

' t h e house is built, but not
- - -finished
.
. inside,
- ~ . . progress appears t o slow downand it seerniiigty takes fore"er to aime every thing, t o s n i s h all .the trim, and to assemble and install
t h e built-in appliances. ~rogressis slow-fast-slow as shown in ~ i ~ u 1-2.
re
It used to be thought that the S-shaped curve of Figure 1-2 represented the life
cycle for all projects. While this is true of many projects, there are important exceptions. Anyone who has baked a cake has dealt with a project that approaches completion by a very different route than the traditional S-curve, as shown in Figure 1-3.
The process of baking a cake is straightforward. T h e ingredients are mixed while
the oven is preheated, usually to 350°F. T h e mixture (technically called "goop") is
placed in a greased pan, inserted in the oven and the baking process begins. Assume
that the entire process from assembling the ingredients t o finished cake requires about
45 minutes-15 minutes for assembling the materials and mixing, and 30 minutes for
baking. A t the end of 15 minutes we have goop. Even after 40 minutes, having baked
for 25 minutes, it may look like cake but, as any baker knows, it is still partly goop inside. If a toothpick (our grandmothers used a broom straw) is inserted into the middle of
the "cake" and then removed, it does not come out clean. In the last few minutes of the
process, the goop in the middle becomes cake. If left a few minutes too long in the
oven, the cake will begin to burn o n the bottom. Project Cake follows a path to completion much like Figure 1-3.
There are many projects that are similar to cake-the production of computer software, and many chemical engineering projects, for instance. In these cases the PM's job
begins with great attention to having all the correct project resources at hand or guaranteed to be available when needed. Once the "baking" process is underway-the integra-

.+

al
-

z8

al

'F

a

*
Time

Figure 1-3 A n alternate project life
cycle.


8

CHAPTER I / T H E WORLD OF PROJECT M A N A G E M E N T

tion of various sets of code or chemicals--one can usually not add missing ingredients. As
the process continues, the PM must concentrate o n determining when the project is complete-"done" in the case of cake, or a fully debugged program in the case of software.
In later chapters, we will also see the importance of the shape of the project's life cycle
on how management allocates resources or reacts to potential delays in a project. Management does not need to know the precise shape of the life cycle, but merely whether its completion phase is concave (Figure 1-2) or convex (Figure 1-3) to the baseline.
There are two different paths (life cycles) along which projects progress from
start to completion. O n e is S-shaped and the other is J-shaped. It is an important distinction because identifying the different life cycles helps the PM to
focus attention on appropriate matters to ensure successful project completion.

Before a project begins its life cycle, it must have been selected for funding by the parent
organization. Whether the project was proposed by someone within the organization or
an outside client, it is subject to approval by a more or less formal selection process.
Often conducted by a committee of senior managers, the major function of the selection process is to ensure that several conditions are considered before a commitment is
made to undertake any project. These conditions vary widely from firm to firm, but several are quite common: (1) Is the project potentially profitable? Does it have a chance
of meeting our return-on-investment hurdle rate? (2) Does the firm have, or can it easily acquire, the knowledge and skills to carry out the project successfully? (3) Does the

project involve building competencies that are considered consistent with our firm's
strategic plan? (4) Does the organization currently have the capacity to carry out the
project o n its proposed schedule?This list could be greatly extended.
The selection process is usually complete before a PM is appointed to the project.
Why, then, should the PM be concerned? Quite simply, the PM should know exactly
why the organization selected the specific project because this sheds considerable light
o n what the project (and hence the PM) is expected to accomplish, from senior management's point of view, with the project. The project may have been selected because it appeared to be profitable, or was a way of entering a new area of business, or a way of building a reputation of competency with a new client or in a new market. This knowledge
can be very helpful to the PM by indicating senior management's goals for the project,
which will point to the desirability of some trade-offs and the undesirability of others.
There are many different methods for selecting projects, but they may be grouped
into two fundamental types, nonnumeric and numeric. The former does not use numbers for evaluation. The latter does.

Nonnumeric Selection Methods

The Sacred Cow A t times, the organization's Chief Executive Officer (CEO) or
other senior executive casually suggests a potential product or service that the organization might offer to its customers. The suggestion often starts, "You know, I was thinking
that we might . . ." and concludes with ". . . Take a look at it and see if it looks sensible.
If not, we'll drop the whole thing."
Whatever the selection process, the aforementioned project will be approved. It becomes a "Sacred Cow" and will be shown to be technically, if not economically, feasible. This may seem irrational to new students of project management, but such a judg